summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2025-08-04drm/i915/display: Use the recomended min_hblank valuesArun R Murthy
Use recommended values as per wa_14021694213 to compare with the calculated value and choose minimum of them. v2: corrected checkpatch warning and retain the restriction for min_hblank (Jani) v3: use calculated value to compare with recomended value and choose minimum of them (Imre) v4: As driver supported min bpc is 8, omit the condition check for bpc6 with ycbcr420. Added a note for the same (Imre) v5: Add a warn for the unexpected case of 6bpc + uhbr + ycbcr420 v6: Reworded the comments and check fo anything < compressed bpp 8(Imre) v7: Fix checkpatch warning. (Ankit) Bspec: 74379 Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250730-min_hblank-v7-1-179360220ced@intel.com
2025-08-01drm/i915/bw: Remove space before newlineColin Ian King
There is an extraneous space before a newline in a drm_dbg_kms message. Remove the space. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://lore.kernel.org/r/20250801164658.2438212-1-colin.i.king@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-01drm/i915/dsi: use intel_de_wait_custom() instead of wait_for_us()Jani Nikula
Prefer the register read specific wait function over i915 wait_for_us(). Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/1fe3d5ac314dd644573e9f59941e4c7f1d57b05d.1753956266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-01drm/i915/pch: use intel_de_wait_custom() instead of wait_for_us()Jani Nikula
Prefer the register read specific wait function over i915 wait_for_us(). Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/67e0afa2c0c5ad39b9108af15d0496394e674518.1753956266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-01drm/i915/power: use intel_de_wait_custom() instead of wait_for_us()Jani Nikula
Prefer the register read specific wait function over i915 wait_for_us(). Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/154b681d9545b26453920b155656a65ce685da2a.1753956266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-01drm/i915/cdclk: use intel_de_wait_custom() instead of wait_for_us()Jani Nikula
Prefer the register read specific wait function over i915 wait_for_us(). Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/fadd74e9450afff5e32bf921b192f19ea1629fff.1753956266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-01drm/i915/dpll: use intel_de_wait_custom() instead of wait_for_us()Jani Nikula
Prefer the register read specific wait function over i915 wait_for_us(). Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/d8c381524d721e01228b76b71080c6e4ccc528e9.1753956266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-01drm/i915/ddi: use intel_de_wait_custom() instead of wait_for_us()Jani Nikula
Prefer the register read specific wait function over i915 wait_for_us(). v2: Wait for bits to clear in mtl_ddi_disable_d2d() Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/232a554db6a327974c06f2491311b28f865467b9.1753956266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-01drm/i915/hdmi: use intel_de_wait_for_set() instead of wait_for()Jani Nikula
Prefer the register read specific wait function over i915 wait_for(). Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/c5d3044114b4464799a2fded18cda7946d95c4f6.1753956266.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-07-30drm/i915/fbc: fix the implementation of wa_18038517565Vinod Govindapillai
As per the wa_18038517565, we need to disable FBC compressor clock gating before enabling FBC and enable after disabling FBC. Placing the enabling of clock gating in the fbc deactivate function can make the above wa logic go wrong in case of frontbuffer rendering FBC mechanism. FBC deactivate can get called during fb invalidate and then the corresponding FBC activate can get called without properly disabling the clock gating and can result in compression stalled. So move the enable clock gating at the end of one FBC session after FBC is completely disabled for a pipe. Bspec: 74212, 72197, 69741, 65555 Fixes: 010363c46189 ("drm/i915/display: implement wa_18038517565") Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250729124648.288497-1-vinod.govindapillai@intel.com
2025-07-29drm/i915/display: remove superfluous <linux/types.h> includesJani Nikula
Commit f7a9dc796567 ("drm/i915/scaler: Use intel_display as argument to skl_scaler_max_src_size") added superfluous includes. Remove them. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250728102113.238730-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-07-28drm/i915/vblank: Change log from err to debugSuraj Kandpal
Let Potential update error just be a log instead of a big error we already have Atomic Update error log which shouts out if something really goes wrong. --v2 -Fix typo in commit message [Mitul] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://lore.kernel.org/r/20250724102954.2573715-1-suraj.kandpal@intel.com
2025-07-25drm/i915/display: Remove unused declarations of intel_io_*Gustavo Sousa
Declarations for both intel_io_mmio_fw_write and intel_io_reg_write were added with commit 01389846f7d6 ("drm/i915: Plumb 'dsb' all way to the plane hooks"), but they never got used. Let's remove them. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://lore.kernel.org/r/20250717-drop-unused-intel_io-declarations-v1-1-bdea2c749571@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-25drm/i915/dp: Fix disabling training pattern at end of UHBR link trainingImre Deak
The Fixed: commit below overlooked the fact that intel_dp_link_train_all_phys() is only used for non-UHBR link rates, but intel_dp_stop_link_train() is used for both non-UHBR and UHBR link rates. Hence, after removing the disabling of the training pattern from intel_dp_stop_link_train(), the commit missed adding this back to the end of UHBR link training in intel_dp_128b132b_link_train(). This left the sink in link training mode at the end of an UHBR rate link training. Fix things by disabling the training pattern at the end of UHBR link training as well. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 11fab5a2a1ad ("drm/i915/dp: Clear DPCD training pattern before transmitting the idle pattern") Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250724182900.160891-1-imre.deak@intel.com
2025-07-25drm/i915: Fix selecting CONFIG_DRM_KUNIT_TEST in debug buildsImre Deak
Selecting an option which depends on other options only works if the dependencies are guaranteed to be selected (as these dependencies will not be automatically selected). CONFIG_DRM_KUNIT_TEST depends on DRM, MMU and KUNIT the first two of which are guaranteed to be selected for i915, but the last one is not. Hence, selecting CONFIG_DRM_KUNIT_TEST in i915 debug builds may result in CONFIG_DRM_KUNIT_TEST being selected without the CONFIG_KUNIT dependency being selected. This causes at least the following compile error: drivers/gpu/drm/tests/drm_bridge_test.c: In function ‘drm_test_bridge_alloc_init’: drivers/gpu/drm/tests/drm_bridge_test.c:449:21: error: implicit declaration of function ‘kunit_device_register’; did you mean ‘root_device_register’? [-Werror=implicit-function-declaration] 449 | priv->dev = kunit_device_register(test, "drm-bridge-dev"); Fix the above by selecting CONFIG_DRM_KUNIT_TEST only if CONFIG_KUNIT is also selected. Fixes: 17133255a322 ("drm/i915: replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TEST") Cc: Ruben Wauters <rubenru09@aol.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250724090237.92040-1-imre.deak@intel.com
2025-07-23drm/i915/display: Fix dma_fence_wait_timeout() return value handlingAakash Deep Sarkar
dma_fence_wait_timeout returns a long type but the driver is only using the lower 32 bits of the retval and discarding the upper 32 bits. This is particularly problematic if there are already signalled or stub fences on some of the hw planes. In this case the dma_fence_wait_timeout function will immediately return with timeout value MAX_SCHEDULE_TIMEOUT (0x7fffffffffffffff) since the fence is already signalled. If the driver only uses the lower 32 bits of this return value then it'll interpret it as an error code (0xFFFFFFFF or (-1)) and skip the wait on the remaining fences. This issue was first observed in the xe driver with the Android compositor where the GPU composited layer was not properly waited on when there were stub fences in other overlay planes resulting in visual artifacts. Fixes: d59cf7bb73f3c ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence") Signed-off-by: Aakash Deep Sarkar <aakash.deep.sarkar@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250708074540.1948068-1-aakash.deep.sarkar@intel.com
2025-07-23drm/i915/display: Set C10_VDR_CTRL_MSGBUS_ACCESS before phy reg readJouni Högander
According to C10 VDR Register programming sequence we need set C10_VDR_CTRL_MSGBUS_ACCESS before accessing PHY internal registers from MsgBus. v2: set C10_VDR_CTRL_MSGBUS_ACCESS once for all owned lanes Bspec: 68962 Fixes: 9dc619680de4 ("drm/i915/display: Add function to configure LFPS sending") Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250722125618.1842615-5-jouni.hogander@intel.com
2025-07-23drm/i915/display: Ensure phy is accessible on lfps configurationJouni Högander
Ensure phy is accessible on lfps configuration by adding intel_cx0_phy_transaction_begin/end around it. Fixes: 9dc619680de4 ("drm/i915/display: Add function to configure LFPS sending") Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250722125618.1842615-4-jouni.hogander@intel.com
2025-07-23drm/i915/display: Avoid unnecessarily calling intel_cx0_get_owned_lane_maskJouni Högander
Currently we are always calling intel_cx0_get_owned_lane_mask when intel_lnl_mac_transmit_lfps is called. Avoid this in cases where it's not needed. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250722125618.1842615-3-jouni.hogander@intel.com
2025-07-23drm/i915/display: Write PHY_CMN1_CONTROL only when using AUXLess ALPMJouni Högander
We are seeing "dmesg-warn/abort - *ERROR* PHY * failed after 3 retries" since we started configuring LFPS sending. According to Bspec Configuring LFPS sending is needed only when using AUXLess ALPM. This patch avoids these failures by configuring LFPS sending only when using AUXLess ALPM. Bspec: 68849 Fixes: 9dc619680de4 ("drm/i915/display: Add function to configure LFPS sending") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250722125618.1842615-2-jouni.hogander@intel.com
2025-07-21drm/i915: replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TESTRuben Wauters
DRM_DEBUG_SELFTEST was removed in commit fc8d29e298cf (drm: selftest: convert drm_mm selftest to KUnit) and all functions under it were converted to KUnit, under the DRM_KUNIT_TEST option This conversion however did not occur in the Kconfig.debug file in the i915 directory. This patch replaces the select for DRM_DEBUG_SELFTEST, an option that no longer exists, with the correct select, DRM_KUNIT_TEST. Signed-off-by: Ruben Wauters <rubenru09@aol.com> Link: https://lore.kernel.org/r/20250701115511.5445-1-rubenru09@aol.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-07-21drm/i915/psr: Add enable_panel_replay module parameterJouni Högander
Add new module parameter enable_panel_replay. This can be used to enable/disable Panel Replay. 0=disabled, 1=enabled. -1=use per-chip default (default). Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250715105509.4146806-4-jouni.hogander@intel.com
2025-07-21drm/i915/psr: Ignore enable_psr parameter on Panel ReplayJouni Högander
Currently we are disabling Panel Replay if enable_psr != -1. Lets ignore enable_psr completely on Panel Replay. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250715105509.4146806-3-jouni.hogander@intel.com
2025-07-21drm/i915/psr: Do not disable Early Transport when enable_psr is setJouni Högander
Current approach is that Early Transport is disabled in case enable_psr module parameter is set. Let's ignore enable_psr parameter when choosing if Early Transport can be used. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250715105509.4146806-2-jouni.hogander@intel.com
2025-07-19drm/i915: Don't pass crtc_state to foo_plane_ctl() & co.Ville Syrjälä
The *_plane_ctl() functions only consider the state of the plane (the state of the crtc is handled by the corresponding *_plane_ctl_crtc()), and thus they don't need the crtc_state at all. Don't pass it in. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250717171353.23090-7-ville.syrjala@linux.intel.com
2025-07-19drm/i915: Remove unused dpt_total_entries()Ville Syrjälä
dpt_total_entries() is not used anywhere. Remove it. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250717171353.23090-6-ville.syrjala@linux.intel.com
2025-07-19drm/i915: Use i915_vma_offset() in intel_dpt_offset()Ville Syrjälä
Replace the open coded vma mm node stuff in intel_dpt_offset() with i915_vma_offset(). This will also include the VT-d guard in the result. Granted that should always be 0 for DPT, but it seems prudent to include that in our DPT vma offset check anyway. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250717171353.23090-5-ville.syrjala@linux.intel.com
2025-07-19drm/i915: Move the intel_dpt_offset() check into intel_plane_pin_fb()Ville Syrjälä
Now that we handle all the other vma offset stuff in intel_plane_pin_fb() it seems more proper to do the dpt_vma offset check there as well. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250717171353.23090-4-ville.syrjala@linux.intel.com
2025-07-19drm/i915: Nuke intel_plane_ggtt_offset()Ville Syrjälä
We don't really need the extra intel_plane_ggtt_offset() wrapper anymore. Get rid of it. v2: Deal with reuse_vma() hacks Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250717171353.23090-3-ville.syrjala@linux.intel.com
2025-07-19drm/i915: Precompute plane SURF addressVille Syrjälä
Currently we pre-compute the plane surface/base address partially (only for cursor_needs_physical cases) in intel_plane_pin_fb() and finish the calculation in the plane->update_arm(). Let's just precompute the whole thing instead. One benefit is that we get rid of all the vma offset stuff from the low level plane code. Another use I have in mind is including the surface address in the plane tracepoints, which should make it easier to analyze display faults. v2: Deal with xe reuse_vma() hacks v3: use intel_plane_ggtt_offset() still in reuse_vma() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250717203216.31258-1-ville.syrjala@linux.intel.com
2025-07-19drm/i915/dsi: Don't set/read the DSI C clock divider on GLKVille Syrjälä
GLK doesn't use the DSI C clock at all, no need to program the divider for it. Bspec even says: "Do not program this field". However looks like some firmware versions program this and some do not. In order to avoid bogus fastset mismatches we should also filter it out during readout. v2: Clear all the DSI C clock bits during readout (Jani) Adjust platform checks for new style, and add has_dsic_clock() while at it. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250718112928.27669-1-ville.syrjala@linux.intel.com
2025-07-17drm/i915/dp: Make .set_idle_link_train() mandatoryVille Syrjälä
Everyone implements the .set_idle_link_train() hook now. Just make it mandatory. Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-8-ville.syrjala@linux.intel.com
2025-07-17drm/i915/dp: Implement .set_idle_link_train() for everyoneVille Syrjälä
All platforms are capable of explicitly transmitting the idle pattern. Implement it for everyone (so far it as implemented only for HSW+). The immediate benefit is that we gain the possibility of implementing the POST_LT_ADJ_REQ sequence for all platforms. Another potential future use would be a pseudo port sync mode on pre-BDW where we attempt to sync up multiple ports/pipes by trying to turn on the transcoders at the same time, and switching the links to normal pixel transmission at the same time. I'm not 100% sure the hardware is guaranteed to transmit the required number of idle patterns (5) when switching away from training pattern (either via explicit idle pattern, or straight to the normal pixel output). Would be nice to confirm that at some point, but for now let's assume it happens correctly in both cases. v2: Elaborate a bit more on the min required idle patterns Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-7-ville.syrjala@linux.intel.com
2025-07-17drm/i915/dp: Move intel_dp_training_pattern()Ville Syrjälä
Move intel_dp_training_pattern() upwards to avoid the forward declaration for the POST_LT_ADJ_REQ stuff. Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-6-ville.syrjala@linux.intel.com
2025-07-17drm/i915/dp: Have intel_dp_get_adjust_train() tell us if anything changedVille Syrjälä
In order to implement the POST_LT_ADJ_REQ sequence we need to know whether the sink actually requested a changed to the vswing/pre-emph values. Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-5-ville.syrjala@linux.intel.com
2025-07-17drm/i915/dp: Clear DPCD training pattern before transmitting the idle patternVille Syrjälä
We are supposed to switch off the training pattern in DPCD before we start transmitting the idle pattern. For LTTPRs we do that correctly, but for the sink DPRX we only do this correctly for some platforms. On pre-HSW (where we don't implement the .set_idle_link_train() hook), we directly switch from transmitting the training pattern to normal pixel transmission (the hardware should hopefully guarantee that the minimum number of required idle patters will be transmitted during this transition). The DPCD write correctly precedes the actual switch away from the training pattern. For HSW+ we start transmitting the idle pattern earlier, and only switch off the DPCD training pattern after we switch from the idle pattern to normal pixel transmission. Adjust the code to disable the DPCD training pattern before we start transmitting the idle pattern. v2: Tweak the commit message a bit Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-4-ville.syrjala@linux.intel.com
2025-07-17drm/i915/dp: Don't switch to idle pattern before disable on pre-hswVille Syrjälä
For some reason we are switching over to the idle pattern before disabling the DP port on pre-hsw. AFAICS this has never been part of the documented sequence (and on hsw+ the spec explicitly says not to do this). Get rid of it. The code goes all the way back to commit 5eb08b69f510 ("drm/i915: enable DisplayPort support on IGDNG"), and it was accompanied by a 17ms delay which got changed to vbl wait in commit ab527efc2fea ("drm/i915: use wait_for_vblank instead of msleep(17)"), and was later completely removed in commit 93c9c19b3d25 ("drm/i915: remove unexplained vblank wait in the DP off code"). Smoke tested on g4x/snb/chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2025-07-17drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4xVille Syrjälä
On g4x we currently use the 96MHz non-SSC refclk, which can't actually generate an exact 2.7 Gbps link rate. In practice we end up with 2.688 Gbps which seems to be close enough to actually work, but link training is currently failing due to miscalculating the DP_LINK_BW value (we calcualte it directly from port_clock which reflects the actual PLL outpout frequency). Ideas how to fix this: - nudge port_clock back up to 270000 during PLL computation/readout - track port_clock and the nominal link rate separately so they might differ a bit - switch to the 100MHz refclk, but that one should be SSC so perhaps not something we want While we ponder about a better solution apply some band aid to the immediate issue of miscalculated DP_LINK_BW value. With this I can again use 2.7 Gbps link rate on g4x. Cc: stable@vger.kernel.org Fixes: 665a7b04092c ("drm/i915: Feed the DPLL output freq back into crtc_state") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2025-07-17drm/i915/gmbus: Add Wa_16025573575 for PTL/WCL for bit-bashingAnkit Nautiyal
As per Wa_16025573575 for PTL/WCL, set the GPIO masks bit before starting bit-bashing and maintain value through the bit-bashing sequence. After the bit-bashing sequence is done, clear the GPIO masks bits. v2: -Use new helper for display workarounds. (Jani) -Use a separate if-block for the workaround. (Gustavo) v3: -Document the workaround details in intel_display_wa.c -Extend the workaround to WCL too. (Gustavo) v4: -Fix the platform check. (Gustavo) -Avoid read when preserve bits are 0. (Gustavo) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250715142211.3145299-1-ankit.k.nautiyal@intel.com
2025-07-17drm/i915/display_wa: Add helpers to check waAnkit Nautiyal
Introduce a generic helper to check display workarounds using an enum. Convert Wa_16023588340 to use the new interface, simplifying WA checks and making future additions easier. v2: Use drm_WARN instead of MISSING_CASE and simplify intel_display_wa macro. (Jani) v3: Print Missing wa number, instead of enum value. (Gustavo, Jani) Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250711041901.1607823-2-ankit.k.nautiyal@intel.com
2025-07-15drm/i915: Don't check for atomic context on PREEMPT_RTSebastian Andrzej Siewior
The !in_atomic() check in _wait_for_atomic() triggers on PREEMPT_RT because the uncore::lock is a spinlock_t and does not disable preemption or interrupts. Changing the uncore:lock to a raw_spinlock_t doubles the worst case latency on an otherwise idle testbox during testing. Ignore _WAIT_FOR_ATOMIC_CHECK() on PREEMPT_RT. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/ Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20250714153954.629393-4-bigeasy@linutronix.de Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-07-14drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2Ankit Nautiyal
Some ICL/TGL platforms with combo PHY ports suffer from signal integrity issues at HBR3. While certain systems include a Parade PS8461 mux to mitigate this, its presence cannot be reliably detected. Furthermore, broken or missing VBT entries make it unsafe to rely on VBT for enforcing link rate limits. To address this introduce a device specific quirk to cap the eDP link rate to HBR2 (540000 kHz). This will override any higher advertised rates from the sink or DPCD for specific devices. Currently, the quirk is added for Dell XPS 13 7390 2-in-1 which is reported in gitlab issue #5969 [1]. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 v2: Align the quirk with the intended quirk name and refactor the condition to use min(). (Jani) v3: Use condition `rate > 540000`. Drop extra parentheses. (Ville) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250710052041.1238567-3-ankit.k.nautiyal@intel.com
2025-07-14Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"Ankit Nautiyal
This reverts commit 584cf613c24a4250d9be4819efc841aa2624d5b6. Commit 584cf613c24a ("drm/i915/dp: Reject HBR3 when sink doesn't support TPS4") introduced a blanket rejection of HBR3 link rate when the sink does not support TPS4. While this was intended to address instability observed on certain eDP panels [1], there seem to be edp panels that do not follow the specification. These eDP panels do not advertise TPS4 support, but require HBR3 to operate at their fixed native resolution [2]. As a result, the change causes blank screens on such panels. Apparently, Windows driver does not enforce this restriction, and the issue is not seen there. Therefore, revert the commit to restore functionality for such panels, and align behaviour with Windows driver. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 [2] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 v2: Update the commit message with better justification. (Ville) Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250710052041.1238567-2-ankit.k.nautiyal@intel.com
2025-07-11drm/i915/xe3lpd: Prune modes for YUV420Suraj Kandpal
We only support resolution up to 4k for single pipe when using YUV420 format so we prune these modes and restrict the plane size at src. This is because pipe scaling will not support YUV420 scaling for hwidth > 4096. --v2 -Use output format to check [Ville] -Add Bspec references -Modify commit messge to point to why this is needed --v3 -Use a function skl_scaler_mode_valid which is routed throug intel_pfit_mode_valid [Ville] -Combine the check conditons [Jonathan] --v4 -mode_valid functions should return drm_mode_status [Jani] --v5 -Use skl_scaler_max_src_size [Ankit] Bspec: 49247, 50441 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> #v2 Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250708043328.1086192-2-suraj.kandpal@intel.com
2025-07-11drm/i915/scaler: Use intel_display as argument to skl_scaler_max_src_sizeSuraj Kandpal
skl_scaler_max_src_size has really no use of intel_crtc other than deriving intel_display. Let's just pass intel_display to it directly. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250708043328.1086192-1-suraj.kandpal@intel.com
2025-07-10drm/i915/bios: Apply vlv_fixup_mipi_sequences() to v2 mipi-sequences tooHans de Goede
It turns out that the fixup from vlv_fixup_mipi_sequences() is necessary for some DSI panel's with version 2 mipi-sequences too. Specifically the Acer Iconia One 8 A1-840 (not to be confused with the A1-840FHD which is different) has the following sequences: BDB block 53 (1284 bytes) - MIPI sequence block: Sequence block version v2 Panel 0 * Sequence 2 - MIPI_SEQ_INIT_OTP GPIO index 9, source 0, set 0 (0x00) Delay: 50000 us GPIO index 9, source 0, set 1 (0x01) Delay: 6000 us GPIO index 9, source 0, set 0 (0x00) Delay: 6000 us GPIO index 9, source 0, set 1 (0x01) Delay: 25000 us Send DCS: Port A, VC 0, LP, Type 39, Length 5, Data ff aa 55 a5 80 Send DCS: Port A, VC 0, LP, Type 39, Length 3, Data 6f 11 00 ... Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 29 Delay: 120000 us Sequence 4 - MIPI_SEQ_DISPLAY_OFF Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 28 Delay: 105000 us Send DCS: Port A, VC 0, LP, Type 05, Length 2, Data 10 00 Delay: 10000 us Sequence 5 - MIPI_SEQ_ASSERT_RESET Delay: 10000 us GPIO index 9, source 0, set 0 (0x00) Notice how there is no MIPI_SEQ_DEASSERT_RESET, instead the deassert is done at the beginning of MIPI_SEQ_INIT_OTP, which is exactly what the fixup from vlv_fixup_mipi_sequences() fixes up. Extend it to also apply to v2 sequences, this fixes the panel not working on the Acer Iconia One 8 A1-840. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14605 Signed-off-by: Hans de Goede <hansg@kernel.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250703143824.7121-1-hansg@kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-07-02drm/i915/power: use intel_de_wait_for_clear() instead of wait_for()Jani Nikula
Prefer the register read specific wait function over i915 wait_for_us(). The existing condition is quite complicated. Simplify by checking for requesters first, and determine timeout based on that. Refresh requesters in case of timeouts, should one have popped up during the wait. The downside is that this does not cut the wait short if requesters show up *during* the wait, but we're talking about 1 ms so shouldn't be an issue. v2: Refresh requesters only if there were none before (Imre) Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250626192632.2330349-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-07-01drm/i915/display: drop a number of dependencies on i915_drv.hJani Nikula
With the switch to an unordered workqueue dedicated to display, we've stopped using struct drm_i915_private in a number of places, and can drop the dependencies on i915_drv.h. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250626101636.1896365-1-jani.nikula@intel.com
2025-07-01drm/i915/fb: use struct intel_display for DISPLAY_VER()Jani Nikula
Convert a leftover struct drm_i915_private use to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250626101712.1898434-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-30drm/i915/display: Fix macro HAS_ULTRAJOINERAnkit Nautiyal
Currently, Ultrajoiner is supported only on Xe2_HPD. Update the HAS_ULTRAJOINER macro to reflect the same. v2: Clarify the commit message to specify platform. (Jani) Bspec: 69556 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Karthik B S <karthik.b.s@intel.com> Link: https://lore.kernel.org/r/20250611053039.377695-1-ankit.k.nautiyal@intel.com
generated by cgit v1.2.3 (git 2.0.4) at 2025-11-27 19:22:10 +0000