summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-04-09drm/exynos: exynos_dp: Apply of-display-mode-bridge to parse the ↵Damon Ding
display-timings node 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 Ding
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 Ding
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 ↵Damon Ding
multi-platform use 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 Lahtinen
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 Lahtinen
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 Cascardo
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 Assche
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 Nikula
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 Nikula
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 Nikula
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 Subrahmanian
__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ä
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 ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next 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 Nikula
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 Vivi
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 Cavitt
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 Upadhyay
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 Price
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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 Brzezinka
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 Belle
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 Belle
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 Belle
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 Belle
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 Belle
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 Belle
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 Belle
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 Belle
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 Nikula
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 Nikula
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 Nikula
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 Nikula
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 Nikula
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 Zimmermann
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 Zimmermann
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 Zimmermann
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 Zimmermann
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
2026-04-08drm/ast: Gen2: Fix open-coded register accessThomas Zimmermann
Replace all open-coded access to MCR and SCU registers in Gen2 with the appropriate calls to ast_moutdwm() and ast_mindwm(). Use MCR and SCU register constants. Name variables according to registers. The values in MCR04 that control VRAM allocation do not look correct. Leave a FIXME comment for later investigation. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-12-tzimmermann@suse.de
2026-04-08drm/ast: Gen1: Fix open-coded register accessThomas Zimmermann
Replace all open-coded access to MCR registers in Gen1 with the appropriate calls to ast_moutdwm() and ast_mindwm(). Use MCR register constants. For the poll loop on MCR100, add ast_moutdwm_poll(). The helper polls the register until it has been updated to the given value. Relax the CPU while busy-waiting. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-11-tzimmermann@suse.de
2026-04-08drm/ast: Store register addresses in struct ast_dramstructThomas Zimmermann
Struct ast_dramstruct contains a 16-bit index field that either contains a magic value or serves as index into the P2A address segment at 0x1e600000. This segment serves MCR and SCU registers, which the ast_dramstruct programs. It's fragile and relies upon the ast_post_chip_*() functions to set up the segment correctly. Replace the 16-bit index with a full 32-bit address of the SCU and MCR addresses. Initialize the DRAM tables with full register constants and write them out with ast_moutdwm(). This sets the correct segment on each write. Drop __AST_DRAMSTRUCT_DRAM_TYPE as it simply referred to MCR04. Use the latter for initializing the DRAM tables. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-10-tzimmermann@suse.de
2026-04-08drm/ast: Use constants for SDRAM registersThomas Zimmermann
Aspeed hardware allows for acceessing the SDRAM from the host. SDRAM registers are located at the memory range at [0x80000000, 0xffffffff]. Refer to memory access with the macro AST_SDRAM(). Also add a TODO item for the nonsensical documentation next to its caller. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260327133532.79696-9-tzimmermann@suse.de
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-19 16:40:28 +0000