- 24 Jan, 2022 4 commits
-
-
Jani Nikula authored
In general, we should avoid redefining kernel macros like this. It can get confusing, and what gets used will depend on whether the header is included or not. Moreover, we should prefer drm_WARN_ON() and drm_WARN_ON_ONCE() anyway, which include the stringified error condition in the message. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121132957.3778555-1-jani.nikula@intel.com
-
Ville Syrjälä authored
dg2_ddi_pre_enable_dp() has outlived its usefulness so eliminate it. The one thing that tgl_ddi_pre_enable_dp() is missing that we need is intel_ddi_config_transcoder_dp2(). So we'll bring that over. tgl_ddi_pre_enable_dp() does also have a few things that dg2_ddi_pre_enable_dp() didn't have: - icl_program_mg_dp_mode() -> nop due to intel_phy_is_tc()==false on DG2 - intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on DG2 - intel_ddi_mso_configure() -> only matters for MSO panels Another slight difference is that dg2_ddi_pre_enable_dp() was missing a bigjoiner check around intel_dsc_enable(), which tgl_ddi_pre_enable_dp() does have. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220119122150.12941-1-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Currently we just use all the hdmi_deep_color_possible() stuff to compute whether deep color is possible, and leave the 8bpc case to do its own thing. That doesn't mesh super well with 4:2:0 handling because we might end up going for 8bpc RGB without considering that it's essentially illegal and we could instead go for a legal 4:2:0 config. So let's run through all the clock checks even for 8bpc first. If we've fully exhausted all options only then do we re-run the computation for 8bpc while ignoring the downstream TMDS clock limits. This will guarantee that if there's a config that respects all limits we will find it, and if there is not we still allow the user to override the mode manually. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Use REG_BIT() & co. for the pre-skl primary plane registers. Also give everything a consistent namespace. v2: s/DSP/DISP/ to avoid confusion (José) Use DISP_WIDTH rather than DISP_POS_X for DSPSIZE (José) Deal with gvt Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:José Roberto de Souza <jose.souza@intel.com>
-
- 21 Jan, 2022 8 commits
-
-
Jani Nikula authored
Seems odd that we clear all event status indicators if we've only handled some. Only clear the ones we've handled. v2: ack DOWN_REP and UP_REQ only if they were set in esi (Ville) Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120110102.3116218-1-jani.nikula@intel.com
-
Jani Nikula authored
Only specific event status indicators caused the link status to be acked. Be sure to ack the link status change event. Arguably we should track which bits to actually clear in ESI instead of the wholesale approach. Signed-off-by:
-
Jani Nikula authored
The link service irq vector in DPCD 0x2005 contains the link status changed bit to indicate the status should be checked. Only read and check the link status when requested by the sink. This also reduces the confusion around the buffer size for the combined ESI and link status. Alas, we still need to take into account that all link status helpers expect a buffer of DP_LINK_STATUS_SIZE (6) while the link status in ESI only has 4 bytes. Signed-off-by:
-
Jani Nikula authored
We'll want to expand on this, so abstract it to a separate function first. Improve debug logging while at it. Signed-off-by:
-
Jani Nikula authored
For whatever reason, the ESI link service irq vector was missing from the debug output. Add the missing byte, clean up the debug message, and do the logging right after reading the data. Signed-off-by:
-
Jani Nikula authored
Smaller functions make the thing easier to read. Debug log failures to ack. Note: Looks like we have the retry loop simply because of hysterical raisins, dating back to the original DP MST enabling. Keep it, though I have no idea why we have it. Signed-off-by:
-
Jani Nikula authored
Remove extra indentation. Signed-off-by:
-
Jani Nikula authored
Add new files i915_ioctl.[ch] to hold small ioctls that are out of place everywhere else, and not big enough to warrant a file of their own. For starters, it's just for i915_reg_read_ioctl() that's a bit high level for a low level implementation that intel_uncore.[ch] is. Suggested-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120113346.3214745-1-jani.nikula@intel.com
-
- 20 Jan, 2022 2 commits
-
-
Madhumitha Tolakanahalli Pradeep authored
Replace GEN<n> with DISPLAY_VER<n>, in line with the naming convention followed in the i915 driver code. Signed-off-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Reviewed-by:
Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. to polish the vlv/chv sprite plane registers. Signed-off-by:
-
- 19 Jan, 2022 8 commits
-
-
Ville Syrjälä authored
Lots of machines these days seem to have a crappy type1 DP dual mode adaptor chip slapped onto the motherboard. Based on the DP dual mode spec we currently limit those to 165MHz max TMDS clock. Windows OTOH ignores DP dual mode adaptors when the VBT indicates that the port is not actually DP++, so we can perhaps assume that the vendors did intend that the 165MHz clock limit doesn't apply here. Though it would be much nicer if they actually declared an explicit limit through VBT, but that doesn't seem to be happening either. So in order to match Windows behaviour let's ignore the DP dual mode adaptor's TMDS clock limit for ports that don't look like DP++ in VBT. Unfortunately many older VBTs misdelcare their DP++ ports as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB Lenovo ThinkPad X220). So we can't really do this universally without risking black screens. I suppose a sensible cutoff is HSW+ since that's when 4k became a thing and one might assume that the machines have been tested to work with higher TMDS clock rates. v2: s/IS_BROADWELL/IS_HASWELL/ Acked-by:
-
Ville Syrjälä authored
Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just a DP+HDMI check. The rest of the bits shouldn't really matter anyway. The slight change in behaviour here is that now we do look at the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via intel_bios_encoder_supports_hdmi()) when we previously ignored it. The one platform we know that has problems with that bit is VLV. But IIRC the problem was always that buggy VBTs basically never set that bit. So that should be OK since all it would do is make all DVI ports look like HDMI ports instead. Also can't imagine there are many VLV machines with actual DVI ports in existence. We still keep the rest of the dvo_port/aux_ch checks as we can't trust that DP+HDMI device type equals DP++ due to buggy VBTs. Signed-off-by:
-
Ville Syrjälä authored
Now that we parse the DDI port info from the VBT on all g4x+ platforms we can throw out all the old codepaths in intel_bios_is_port_present(), intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None of these should be called on pre-g4x platforms. For good measure throw in a WARN into intel_bios_is_port_present() should someone get the urge to call it on older platforms. The other two functions are specific to HDMI and DP so should not need any protection as those encoder types don't even exist on older platforms. Signed-off-by:
-
Ville Syrjälä authored
Extend the vbt.ports[] stuff for all g4x+ platforms. We do need to drop the version check as some elk/ctg machines may have VBTs older than that. The oldest I know is an elk with version 142. But the child device stuff has had the correct size since at least version 125 (observed on my sdg), so from that angle this should be totally safe. This does couple of things: - Start using the aux_ch/ddc_pin from VBT instead of just the hardcoded defaults. Hopefully there are no VBTs with entirely bogus information here. - Start using i915->vbt.ports[] for intel_bios_is_port_dp_dual_mode(). Should be fine as the logic doesn't actually change. - Start using i915->vbt.ports[] for intel_bios_is_port_edp(). The old codepath only looks at the DP DVO ports, the new codepath looks at both DP and HDMI DVO ports. In principle that should not matter. We also stop looking at some of the other device type bits (eg. LVDS,MIPI,ANALOG,etc.). Hopefully no VBT is broken enough that it sets up totally conflicting device type bits (eg. LVDS+eDP at the same time). We also lose the "g4x->no eDP ever" hardcoding (shouldn't be hard to re-introduce that into eg. sanitize_device_type() if needed). Lightly smoke tested on a set of machines (one of ctg,ilk,snb,ivb each) with both DP and HDMI (DP++). Everything still worked as it should. Signed-off-by:
-
Ville Syrjälä authored
CHV is currently straddling the divide by using parse_ddi_ports() stuff for aux_ch/ddc_pin but going through all old codepaths for the rest (intel_bios_is_port_present(), intel_bios_is_port_edp(), intel_bios_is_port_dp_dual_mode()). Let's switch over full and use i915->vbt.ports[] for the rest of the stuff. dvo_port_to_port() doesn't know about DSI so we won't get into any kind of "is port B HDMI or DSI or both?" conundrum, which could otherwise happen on VLV/CHV due to DSI ports living in a separate world from the other digital ports. Including Jani's detailed analysis here for posterity: "We stop checking for port A for CHV in intel_bios_is_port_present(), but it's a warn and I don't recall any bug reports, so probably fine. We could add a check in parse_ddi_port(), but meh. Ditto for intel_bios_is_port_dp_dual_mode(), except it doesn't have a warn. The eDP check in intel_bios_is_port_edp() becomes slightly more relaxed. Both the old and new check require these to be set: - DEVICE_TYPE_DISPLAYPORT_OUTPUT - DEVICE_TYPE_INTERNAL_CONNECTOR. The old code also required these to be unset: - DEVICE_TYPE_MIPI_OUTPUT - DEVICE_TYPE_COMPOSITE_OUTPUT - DEVICE_TYPE_DUAL_CHANNEL - DEVICE_TYPE_LVDS_SIGNALING - DEVICE_TYPE_TMDS_DVI_SIGNALING - DEVICE_TYPE_VIDEO_SIGNALING - DEVICE_TYPE_ANALOG_OUTPUT It's possible we've added these just as a sanity check for broken VBTs more than anything. I guess I'd see if actual problems arise. Bottom line, I think the functional changes matter only for VBTs with bogus data." I agree that it should work assuming the VBT isn't totally insane. Modern windows drivers also don't seem to check any of those additional device type bits, which may or may not matter for older devices (no idea what some old driver versions are checking). Signed-off-by:
-
Ville Syrjälä authored
Pull the "do we want to use i915->vbt.ports[]?" check into a central place. Signed-off-by:
-
Ville Syrjälä authored
This async flip vt-d w/a was moved to a different place in commit 7d396cac ("drm/i195: Make the async flip VT-d workaround dynamic") but the drm-intel-fixes cherry-pick commit b2d73deb ("drm/i915: Extend the async flip VT-d w/a to skl/bxt") resurrected the original code as well. So now we have this w/a in two places. Remove the resurrected zombie code. Not done as a revert to hopefully prevent any kind of automagic stable backport. Signed-off-by:
-
Jani Nikula authored
Move struct intel_shared_dpll_funcs to intel_dpll_mgr.c, as no other place needs to have access to it. We also don't need to have kernel-doc documentation for file internal structures, so drop them while at it. Signed-off-by:
-
- 18 Jan, 2022 8 commits
-
-
Ville Syrjälä authored
There is no real point in having this two stage skl_program_plane*() vs. skl_plane_update*() wrapper stuff. All we need to do is determine the correct color plane and we're done. Signed-off-by:
-
Ville Syrjälä authored
Add a few small helpers to calculate the color key register values. Cleans up skl_program_plane_arm() a bit. Signed-off-by:
-
Ville Syrjälä authored
Extract the PLANE_AUX_DIST stuff into a small helper to dclutter skl_program_plane_arm() a bit. Signed-off-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. to polish the cursor plane registers. v2: deal with gvt Signed-off-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. to polish the g4x+ sprite plane registers. Signed-off-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. to polish the ivb+ sprite plane registers. v2: deal with gvt Signed-off-by:
-
Ville Syrjälä authored
Polish the skl+ universal plane register defines by using REG_BIT() & co. The defines are also currently spread around in some semi-random fashion. Collect them up into one place. v2: deal with gvt Signed-off-by:
-
Ville Syrjälä authored
There's no need to have separate masks for the stride bitfield in PLANE_STRIDE for different platforms. All the extra bits are hardcoded to zero anyway. Also the masks we're using now don't even match the actual hardware since the bitfield was only 10 bits on skl/derivatives, only getting bumped to 11 bits on glk. So let's just use a 12 bit mask for everything. Signed-off-by:
-
- 17 Jan, 2022 1 commit
-
-
Jani Nikula authored
The lines_to_wait info from VBT is never used. Remove. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 13 Jan, 2022 5 commits
-
-
Juston Li authored
Similar to commit b8d84368 ("drm/i915/gt: Hold RPM wakelock during PXP suspend") but to fix the same warning for unbind during shutdown: ------------[ cut here ]------------ RPM wakelock ref not held during HW access WARNING: CPU: 0 PID: 4139 at drivers/gpu/drm/i915/intel_runtime_pm.h:115 gen12_fwtable_write32+0x1b7/0 Modules linked in: 8021q ccm rfcomm cmac algif_hash algif_skcipher af_alg uinput snd_hda_codec_hdmi vf industrialio iwl7000_mac80211 cros_ec_sensorhub lzo_rle lzo_compress zram iwlwifi cfg80211 joydev CPU: 0 PID: 4139 Comm: halt Tainted: G U W 5.10.84 #13 344e11e079c4a03940d949e537eab645f6 RIP: 0010:gen12_fwtable_write32+0x1b7/0x200 Code: 48 c7 c7 fc b3 b5 89 31 c0 e8 2c f3 ad ff 0f 0b e9 04 ff ff ff c6 05 71 e9 1d 01 01 48 c7 c7 d67 RSP: 0018:ffffa09ec0bb3bb0 EFLAGS: 00010246 RAX: 12dde97bbd260300 RBX: 00000000000320f0 RCX: ffffffff89e60ea0 RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: ffffffff89e60e70 RBP: ffffa09ec0bb3bd8 R08: 0000000000000000 R09: ffffa09ec0bb3950 R10: 00000000ffffdfff R11: ffffffff89e91160 R12: 0000000000000000 R13: 0000000028121969 R14: ffff9515c32f0990 R15: 0000000040000000 FS: 0000790dcf225740(0000) GS:ffff951737800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000058b25efae147 CR3: 0000000133ea6001 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: intel_pxp_fini_hw+0x2f/0x39 i915_pxp_tee_component_unbind+0x1c/0x42 component_unbind+0x32/0x48 component_unbind_all+0x80/0x9d take_down_master+0x24/0x36 component_master_del+0x56/0x70 mei_pxp_remove+0x2c/0x68 mei_cl_device_remove+0x35/0x68 device_release_driver_internal+0x100/0x1a1 mei_cl_bus_remove_device+0x21/0x79 mei_cl_bus_remove_devices+0x3b/0x51 mei_stop+0x3b/0xae mei_me_shutdown+0x23/0x58 device_shutdown+0x144/0x1d3 kernel_power_off+0x13/0x4c __se_sys_reboot+0x1d4/0x1e9 do_syscall_64+0x43/0x55 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x790dcf316273 Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 89 fa be 69 19 12 28 bf ad8 RSP: 002b:00007ffca0df9198 EFLAGS: 00000202 ORIG_RAX: 00000000000000a9 RAX: ffffffffffffffda RBX: 000000004321fedc RCX: 0000790dcf316273 RDX: 000000004321fedc RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007ffca0df9200 R08: 0000000000000007 R09: 0000563ce8cd8970 R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffca0df9308 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000003 ---[ end trace 2f501b01b348f114 ]--- ACPI: Preparing to enter system sleep state S5 reboot: Power down Changes since v1: - Rebase to latest drm-tip Fixes: 0cfab4cb ("drm/i915/pxp: Enable PXP power management") Suggested-by:
Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
Juston Li <juston.li@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
José Roberto de Souza authored
TC voltage swing programming sequence was updated with a new step. BSpec: 54956 Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220113174826.50272-1-jose.souza@intel.com
-
José Roberto de Souza authored
EHL table was recently updated with some minor fixes. BSpec: 21257 Cc: stable@vger.kernel.org Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Jani Nikula authored
Prefer acronym-based naming to be in line with the rest of the driver. Signed-off-by:
-
Jani Nikula authored
The last user of intel_dp_pack_aux() outside intel_dp_aux.c got removed in commit ad26451a ("drm/i915/display: Drop PSR support from HSW and BDW"). Make the function static again. Rename the pack/unpack functions to follow the usual naming conventions while at it. Signed-off-by:
-
- 12 Jan, 2022 4 commits
-
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2022-01-12 - Constify some pointers. (Rikard Falkeborn) - Use list_entry to access list members. (Guenter Roeck) - Fix cmd parser error for Passmark9. (Zhenyu Wang) Signed-off-by:
-
Rikard Falkeborn authored
It is never modified, so make it const to allow the compiler to put it in read-only memory. While at it, make name a const char*. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20211204105527.15741-10-rikard.falkeborn@gmail.comReviewed-by:
-
Rikard Falkeborn authored
It is never modified, so make it const to allow the compiler to put it in read-only memory. Signed-off-by:
-
Rikard Falkeborn authored
These are never modified, so make them const to allow the compiler to put them in read-only memory. WHile at it, make the description const char* since it is never modified. Signed-off-by:
-
