From 9e0c433d0c05fde284025264b89eaa4ad59f0a3e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= Date: Thu, 10 Jul 2025 23:17:12 +0300 Subject: [PATCH 1/3] drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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ä Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak (cherry picked from commit a8b874694db5cae7baaf522756f87acd956e6e66) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/display/intel_dp.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 640c43bf62d4..724de7ed3c04 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -1604,6 +1604,12 @@ int intel_dp_rate_select(struct intel_dp *intel_dp, int rate) void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock, u8 *link_bw, u8 *rate_select) { + struct intel_display *display = to_intel_display(intel_dp); + + /* FIXME g4x can't generate an exact 2.7GHz with the 96MHz non-SSC refclk */ + if (display->platform.g4x && port_clock == 268800) + port_clock = 270000; + /* eDP 1.4 rate select method. */ if (intel_dp->use_rate_select) { *link_bw = 0; From fd77b2c1b6eb7c7d2087e2c2b37c671d47fd2d4f Mon Sep 17 00:00:00 2001 From: Aakash Deep Sarkar Date: Tue, 8 Jul 2025 07:45:40 +0000 Subject: [PATCH 2/3] drm/i915/display: Fix dma_fence_wait_timeout() return value handling 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 Reviewed-by: Matthew Brost Signed-off-by: Ankit Nautiyal Link: https://lore.kernel.org/r/20250708074540.1948068-1-aakash.deep.sarkar@intel.com (cherry picked from commit cdb16039515a5ac4d2c923f7a651cf19a803a3fe) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/display/intel_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 6f0a0bc71b06..43aa1f97378b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -7061,7 +7061,8 @@ static void intel_atomic_commit_fence_wait(struct intel_atomic_state *intel_stat struct drm_i915_private *i915 = to_i915(intel_state->base.dev); struct drm_plane *plane; struct drm_plane_state *new_plane_state; - int ret, i; + long ret; + int i; for_each_new_plane_in_state(&intel_state->base, plane, new_plane_state, i) { if (new_plane_state->fence) { From 99e91521cef80d74e4fefed16a156848052b13df Mon Sep 17 00:00:00 2001 From: Lucas De Marchi Date: Tue, 22 Jul 2025 12:52:08 -0700 Subject: [PATCH 3/3] drm/xe: Fix build without debugfs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When CONFIG_DEBUG_FS is off, drivers/gpu/drm/xe/xe_gt_debugfs.o is not built and build fails on some setups with: ld: drivers/gpu/drm/xe/xe_gt.o: in function `xe_fault_inject_gt_reset': drivers/gpu/drm/xe/xe_gt.h:27:(.text+0x1659): undefined reference to `gt_reset_failure' ld: drivers/gpu/drm/xe/xe_gt.h:27:(.text+0x1c16): undefined reference to `gt_reset_failure' collect2: error: ld returned 1 exit status Do not use the gt_reset_failure attribute if debugfs is not enabled. Fixes: 8f3013e0b222 ("drm/xe: Introduce fault injection for gt reset") Cc: Himal Prasad Ghimiray Acked-by: Randy Dunlap Tested-by: Randy Dunlap Reviewed-by: Himal Prasad Ghimiray Link: https://lore.kernel.org/r/20250722-xe-fix-build-fault-v1-1-157384d50987@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit 4d3bbe9dd28c0a4ca119e4b8823c5f5e9cb3ff90) Signed-off-by: Thomas Hellström --- drivers/gpu/drm/xe/xe_gt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h index 187fa6490eaf..6357325f3939 100644 --- a/drivers/gpu/drm/xe/xe_gt.h +++ b/drivers/gpu/drm/xe/xe_gt.h @@ -24,7 +24,7 @@ extern struct fault_attr gt_reset_failure; static inline bool xe_fault_inject_gt_reset(void) { - return should_fail(>_reset_failure, 1); + return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(>_reset_failure, 1); } struct xe_gt *xe_gt_alloc(struct xe_tile *tile);