aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2026-04-09drm/bridge: analogix_dp: Remove unused struct drm_connector* for &analogix_dp_plat_data.attach()Damon Ding2-3/+2
For both Rockchip and Exynos sides, the struct drm_connector* is never used in callback &analogix_dp_plat_data.attach(). After applying drm_bridge_connector helper, this parameter will no longer be used at all. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260409065301.446670-10-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: analogix_dp: Remove unused &analogix_dp_plat_data.get_modes()Damon Ding1-3/+0
The callback &analogix_dp_plat_data.get_modes() is not implemented by either Rockchip side or Exynos side. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-9-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: analogix_dp: Move the color format check to .atomic_check() for Rockchip platformsDamon Ding2-18/+11
For Rockchip platforms, the YUV color formats are currently unsupported. This compatibility check was previously implemented in &analogix_dp_plat_data.get_modes(). Moving color format check to &drm_connector_helper_funcs.atomic_check() would get rid of &analogix_dp_plat_data.get_modes() and be more reasonable than before. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-8-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: analogix_dp: Remove redundant &analogix_dp_plat_data.skip_connectorDamon Ding2-2/+1
The &analogix_dp_plat_data.skip_connector related check can be replaced by &analogix_dp_plat_data.bridge. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-7-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/exynos: exynos_dp: Apply of-display-mode-bridge to parse the display-timings nodeDamon Ding2-50/+17
If there is neither a panel nor a bridge, the display timing can be parsed from the display-timings node under the dp node. In order to get rid of &analogix_dp_plat_data.get_modes() and make the codes more consistent, apply DRM of-display-mode-bridge to parse display timings. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-6-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/exynos: exynos_dp: Remove unused &exynos_dp_device.connectorDamon Ding1-3/+0
The &exynos_dp_device.connector is assigned in exynos_dp_bridge_attach() but never used. It should make sense to remove it. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-5-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/exynos: exynos_dp: Remove &exynos_dp_device.ptn_bridgeDamon Ding1-6/+4
Use &analogix_dp_plat_data.bridge instead of &exynos_dp_device.ptn_bridge directly. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-4-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: Move legacy bridge driver out of imx directory for multi-platform useDamon Ding9-109/+112
As suggested by Dmitry, the DRM legacy bridge driver can be pulled out of imx/ subdir for multi-platform use. The driver is also renamed to make it more generic and suitable for platforms other than i.MX. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-3-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/i915/gem: Drop check for changed VM in EXECBUFJoonas Lahtinen1-1/+1
Since the introduction of d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") it has not been possible for VM to change after context creation so the check will never fail. Sima's analysis: This check was added in f7ce8639f6ff ("drm/i915/gem: Split the context's obj:vma lut into its own mutex") but without any hint in the commit message as to why. In another hunk of that commit there's a hint though in __eb_add_lut: /* user racing with ctx set-vm */ This would mean that this bug was introduced in e0695db7298e ("drm/i915: Create/destroy VM (ppGTT) for use with contexts"), which allowed to change the gem_ctx->vm at runtime, opening up the race that was partially fixed in the earlier referenced commit about a year later. But it cannot be exploited anymore in anything remotely recent because with the introduction of proto-contexts we've made gem_ctx->vm invariant again, exactly to preemptively close all these potential issues. Specifically d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") is the vm specific part of the proto-context work. v3: - Include Sima's analysis and WARN_ON_ONCE v4: - Focus only on latest mainline codebase References: https://lore.kernel.org/all/20260324151741.29338-1-sosohero200@gmail.com/ Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260409053111.8914-1-joonas.lahtinen@linux.intel.com (cherry picked from commit f6d4afc9ec6a0bc326151b35a7a3369369180079) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-04-09drm/i915/gem: Drop check for changed VM in EXECBUFJoonas Lahtinen1-1/+1
Since the introduction of d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") it has not been possible for VM to change after context creation so the check will never fail. Sima's analysis: This check was added in f7ce8639f6ff ("drm/i915/gem: Split the context's obj:vma lut into its own mutex") but without any hint in the commit message as to why. In another hunk of that commit there's a hint though in __eb_add_lut: /* user racing with ctx set-vm */ This would mean that this bug was introduced in e0695db7298e ("drm/i915: Create/destroy VM (ppGTT) for use with contexts"), which allowed to change the gem_ctx->vm at runtime, opening up the race that was partially fixed in the earlier referenced commit about a year later. But it cannot be exploited anymore in anything remotely recent because with the introduction of proto-contexts we've made gem_ctx->vm invariant again, exactly to preemptively close all these potential issues. Specifically d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") is the vm specific part of the proto-context work. v3: - Include Sima's analysis and WARN_ON_ONCE v4: - Focus only on latest mainline codebase References: https://lore.kernel.org/all/20260324151741.29338-1-sosohero200@gmail.com/ Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260409053111.8914-1-joonas.lahtinen@linux.intel.com
2026-04-09drm/vram: remove DRM_VRAM_MM_FILE_OPERATIONS from docsThadeu Lima de Souza Cascardo1-5/+2
Commit 02f64b2d8605 ("drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS") dropped DRM_VRAM_MM_FILE_OPERATIONS in preference for using DEFINE_DRM_GEM_OPS. However, it was not dropped from the kernel docs. Use DEFINE_DRM_GEM_OPS in the illustration on how to define a struct file_operations for such a DRM driver and remove any reference to DRM_VRAM_MM_FILE_OPERATIONS. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 02f64b2d8605 ("drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260408-drm_gem_vram_helper_docs-v1-1-4d667a768f75@igalia.com
2026-04-09drm/fb-helper: Fix a locking bug in an error pathBart Van Assche1-1/+3
The name of the function __drm_fb_helper_initial_config_and_unlock() and also the comment above that function make it clear that all code paths in this function should unlock fb_helper->lock before returning. Add a mutex_unlock() call in the only code path where it is missing. This has been detected by the Clang thread-safety analyzer. Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Christian König <christian.koenig@amd.com> # radeon Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # msm Cc: Javier Martinez Canillas <javierm@redhat.com> Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260403205355.1181984-1-bvanassche@acm.org
2026-04-09drm/i915/display: switch to including common step file directlyJani Nikula14-24/+13
Instead of using the proxy intel_step.h in display, just include the common step file directly where needed. This allows us to remove the compat intel_step.h header. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/83b5f13b7f863b9cbc61499bcff22af5cd822a0b.1774875688.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-09drm/xe/step: switch from enum xe_step to intel_step namingJani Nikula4-7/+5
Remove the xe_step macro, and use the enum intel_step name directly. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/87530eaa2052ae4a3c97c7fb87e261d1f73341a7.1774875688.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-09drm/xe/step: switch to the shared step definitions with i915Jani Nikula2-62/+5
Use the shared stepping enums from include/drm/intel/step.h. For now, define xe_step as intel_step to avoid mass renames at the same time. For compat, we can remove the reverse macro. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/8173d9d753b343ba127d86277344248a6b1d0c3f.1774875688.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-09drm/i915/dmc: Reduce wakelock hold timeDibin Moolakadan Subrahmanian1-1/+1
__intel_dmc_wl_release() schedules delayed work which releases the DMC wakelock after a fixed timeout of 50 ms. Until the delayed work runs, the wakelock remains held and prevents entry into deeper DC states. Reduce DMC_WAKELOCK_HOLD_TIME from 50 ms to 5 ms. This should allow the system to enter deeper DC states sooner once MMIO activity settles down. Changes in v2: - Drop detailed explanation from commit message and keep it concise (Suraj Kandpal, Luca Coelho) Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260407105102.3730973-1-dibin.moolakadan.subrahmanian@intel.com
2026-04-09drm/i915/dp: Don't use DP link min bpp for the FRL link bandwidth checkVille Syrjälä1-6/+14
intel_dp_mode_min_link_bpp_x16() gives us the min bpp for the DP link before the PCON, however intel_dp_mode_valid_downstream() is trying to check for sufficient bandwidth on the HDMI FRL link after the PCON. So the use of intel_dp_mode_min_link_bpp_x16() here is incorrect. Presumably even with FRL HDMI still can't go below 8bpc, so we should just use that to give us the minimum required FRL bandwidth. And this needs to account for the sink format (for 4:2:0 sub-sampling) since that is what will be flowing over the HDMI link. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407183015.16256-1-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-09Merge tag 'drm-rust-next-2026-04-06' of https://gitlab.freedesktop.org/drm/rust/kernel into drm-nextDave Airlie5-56/+89
DRM Rust changes for v7.1-rc1 (2nd) Nova (Core): - Don't create intermediate (mutable) references to the whole command queue buffer, which is potential undefined behavior. - Add missing padding to the falcon firmware DMA buffer to prevent DMA transfers going out of range of the DMA buffer. - Actually set the default values in the bitfield Default implementation. - Use u32::from_le_bytes() instead of manual bit shifts to parse the PCI ROM header. - Fix a missing colon in the SEC2 boot debug message. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DHN5GMSIBKO2.2AYOLXDU4X19S@kernel.org
2026-04-09Merge drm/drm-next into drm-intel-nextJani Nikula512-5866/+10633
Backmerge to unblock a topic branch for i915 and xe. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-08Merge drm/drm-next into drm-xe-nextRodrigo Vivi811-10631/+25636
Sync drm-xe-next with drm-next to unblock some topic branches. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-04-08drm/xe/tlb: Init range tilemask err to zeroJonathan Cavitt1-1/+1
Initialize err = 0 in xe_tlb_inval_range_tilemask_submit to prevent a possible uninitialized value return in the case where the tile_mask somehow doesn't match any available tile ids. This targets a static analysis issue. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260316162003.64643-2-jonathan.cavitt@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-08Use xe_map_resource_to_region helper instead of direct accessTejas Upadhyay4-25/+30
Renaming: The helper function res_to_mem_region is now xe_map_resource_to_region. Abstraction: The patch removes instances where block->private was accessed directly to obtain VRAM region data allowing VRAM manager to own block->private for future use cases. V2(MattB): Add more detail about patch also adjust variable placement Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260407055107.2782450-2-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-04-08drm/panthor: Fix kernel-doc in panthor_sched.c so it's visibleSteven Price1-36/+36
Various substructures defined in panthor_sched.c have kernel-doc which is silently ignored because it doesn't include the full path to the member. Fix these issues so that the kernel-doc text is actually output by including the name of the parent. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260408091242.799074-1-steven.price@arm.com
2026-04-08drm/i915/casf: Integrate the sharpness filter properly into the scaler codeVille Syrjälä6-149/+53
The sharpness filter is just a special mode of the pipe scaler. It doesn't warrant all this special casing everywhere. Just integrate it properly into the scaler code so that it's treated no different from the other pipe scaler uses (scaling,centering, YCbCr 4:2:0 output). v2: Also reject scaling_filter vs. sharpness Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-10-ville.syrjala@linux.intel.com
2026-04-08drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMIVille Syrjälä2-11/+6
We now have three different reasons for calling intel_pfit_compute_config(): - actual pfit scaling/centering - YCbCr 4:2:0 output - sharpness filter So let's just call intel_pfit_compute_config() unconditionally from both the DP and HDMI code. Both gmch and ilk+ pfit code should be capable of judging whether anything actually needs the pfit. The only slightly questionable thing in the gmch code is the dithering knob, but that's only a thing on gen2/3 which don't even have HDMI/DP outputs, and so not an issue here. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-9-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Remove redundant argument from intel_casf_filter_lut_load()Ville Syrjälä1-3/+3
intel_casf_filter_lut_load() can find the crtc from the crtc_state. No need to pass in both. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-8-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Constify crtc_stateVille Syrjälä4-11/+11
Make the crtc_state const everywhere in the sharpness filter code where it doesn't need to be mutated. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-7-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Handle CASF in skl_scaler_get_filter_select()Ville Syrjälä1-12/+5
Nuke the duplicate CASF_SCALER_FILTER_SELECT and just have skl_scaler_get_filter_select() return the proper value for sharpness filter use. It is the same "use programmable coefficients" value we already use for the nearest neighbor filtering. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-6-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Extract scaler_has_casf()Ville Syrjälä1-4/+8
Extract a small helper to determine if the scaler supports the sharpness filter or not. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-5-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Move the casf state to better placeVille Syrjälä5-32/+32
The casf state is placed inside the 'hw' state for some reason. That is only really meant for things we have to duplicate from the uapi state. The rest can live on its own in our actual state. And since casf is just one aspect of the pfit/pipe scaler the proper place for it seems to be under pch_pfit. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-4-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Make a proper hw state copy of the sharpness_strengthVille Syrjälä6-6/+16
Make a copy of the uapi.sharpness_strength property value in our hw state. This is how we deal with having proper state for joined pipes. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-3-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: s/casf_enable/enable/Ville Syrjälä5-11/+11
The 'casf_enable' boolean is already inside a casf specific structure, so drop the extra 'casf_' namespace from the bool. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-2-ville.syrjala@linux.intel.com
2026-04-08drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeatSebastian Brzezinka1-8/+18
A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <TASK> <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] </TASK> ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15880 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/d4c1c14255688dd07cc8044973c4f032a8d1559e.1775038106.git.sebastian.brzezinka@intel.com (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-04-08drm/imagination: Minor improvements to job submission code documentationAlessio Belle2-22/+26
Mixed list of clarifications and typo fixes. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-8-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/imagination: Update check to skip prepare_job() for fragment jobsAlessio Belle1-5/+6
By the time prepare_job() is called on a paired fragment job, the paired geometry job might already be finished and its PM reference dropped. Check the fragment job's PM reference instead which is a bit more likely to be still set. This is a very minor optimization. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-7-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/imagination: Move repeated job fence check to its own functionAlessio Belle1-5/+20
This should make the code slightly clearer. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-6-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/imagination: Rename fence returned by pvr_queue_job_arm()Alessio Belle3-7/+7
Rename from done_fence to finished_fence, both because the function returns a drm_sched_fence's finished fence, and to avoid confusion with the job fence, which is called the same but has a different purpose. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-5-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/imagination: Rename pvr_queue_fence_is_ufo_backed() to reflect usageAlessio Belle3-10/+10
This function is only used by the synchronization code to figure out if a fence belongs to this driver. Rename it to pvr_queue_fence_is_native() and update its documentation to reflect its current purpose. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-4-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/imagination: Skip check on paired job fence during job submissionAlessio Belle1-5/+6
While submitting a paired fragment job, there is no need to manually look for, and skip, the paired job fence, as the existing logic to resolve dependencies to pvr_queue_fence objects will have failed to resolve it already and continued with the next one. Point this out where the fence is actually accessed and drop the related check. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-3-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/imagination: Fit paired fragment job in the correct CCCBAlessio Belle1-18/+14
For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20 Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Cc: stable@vger.kernel.org Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-2-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/imagination: Count paired job fence as dependency in prepare_job()Alessio Belle1-4/+23
The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]--- Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Cc: stable@vger.kernel.org Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-1-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-04-08drm/i915/pci: move intel_pci_config.h under include/drm/intelJani Nikula16-130/+14
Since the PCI registers are used from both i915 display and core, move intel_pci_config.h to include/drm/intel/pci_config.h. Drop the intel_ prefix from the name to reduce tautology. With this, we can drop the corresponding xe display compat header. v2: Rebase Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/5aac6c711c3f0a09fc52f322455a4a4b35f80a82.1775590536.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-08drm/i915: drop unnecessary intel_pci_config.h includeJani Nikula1-1/+0
There's an unnecessary include. Drop it. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/8323c99f379809b2973c99ebe54c21fd274d246c.1775590536.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-08drm/i915/mchbar: move intel_mchbar_regs.h under include/drm/intelJani Nikula13-292/+15
Since the mchbar registers are used from both i915 display and core, move intel_mchbar_regs.h to include/drm/intel/mchbar_regs.h. Drop the intel_ prefix from the name to reduce tautology. With this, we can drop the corresponding xe display compat header. v2: Rebase Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/6c951b2c05db74ea517d52a3912986f7eb886422.1775590536.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-08drm/i915/mchbar: drop unnecessary intel_mchbar_regs.h includeJani Nikula3-3/+0
There are some unnecessary includes. Remove. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/7eaf98e648240e3011bfb85d0330787074c39205.1775590536.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-08drm/i915/mchbar: include intel_mchbar_regs.h from intel_mchbar.hJani Nikula7-6/+1
As an exception to the rule of not including unnecessary headers from headers, include intel_mchbar_regs.h from intel_mchbar.h. In order to use the interfaces in intel_mchbar.h you will always have to include the registers anyway, so the includes are in pairs everywhere. There is zero asymmetry. Simplify. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/e44dc2daf3fc39d02c3f598c323caa3c08a54304.1775590536.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-08drm/ast: Fix open-coded scu_rev accessThomas Zimmermann2-7/+7
Replace all open-coded access to P2A and SCU registers in the device detection with the appropriate calls to ast_moutdwm() and ast_mindwm(). Use P2A and MCR register constants. Name variables according to registers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-16-tzimmermann@suse.de
2026-04-08drm/ast: dp501: Fix open-coded register accessThomas Zimmermann2-58/+56
Replace all open-coded access to SCU registers in DP501 support with the appropriate calls to ast_moutdwm() and ast_mindwm(). Use SCU register constants. Name variables according to registers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-15-tzimmermann@suse.de
2026-04-08drm/ast: Gen6: Fix open-coded register accessThomas Zimmermann2-8/+9
Replace all open-coded access to MCR and SCU registers in Gen6 with the appropriate calls to ast_moutdwm() and ast_mindwm(). Use MCR and SCU register constants. Name variables according to registers. v2: - also fix MCR constants Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-14-tzimmermann@suse.de
2026-04-08drm/ast: Gen4: Fix open-coded register accessThomas Zimmermann2-15/+10
Replace all open-coded access to MCR and SCU registers in Gen4 with the appropriate calls to ast_moutdwm() and ast_mindwm(). Use MCR and SCU register constants. Name variables according to registers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-13-tzimmermann@suse.de
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.