summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-03-23drm/amdgpu: Skip discovery dump when topology is unavailableSrinivasan Shanmugam
When generating a devcoredump, amdgpu_discovery_dump() prints the IP discovery topology. The function already needs to handle the case where adev->discovery.ip_top is NULL to avoid a crash. Currently, the code prints a section header and an additional message when the topology is unavailable. However, for platforms where discovery is not used, this section is not expected to be present. Printing an extra message adds unnecessary output. Simplify this by skipping the entire section when ip_top is NULL. The NULL check is kept to avoid a crash, but no output is generated when the discovery topology is unavailable. Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amd/ras: Add input pointer validation in ras core helpersSrinivasan Shanmugam
Add NULL checks for helper input/output pointers that are directly dereferenced, such as tm, seqno, dev_info and init_config. Cc: Tao Zhou <tao.zhou1@amd.com> Cc: YiPeng Chai <YiPeng.Chai@amd.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amd/ras: Add NULL checks for ras_core sys_fn callbacksSrinivasan Shanmugam
Some ras core helper functions access ras_core and its callback table (sys_fn) without validating them first. Cc: Tao Zhou <tao.zhou1@amd.com> Cc: YiPeng Chai <YiPeng.Chai@amd.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amdgpu: annotate eviction fence signaling pathChristian König
Make sure lockdep sees the dependencies here. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amdgpu: Avoid NULL dereference in discovery topology coredump path v3Srinivasan Shanmugam
When a GPU fault or timeout happens, the driver creates a devcoredump to collect debug information. During this, amdgpu_devcoredump_format() calls amdgpu_discovery_dump() to print IP discovery data. amdgpu_discovery_dump() uses: adev->discovery.ip_top and then accesses: ip_top->die_kset amdgpu_discovery_dump() uses adev->discovery.ip_top. However, ip_top may be NULL if the discovery topology was never initialized. The current code does not check for this before using ip_top. As a result, when ip_top is NULL, the coredump worker crashes while taking the spinlock for ip_top->die_kset. Fix this by checking for a missing ip_top before walking the discovery topology. If it is unavailable, print a short message in the dump and return safely. - If ip_top is NULL, print a message and skip the dump - Also add the same check in the cleanup path This makes the coredump and cleanup paths safe even when the discovery topology is not available. KASAN trace: [ 522.228252] [IGT] amd_deadlock: starting subtest amdgpu-deadlock-sdma [ 522.240681] [IGT] amd_deadlock: starting dynamic subtest amdgpu-deadlock-sdma ... [ 522.952317] Write of size 4 at addr 0000000000000050 by task kworker/u129:5/5434 [ 522.937526] BUG: KASAN: null-ptr-deref in _raw_spin_lock+0x66/0xc0 [ 522.967659] Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu] ... [ 522.969445] Call Trace: [ 522.969508] _raw_spin_lock+0x66/0xc0 [ 522.969518] ? __pfx__raw_spin_lock+0x10/0x10 [ 522.969534] amdgpu_discovery_dump+0x61/0x530 [amdgpu] [ 522.971346] ? pick_next_task_fair+0x3f6/0x1c60 [ 522.971363] amdgpu_devcoredump_format+0x84f/0x26f0 [amdgpu] [ 522.973188] ? __pfx_amdgpu_devcoredump_format+0x10/0x10 [amdgpu] [ 522.975012] ? psi_task_switch+0x2b5/0x9b0 [ 522.975027] ? __pfx___drm_printfn_coredump+0x10/0x10 [drm] [ 522.975198] ? __pfx___drm_puts_coredump+0x10/0x10 [drm] [ 522.975366] ? __schedule+0x113c/0x38d0 [ 522.975381] amdgpu_devcoredump_deferred_work+0x4c/0x1f0 [amdgpu] v2: Updated commit message - Clarified that ip_top is not freed, it can just be NULL if discovery was not initialized. (Christian/Lijo) v3: Removed the extra drm_warn() for sysfs init failure as sysfs already reports errors. (Christian) Fixes: e81eff80aad6 ("drm/amdgpu: include ip discovery data in devcoredump") Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amd/display: Do not skip unrelated mode changes in DSC validationYussuf Khalil
Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream. However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc(). At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on: BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977 Workqueue: events drm_mode_rmfb_work_fn Call Trace: <TASK> dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc(). Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5004 Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check") Signed-off-by: Yussuf Khalil <dev@pp3345.net> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amd/ras: Remove redundant NULL check in pending bad-bank list iterationSrinivasan Shanmugam
ras_umc_log_pending_bad_bank() walks through a list of pending ECC bad-bank entries. These entries are saved when a bad-bank error cannot be processed immediately, for example during a GPU reset. Later, this function iterates over the pending list and retries logging each bad-bank error. If logging succeeds, the entry is removed from the list and the memory for that node is freed. The loop uses list_for_each_entry_safe(), which already guarantees that ecc_node points to a valid list entry while the loop body is executing. Checking "ecc_node &&" inside the loop is therefore unnecessary and redundant. Fixes the below: drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_umc.c:225 ras_umc_log_pending_bad_bank() warn: variable dereferenced before check 'ecc_node' (see line 223) Fixes: 7a3f9c0992c4 ("drm/amd/ras: Add umc common ras functions") Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: YiPeng Chai <YiPeng.Chai@amd.com> Cc: Tao Zhou <tao.zhou1@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amd/pm: Add smu v15_0_8 pmfw headerHawking Zhang
Add smu v15_0_8 pmfw header v2: squash in updates (Alex) Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amd/pm: Add smu v15_0_8 message headerHawking Zhang
Add smu v15_0_8 message header v2: squash in updates (Alex) Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amd/pm: Add smu v15_0_8 driver interface headerHawking Zhang
Add smu v15_0_8 driver interface header v2: squash in updates (Alex) Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amdgpu: make amdgpu_user_wait_ioctl more resilent v2Christian König
When the memory allocated by userspace isn't sufficient for all the fences then just wait on them instead of returning an error. v2: use correct variable as pointed out by Sunil Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/amdgpu: replace WARN with DRM_ERROR for invalid sched priorityJesse.Zhang
amdgpu_sched_ioctl() currently uses WARN(1, ...) when userspace passes an out-of-range context priority value. WARN(1, ...) is unconditional and produces a full stack trace, which is disproportionate for a simple input validation failure -- the invalid value is already rejected with -EINVAL on the next line. Replace WARN(1, ...) with DRM_ERROR() to log the invalid value at an appropriate level without generating a stack dump. The -EINVAL return to userspace is unchanged. No functional change for well-formed userspace callers. v2: - Reworked commit message to focus on appropriate log level for parameter validation - Clarified that -EINVAL behavior is preserved (Vitaly) v3: completely drop that warning. Invalid parameters should never clutter the system log. (Christian) Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-23drm/imagination: Skip 2nd thread DM association for non META FirmwareBrajesh Gupta
Only a META firmware can have two threads. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260313-b4-staging-layout_mars_base-v2-2-9e3c251d278e@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-23drm/imagination: Improve firmware power off for layout_mars configBrajesh Gupta
In layout_mars HW config, Firmware MCU moved from Sidekick to new Mars domain so Firmware takes care of powering down Sidekick/Jones and SLC. Skip checks for those from kernel and check idle bits for Firmware MCU and system arbiter excluding SOCIF. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260313-b4-staging-layout_mars_base-v2-1-9e3c251d278e@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-23drm/xe/pf: Fix use-after-free in migration restoreMichał Winiarski
When an error is returned from xe_sriov_pf_migration_restore_produce(), the data pointer is not set to NULL, which can trigger use-after-free in subsequent .write() calls. Set the pointer to NULL upon error to fix the problem. Fixes: 1ed30397c0b92 ("drm/xe/pf: Add support for encap/decap of bitstream to/from packet") Reported-by: Sebastian Österlund <sebastian.osterlund@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7230 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260217154118.176902-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 4f53d8c6d23527d734fe3531d08e15cb170a0819) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-23drm/xe/xe3p: Skip TD flushTejas Upadhyay
Xe3p has HW ability to do transient display flush so the xe driver can enable this HW feature by default and skip the software TD flush. Bspec: 60002 Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://patch.msgid.link/20260305121902.1892593-10-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimizationTejas Upadhyay
When set, starting xe3p_lpg, the L2 flush optimization feature will control whether L2 is in Persistent or Transient mode through monitoring of media activity. To enable L2 flush optimization include new feature flag GUC_CTL_ENABLE_L2FLUSH_OPT for Novalake platforms when media type is detected. Tighten UAPI validation to restrict userptr, svm and dmabuf mappings to be either 2WAY or XA+1WAY V5(Thomas): logic correction V4(MattA): Modify uapi doc and commit V3(MattA): check valid op and pat_index value V2(MattA): validate dma-buf bos and madvise pat-index Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Michal Mrozek <michal.mrozek@intel.com> Acked-by: Carl Zhang <carl.zhang@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260305121902.1892593-9-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23drm/xe/pat: define coh_mode 2wayTejas Upadhyay
Defining 2way (two-way coherency) is critical for Xe3p_LPG (Nova Lake P) platforms to support L2 flush optimization safely. This mode allows the driver to skip certain manual cache flushes (L2 flush optimization) without risking memory corruption because the hardware ensures the most recent data is visible to both entities. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260305121902.1892593-8-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23drm/xe/xe3p_lpg: flush shrinker bo cachelines manuallyTejas Upadhyay
XA, new pat_index introduced post xe3p_lpg, is memory shared between the CPU and GPU is treated differently from other GPU memory when the Media engine is power-gated. XA is *always* flushed, like at the end-of-submssion (and maybe other places), just that internally as an optimisation hw doesn't need to make that a full flush (which will also include XA) when Media is off/powergated, since it doesn't need to worry about GT caches vs Media coherency, and only CPU vs GPU coherency, so can make that flush a targeted XA flush, since stuff tagged with XA now means it's shared with the CPU. The main implication is that we now need to somehow flush non-XA before freeing system memory pages, otherwise dirty cachelines could be flushed after the free (like if Media suddenly turns on and does a full flush) V4: Add comments for L2 flush path V3(Thomas/MattA/MattR): Restrict userptr with non-xa, then no need to flush manually V2(MattA): Expand commit description Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260305121902.1892593-7-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-03-23drm/xe/vf: Improve getting clean NULL contextMichal Wajdeczko
There is a small risk that when fetching a NULL context image the VF may get a tweaked context image prepared by another VF that was previously running on the engine before the GuC scheduler switched the VFs. To avoid that risk, without forcing GuC scheduler to trigger costly engine reset on every VF switch, use a watchdog mechanism that when configured with impossible condition, triggers an interrupt, which GuC will handle by doing an engine reset. Also adjust job size to account for additional dwords with watchdog setup. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260303201354.17948-4-michal.wajdeczko@intel.com
2026-03-23drm/xe: Add MI_SEMAPHORE_WAIT command definitionMichal Wajdeczko
This command supports memory based Semaphore WAIT. Memory based semaphores will be used for synchronization between the Producer and the Consumer contexts. Producer and Consumer Contexts could be running on different engines or on the same engine inside GT. Bspec: 45749, 60244 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260303201354.17948-3-michal.wajdeczko@intel.com
2026-03-23drm/xe: Add PR_CTR_CTRL/THRSH register definitionsMichal Wajdeczko
The Watchdog Counter Control and Watchdog Counter Threshold registers are needed for watchdog programming. This watchdog will generate the "Media Hang Notify" interrupt. Bspec: 45999, 46000 Bspec: 60373, 60374 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260303201354.17948-2-michal.wajdeczko@intel.com
2026-03-23drm/xe/pf: Fix use-after-free in migration restoreMichał Winiarski
When an error is returned from xe_sriov_pf_migration_restore_produce(), the data pointer is not set to NULL, which can trigger use-after-free in subsequent .write() calls. Set the pointer to NULL upon error to fix the problem. Fixes: 1ed30397c0b92 ("drm/xe/pf: Add support for encap/decap of bitstream to/from packet") Reported-by: Sebastian Österlund <sebastian.osterlund@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7230 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260217154118.176902-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2026-03-23drm/i915/dp_tunnel: Fix error handling when clearing stream BW in atomic stateImre Deak
Clearing the DP tunnel stream BW in the atomic state involves getting the tunnel group state, which can fail. Handle the error accordingly. This fixes at least one issue where drm_dp_tunnel_atomic_set_stream_bw() failed to get the tunnel group state returning -EDEADLK, which wasn't handled. This lead to the ctx->contended warn later in modeset_lock() while taking a WW mutex for another object in the same atomic state, and thus within the same already contended WW context. Moving intel_crtc_state_alloc() later would avoid freeing saved_state on the error path; this stable patch leaves that simplification for a follow-up. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Fixes: a4efae87ecb2 ("drm/i915/dp: Compute DP tunnel BW during encoder state computation") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7617 Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260320092900.13210-1-imre.deak@intel.com
2026-03-23drm/i915: Unlink NV12 planes earlierVille Syrjälä
unlink_nv12_plane() will clobber parts of the plane state potentially already set up by plane_atomic_check(), so we must make sure not to call the two in the wrong order. The problem happens when a plane previously selected as a Y plane is now configured as a normal plane by user space. plane_atomic_check() will first compute the proper plane state based on the userspace request, and unlink_nv12_plane() later clears some of the state. This used to work on account of unlink_nv12_plane() skipping the state clearing based on the plane visibility. But I removed that check, thinking it was an impossible situation. Now when that situation happens unlink_nv12_plane() will just WARN and proceed to clobber the state. Rather than reverting to the old way of doing things, I think it's more clear if we unlink the NV12 planes before we even compute the new plane state. Cc: stable@vger.kernel.org Reported-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Closes: https://lore.kernel.org/intel-gfx/20260212004852.1920270-1-khaled.almahallawy@intel.com/ Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Fixes: 6a01df2f1b2a ("drm/i915: Remove pointless visible check in unlink_nv12_plane()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260316163953.12905-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com> (cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-03-23drm/i915: Order OP vs. timeout correctly in __wait_for()Ville Syrjälä
Put the barrier() before the OP so that anything we read out in OP and check in COND will actually be read out after the timeout has been evaluated. Currently the only place where we use OP is __intel_wait_for_register(), but the use there is precisely susceptible to this reordering, assuming the ktime_*() stuff itself doesn't act as a sufficient barrier: __intel_wait_for_register(...) { ... ret = __wait_for(reg_value = intel_uncore_read_notrace(...), (reg_value & mask) == value, ...); ... } Cc: stable@vger.kernel.org Fixes: 1c3c1dc66a96 ("drm/i915: Add compiler barrier to wait_for") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260313110740.24620-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit a464bace0482aa9a83e9aa7beefbaf44cd58e6cf) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-03-23drm/i915/gmbus: fix spurious timeout on 512-byte burst readsSamasth Norway Ananda
When reading exactly 512 bytes with burst read enabled, the extra_byte_added path breaks out of the inner do-while without decrementing len. The outer while(len) then re-enters and gmbus_wait() times out since all data has been delivered. Decrement len before the break so the outer loop terminates correctly. Fixes: d5dc0f43f268 ("drm/i915/gmbus: Enable burst read") Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260316231920.135438-2-samasth.norway.ananda@oracle.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 4ab0f09ee73fc853d00466682635f67c531f909c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-03-23drm/sun4i: Use backend/mixer as dedicated DMA deviceChen-Yu Tsai
The sun4i DRM driver deals with DMA constraints in a peculiar way. Instead of using the actual DMA device in various helpers, it justs reconfigures the DMA constraints of the virtual display device using the DMA device's device tree node by calling of_dma_configure(). Turns out of_dma_configure() should only be called from bus code. Lately this also triggers a big warning through of_iommu_configure() and ultimately __iommu_probe_device(): late IOMMU probe at driver bind, something fishy here! Now that the GEM DMA helpers have proper support for allocating and mapping buffers with a dedicated DMA device, switch over to it as the proper solution. The mixer change was tested on a Pine H64 model B. The backend change was only compile tested. Though I don't expect any issues, help testing on an older device would be appreciated. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260311094929.3393338-5-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2026-03-23drm/mediatek: Set dedicated DMA device and drop custom GEM callbacksChen-Yu Tsai
In commit 9b54a32c7c6a ("drm/mediatek: mtk_gem: Partial refactor and use drm_gem_dma_object") the MediaTek DRM driver was refactored to use drm_gem_dma_object, but custom callbacks were still needed to deal with using the first device of the pipeline as the DMA device, instead of the MMSYS device that the DRM driver binds to. Turns out there is already partial support for dedicated DMA devices in the DRM subsystem for PRIME imports. The preceding patches add support for dedicated DMA devices to the GEM DMA helpers. This allows us to just set the dedicated DMA device for the DRM device, and drop all the custom GEM callbacks. Also drop the .dma_dev field from the driver private data as it is no longer needed. There are slight differences in the mmap helper: the VM_DONTDUMP and VM_IO flags are no longer set. Both were lifted from drm_gem_mmap_obj(). VM_IO probably doesn't make sense since the buffer is allocated using dma_alloc_attrs(). Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260311094929.3393338-4-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2026-03-23drm/gem-dma: Support dedicated DMA device for allocation and mappingChen-Yu Tsai
Support for a dedicated DMA device for prime imports was added in commit 143ec8d3f939 ("drm/prime: Support dedicated DMA device for dma-buf imports"). This allowed the DRM driver to provide a dedicated DMA device when its own underlying device was not capable of DMA, for example when it is a USB device (the original target) or a virtual device. The latter case is common on embedded SoCs, on which the display pipeline is composed of various fixed function blocks, and the DRM device is simply a made-up device, an address space managing the routing between the blocks, or whichever block the implementor thought made sense at the time. The point is that the chosen device is often not the actual device doing the DMA. Various drivers have used workarounds or reimplemented the GEM DMA helpers to get the DMA addresses and IOMMUs to work correctly. Add support for the dedicated DMA device to the GEM DMA helpers. No existing driver currently uses the GEM DMA helpers and calls drm_dev_set_dma_dev() to set a dedicated DMA device, so no existing users should be affected. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260311094929.3393338-3-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2026-03-23drm/prime: Limit scatter list size with dedicated DMA deviceChen-Yu Tsai
If a dedicated DMA device is specified for the DRM device, then the scatter list size limit should pertain to the DMA device. Use the dedicated DMA device, if given, to limit the scatter list size. This only applies to drivers that have called drm_dev_set_dma_dev() and are using drm_prime_pages_to_sg() either directly or through the SHMEM helpers. At the time of this writing, the former case only includes the Rockchip DRM driver, while the latter case includes the gud, udl, and the tiny appletbdrm and gm12u320 drivers. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260311094929.3393338-2-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2026-03-23Merge tag 'drm-misc-next-2026-03-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.1: UAPI Changes: math: - provide __KERNEL_DIV_ROUND_CLOSEST() in UAPI mode: - provide DRM_ARGB_GET*() macros for reading color components Cross-subsystem Changes: math: - implement DIV_ROUND_CLOSEST() with __KERNEL_DIV_ROUND_CLOSEST() Core Changes: atomic: - fix handling of colorop state in atomic updates - provide CRTC background color ttm: - improve tests and doumentation Driver Changes: amdxdna: - allow forcing DMA through IOMMU IOVA - improve debugging bridge: - Support Lontium LT8713SX DP MST bridge plus DT bindings imx: - support planes behind the primary plane - fix bus-format selection ivpu: - perform engine reset on TDR error panel: - novatek-nt36672a: Use mipi_dsi_*_multi() functions - panel-edp: Support BOE NV153WUM-N42, CMN N153JCA-ELK, CSW MNF307QS3-2 renesas: - rz-du: clean up rockchip: - support CRTC background color sun4i: - fix leak in init code - clean up tildc - clean up v3d: - improve handling of struct v3d_stats - improve error handling - clean up vkms: - support CRTC background color Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260320082604.GA17867@linux.fritz.box
2026-03-22drm/mediatek: dsi: Store driver data before invoking mipi_dsi_host_registerLuca Leonardo Scorcia
The call to mipi_dsi_host_register triggers a callback to mtk_dsi_bind, which uses dev_get_drvdata to retrieve the mtk_dsi struct, so this structure needs to be stored inside the driver data before invoking it. As drvdata is currently uninitialized it leads to a crash when registering the DSI DRM encoder right after acquiring the mode_config.idr_mutex, blocking all subsequent DRM operations. Fixes the following crash during mediatek-drm probe (tested on Xiaomi Smart Clock x04g): Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [...] Modules linked in: mediatek_drm(+) drm_display_helper cec drm_client_lib drm_dma_helper drm_kms_helper panel_simple [...] Call trace: drm_mode_object_add+0x58/0x98 (P) __drm_encoder_init+0x48/0x140 drm_encoder_init+0x6c/0xa0 drm_simple_encoder_init+0x20/0x34 [drm_kms_helper] mtk_dsi_bind+0x34/0x13c [mediatek_drm] component_bind_all+0x120/0x280 mtk_drm_bind+0x284/0x67c [mediatek_drm] try_to_bring_up_aggregate_device+0x23c/0x320 __component_add+0xa4/0x198 component_add+0x14/0x20 mtk_dsi_host_attach+0x78/0x100 [mediatek_drm] mipi_dsi_attach+0x2c/0x50 panel_simple_dsi_probe+0x4c/0x9c [panel_simple] mipi_dsi_drv_probe+0x1c/0x28 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __device_attach_driver+0xbc/0x17c bus_for_each_drv+0x88/0xf0 __device_attach+0x9c/0x1cc device_initial_probe+0x54/0x60 bus_probe_device+0x34/0xa0 device_add+0x5b0/0x800 mipi_dsi_device_register_full+0xdc/0x16c mipi_dsi_host_register+0xc4/0x17c mtk_dsi_probe+0x10c/0x260 [mediatek_drm] platform_probe+0x5c/0xa4 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x24/0x30 bus_add_driver+0x11c/0x240 driver_register+0x68/0x130 __platform_register_drivers+0x64/0x160 mtk_drm_init+0x24/0x1000 [mediatek_drm] do_one_initcall+0x60/0x1d0 do_init_module+0x54/0x240 load_module+0x1838/0x1dc0 init_module_from_file+0xd8/0xf0 __arm64_sys_finit_module+0x1b4/0x428 invoke_syscall.constprop.0+0x48/0xc8 do_el0_svc+0x3c/0xb8 el0_svc+0x34/0xe8 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800022 941004ab 2a0003f3 37f80040 (29005a80) Fixes: e4732b590a77 ("drm/mediatek: dsi: Register DSI host after acquiring clocks and PHY") Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20260225094047.76780-1-l.scorcia@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-03-22drm/mediatek: ovl: Add specific entry for mt8167Val Packett
While this configuration is otherwise identical to mt8173, according to Android kernel sources, this SoC does need smi_id_en. Signed-off-by: Val Packett <val@packett.cool> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/5f880f1334aa93184afee3e36132ca42628821fb.1771863641.git.l.scorcia@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-03-22drm/mediatek: Remove all conflicting aperture devices during probeLuca Leonardo Scorcia
If a device has a framebuffer available it might be already used as display by simple-framebuffer or simpledrm when mediatek-drm is probed. This is actually helpful when porting to a new device as framebuffers are simple to setup in device trees and fbcon can be used to monitor the kernel boot process. When drm-mediatek loads a new fb device is initialized, however fbcon remains attached to the initial framebuffer which is no longer connected to the actual display - the early fb is never removed. We can gracefully transition from framebuffer handling to drm-managed display by calling aperture_remove_all_conflicting_devices before registering mediatek-drm. This takes care of unloading other fb devices/drivers and disconnects fbcon which then automatically reconnects to mediatekdrmfb as soon as it's available. The function is invoked just before drm_dev_register() to kick out the existing framebuffer as late as possible to reduce the time the screen is unresponsive. Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20260212192605.263160-1-l.scorcia@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-03-22drm/mediatek: mtk_dsi: enable hs clock during pre-enableGary Bisson
Some bridges, such as the TI SN65DSI83, require the HS clock to be running in order to lock its PLL during its own pre-enable function. Without this change, the bridge gives the following error: sn65dsi83 14-002c: failed to lock PLL, ret=-110 sn65dsi83 14-002c: Unexpected link status 0x01 sn65dsi83 14-002c: reset the pipe Move the necessary functions from enable to pre-enable. Signed-off-by: Gary Bisson <bisson.gary@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> # Chromebooks Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20260120-mtkdsi-v1-1-b0f4094f3ac3@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-03-21drm/i915/wm: Include .min_ddb_alloc_uv in the wm dumpsVille Syrjälä
We include the Y/RGB .min_ddb_alloc in the wm state change dumps. Do the same for .min_ddb_alloc_uv, on the platforms where it is used. Also adjust the whitespace in the other debug prints to keep the values for each wm level lined up across all the lines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: Include ddb_y in skl_print_wm_changes() on pre-iclVille Syrjälä
Pre-icl doesn't use a separate hardware plane for Y scanout, and instead it's all handled magically by the hardware. We do still need to allocate DDB space for the Y color plane though (PLANE_NV12_BUF_CFG). Include that information in the debugs so that we know where it ended up. On icl+ the equivalent information is dumped as the hardware Y plane's normal ddb allocation. v2: Use prink field width for ddb_name alignment Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: Extract skl_print_plane_ddb_changes()Ville Syrjälä
We have skl_print_plane_wm_changes() but the DDB counterpart is just inline in the main loop. Extract it into a function. We'll have a second use for this soon. The "ddb" part is already parametrized in anticipation of the second user. v2: Use prink field width for ddb_name alignment Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: s/skl_print_plane_changes()/skl_print_plane_wm_changes()/Ville Syrjälä
Rename skl_print_plane_changes() to skl_print_plane_wm_changes() to better reflect what it does. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: Nuke wm->uv_wm[]Ville Syrjälä
We currently keep around the full watermarks for the UV plane on pre-icl, even though the hardware doesn't need most of this information. The only thing we need to keep is the min_ddb_alloc for the UV plane. Move that into the main wm->wm[].min_ddb_alloc_uv alongside the other min_ddb_alloc (used for Y/RGB). This makes our state tracking match the hardware more closely, and avoids having to justify everwhere why uv_wm[] is being ignored. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: Extract skl_allocate_plane_ddb_nv12()Ville Syrjälä
Extract skl_allocate_plane_ddb_nv12() as the compute counterpart to skl_check_wm_level_nv12(). Mainly to hide some of the clutter from skl_crtc_allocate_plane_ddb(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: s/skl_check_nv12_wm_level()/skl_check_wm_level_nv12()/Ville Syrjälä
Rename skl_check_nv12_wm_level() to skl_check_wm_level_nv12(). There will be a sort of DDB counterparts to skl_check_wm_level*(), and putting the "nv12" part to the end will allow consistent naming. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: Reorder the arguments to skl_allocate_plane_ddb()Ville Syrjälä
Group the ddb and data_rate together in the skl_allocate_plane_ddb() arguments. Upcoming changes will adjust the UV plane handling and keeing the ddb allocation and the data rate used to calculate it together will help with clarity. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915/wm: Nuke is_planar from skl+ wm structuresVille Syrjälä
We don't need is_planar in either the actual watermarks or the wm_params structure used during the wm computation. Get rid of both. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260319114034.7093-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-21drm/i915: Skip redundant NV12 plane unlinkingVille Syrjälä
plane_atomic_check() will already have unlinked the old NV12 planes by the time icl_check_nv12_planes() gets called. Drop the redundant second unlinking. Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260316163953.12905-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2026-03-21drm/i915: Relocate unlink_nv12_plane()Ville Syrjälä
Move unlink_nv12_plane() ahead of its first caller to avoid the forward declaration. Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260316163953.12905-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2026-03-21drm/i915: Unlink NV12 planes earlierVille Syrjälä
unlink_nv12_plane() will clobber parts of the plane state potentially already set up by plane_atomic_check(), so we must make sure not to call the two in the wrong order. The problem happens when a plane previously selected as a Y plane is now configured as a normal plane by user space. plane_atomic_check() will first compute the proper plane state based on the userspace request, and unlink_nv12_plane() later clears some of the state. This used to work on account of unlink_nv12_plane() skipping the state clearing based on the plane visibility. But I removed that check, thinking it was an impossible situation. Now when that situation happens unlink_nv12_plane() will just WARN and proceed to clobber the state. Rather than reverting to the old way of doing things, I think it's more clear if we unlink the NV12 planes before we even compute the new plane state. Cc: stable@vger.kernel.org Reported-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Closes: https://lore.kernel.org/intel-gfx/20260212004852.1920270-1-khaled.almahallawy@intel.com/ Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Fixes: 6a01df2f1b2a ("drm/i915: Remove pointless visible check in unlink_nv12_plane()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260316163953.12905-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2026-03-20drm/xe: Fix format specifier for printing pointer differencesNathan Chancellor
GCC and clang warn (or error with CONFIG_WERROR=y / W=e) several times when targeting 32-bit platforms along the lines of drivers/gpu/drm/xe/xe_lrc.c: In function 'dump_mi_command': drivers/gpu/drm/xe/xe_lrc.c:1921:40: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'int' [-Werror=format=] 1921 | drm_printf(p, "LRC[%#5lx] = [%#010x] MI_NOOP (%d dwords)\n", | ~~~~^ | | | long unsigned int | %#5x 1922 | dw - num_noop - start, inst_header, num_noop); | ~~~~~~~~~~~~~~~~~~~~~ | | | int drivers/gpu/drm/xe/xe_lrc.c:1922:7: error: format specifies type 'unsigned long' but the argument has type '__ptrdiff_t' (aka 'int') [-Werror,-Wformat] 1921 | drm_printf(p, "LRC[%#5lx] = [%#010x] MI_NOOP (%d dwords)\n", | ~~~~~ | %#5tx 1922 | dw - num_noop - start, inst_header, num_noop); | ^~~~~~~~~~~~~~~~~~~~~ Use the '%tx' specifier for printing pointer differences, which clears up the warnings for 32-bit platforms while introducing no regressions for 64-bit platforms. Fixes: 65fcf19cb36b ("drm/xe: Include running dword offset in default_lrc dumps") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260316-drm-xe-fix-32-bit-wformat-ptrdiff-v1-1-0108b10b2b6b@kernel.org Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-03-21Merge tag 'drm-xe-fixes-2026-03-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - A number of teardown fixes (Daniele, Matt Brost, Zhanjun, Ashutosh) - Skip over non-leaf PTE for PRL generation (Brian) - Fix an unitialized variable (Umesh) - Fix a missing runtime PM reference (Sanjay) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/abxj4_dBHYBiSvDG@fedora
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 14:09:56 +0000