linux-stable.git/drivers/gpu, branch v7.1.9

Revert "drm/amdgpu: fix aperture mapping leak"

2026-08-19T16:20:28+00:00

commit b96c529cd2551b78316a4afa3237b2ed96ba03c8 upstream.

devres teardown is LIFO. The aperture devres node was registered after
the DRM device node, so devres_release_all() unmaps the aperture before
the DRM device release callback fires amdgpu_device_fini_sw(). IP
sw_fini callbacks (e.g. vcn_v4_0_sw_fini) write to fw_shared through a
pointer derived from aper_base_kaddr, causing a kernel page fault on
probe failure / rollback:

  BUG: unable to handle page fault ... PMD 0
  RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu]
  Call Trace:
    amdgpu_device_fini_sw
    amdgpu_driver_release_kms
    devm_drm_dev_init_release
    devres_release_all

This reverts commit d871e99879cb5fd1fa798b006b4888887e63a17a.

Fixes: d871e99879cb ("drm/amdgpu: fix aperture mapping leak")
Reported-by: Yuansheng Mao 
Signed-off-by: Asad Kamal 
Reviewed-by: Lijo Lazar 
Reviewed-by: Hawking Zhang 
Signed-off-by: Alex Deucher 
(cherry picked from commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/v3d: Serialize the scheduler timeout handlers

2026-08-19T16:20:27+00:00

commit 4da94744707b27a3ae1197bdd7127da4505dc5b1 upstream.

V3D exposes several independent hardware queues (BIN, RENDER, TFU and
CSD) but has only a single, global reset. A timeout on any one queue
therefore has to stop, reset and restart the schedulers of every other
queue as well. That makes concurrent timeout handlers unsafe.

`reset_lock` was never able to make them safe, as a driver-side lock can
only cover the driver's &drm_sched_backend_ops.timedout_job callback.
The scheduler handles the timed out job and its pending list around that
callback, outside of the driver's control, so a global reset triggered
by one queue can still interfere with another queue that is in the
middle of handling a timeout of its own.

Consequently, if a reset happens in the CSD queue while a CL-intensive
application is running, the global reset stops and restarts the CL
queue's scheduler while that queue is handling a timeout of its own. As
drm_sched_stop() and drm_sched_start() subtract and add the credits of
every job sitting on the pending list of the scheduler they are called
on, and as the CL queue's handler concurrently takes its job off that
same list and puts it back, the stop and the start no longer see the
same set of jobs. The CL queue is left with more credits in flight than
its limit:

[  327.302739] ------------[ cut here ]------------
[  327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched]
[  327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT
[  327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[  327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]
[  327.302984] Call trace:
[  327.302987]  drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P)
[  327.302997]  process_scheduled_works+0x180/0x3d0
[  327.303010]  worker_thread+0x268/0x3e8
[  327.303016]  kthread+0x140/0x250
[  327.303022]  ret_from_fork+0x10/0x20
[  327.303031] ---[ end trace 0000000000000000 ]---

From that point on, the credit count of the CL queue is broken, causing
a complete GPU hang and UI freeze.

The DRM scheduler already provides a mechanism to serialize the timeout
handlers of different schedulers: an ordered workqueue passed as
drm_sched_init()'s @timeout_wq parameter. By default, each scheduler
queues its timeout work on the system workqueue, which runs the handlers
concurrently. Give all of the queues a shared ordered workqueue instead,
as recommended by the DRM scheduler documentation for hardware that has
distinct queues but resets globally.

Cc: stable@vger.kernel.org # 6.15
Reviewed-by: Iago Toral Quiroga 
Link: https://patch.msgid.link/20260728-v3d-order-global-reset-v1-1-e47be838158d@igalia.com
Signed-off-by: Maíra Canal 
Signed-off-by: Greg Kroah-Hartman

Revert "drm/amd/display: Fix backlight max_brightness to match exported range"

2026-08-19T16:20:24+00:00

This reverts commit 1191285ecb4233e5bf907da7e9394d7999055566.

This patch is apparently missing a dependency from 7.2 as users have not
reported any regressions with 7.2-rc, but there are regressions on 7.1.

The regression manifests as inconsistent lower brightness at the top end
(e.g., around 98%).

Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5562
Signed-off-by: Alex Deucher 
Cc: Thorsten Leemhuis 
Cc: Sergio Callegari 
Cc: Mario Limonciello 
Signed-off-by: Sasha Levin

drm/xe/uc: Apply RCS/CCS yield policy to SR-IOV VFs

2026-08-19T16:20:18+00:00

[ Upstream commit d1643db3b037b57f2af7f85c3821d6fe69c492f6 ]

VFs were missing the call to apply the global scheduling policy.
Call xe_guc_submit_enable() during vf_uc_load_hw() to ensure VFs
get the same policy enforcement as PF.

Fixes: 26caeae9fb48 ("drm/xe/guc: Set RCS/CCS yield policy")
Suggested-by: Michal Wajdeczko 
Signed-off-by: Marcin Bernatowicz 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Reviewed-by: Daniele Ceraolo Spurio 
Link: https://patch.msgid.link/20260709075945.1337660-1-marcin.bernatowicz@linux.intel.com
Signed-off-by: Michał Winiarski 
(cherry picked from commit f09360e857130f7ab7f069e2421e6b4a6e502531)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Sasha Levin

drm/xe: Fix memory leak in exec_queue_set_hang_replay_state()

2026-08-19T16:20:18+00:00

[ Upstream commit c5f500161709f27719701334190dff2325868ef0 ]

The q->replay_state is blindly overwritten, which can potentially leak
memory that was previously allocated by vmemdup_user().
Return an error if q->replay_state is not empty.

Discovered using AI-assisted static analysis confirmed by Intel Product
Security.

Reported-by: Martin Hodo 
Fixes: 1026c1a73a96 ("drm/xe: Implement DRM_XE_EXEC_QUEUE_SET_HANG_REPLAY_STATE")
Reviewed-by: Matthew Brost 
Link: https://patch.msgid.link/20260624111421.1258364-1-michal.winiarski@intel.com
Signed-off-by: Michał Winiarski 
(cherry picked from commit f6b6cc1118bdbc4265fa8b3bdf8565b26f13e56e)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Sasha Levin

drm/bridge: ps8640: propagate AUX transfer register errors

2026-08-19T16:20:14+00:00

[ Upstream commit 20697ecb299cd77b4cf8b28f655e56606b0472d8 ]

ps8640_aux_transfer_msg() programs the AUX address registers, starts the
AUX transfer, waits for SWAUX_SEND to clear, and reads the AUX status
register. Several of those regmap operations have return values, but the
function only checks a stale ret after the status read.

Propagate failures from the address write, transfer start, completion
poll, and status read. This avoids returning a transfer length when the
bridge register transaction or AUX completion wait failed.

Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
Signed-off-by: Pengpeng Hou 
Reviewed-by: Douglas Anderson 
Signed-off-by: Douglas Anderson 
Link: https://patch.msgid.link/20260723103509.2-ps8640-v2-pengpeng@iscas.ac.cn
Signed-off-by: Sasha Levin

drm/amd/display: Check for tg ops in dce110_set_avmute

2026-08-19T16:20:12+00:00

[ Upstream commit 3141e3d61469bba2624a91c5e2407f110b33b29e ]

Some older DCE timing generators do not implement is_tg_enabled in
their ops table. Calling it unconditionally when waiting for AV mute
frames causes a NULL pointer dereference on Southern Islands dGPUs
when turning the display off over HDMI.

Check that tg and the required ops exist before waiting for frames.

Fixes: 414da24137ac ("drm/amd/display: Add AV mute wait frames to dce110_set_avmute")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5557
Tested-by: Viktor Jägersküpper 
Signed-off-by: Ray Wu 
Signed-off-by: Alex Deucher 
(cherry picked from commit 2686a0c0aaa07bec2e24131835cf27b5fd4935a5)
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/amd/display: Add AV mute wait frames to dce110_set_avmute

2026-08-19T16:20:12+00:00

[ Upstream commit 443290d70b01e9c35830c300e3247c06581b594c ]

Port the three-frame wait logic from dcn30_set_avmute to
dce110_set_avmute so that older DCN versions (1.0, 2.0) also
wait for GCP packets to be sent out before proceeding.

This ensures HDMI sinks properly process the mute state,
preventing garbled display after link re-establishment.

Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5167
Reviewed-by: Wayne Lin 
Signed-off-by: Ray Wu 
Signed-off-by: Fangzhi Zuo 
Tested-by: Dan Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 414da24137ace80d8c59fefd43ba3ec9f5f854ba)
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/amd/display: Exit idle optimizations before programming

2026-08-09T18:26:58+00:00

[ Upstream commit 8419331e64d92a8de5fc4feef0e305f201fb8b33 ]

[Why]

We need to exit PSR/IPS before programming. Before calling DC for
programming in amdgpu_dm_commit_planes(), there's a
vblank_control_workqueue flush. This waits for IPS and PSR exit. (See
drm_vblank_on/off() > amdgpu_dm_crtc_set_vblank() --queue_work()->
amdgpu_dm_crtc_vblank_control_worker())

Prior to the tagged "Fixes:" change, drm_vblank_get() was called before
the workqueue flush. This ordering ensures that PSR exit occurred before
programming. After the "Fixes:" change, drm_vblank_get() is called after
the workqueue flush, leading to programming while idle optimizations are
still active. This can lead to incorrect flip_pending detection used by
vblank event delivery.

[How]

Split the vblank_get() component of `dm_arm_vblank_event()` into
`dm_arm_vblank_event_pre_programming()`, which is called before
programming. Call it before the vblank_control_workqueue flush.

Includes a drive-by cleanup of prepare_flip_isr(): the only caller is
dm_arm_vblank_event() and it's simple enough to roll-in.

v2: Fix checkpatch formatting warning on
    drm_arm_vblank_event_pre_programming() arg alignment.

Fixes: 48ab86360af1 ("drm/amd/display: check GRPH_FLIP status before sending event")
Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141#note_3583205
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5527
Assisted-by: Codex:gpt-5.6-sol
Assisted-by: Claude:opus-5
Suggested-by: David Weber 
Signed-off-by: Leo Li 
Reviewed-by: Mario Limonciello (AMD) 
Signed-off-by: Alex Deucher 
(cherry picked from commit 05984e29520a28c27f5a2388742c957a6a87ee7a)
(cherry picked from commit 8419331e64d92a8de5fc4feef0e305f201fb8b33)
Signed-off-by: Sasha Levin

drm/amd/display: check GRPH_FLIP status before sending event

2026-08-09T18:26:58+00:00

[ Upstream commit 48ab86360af117123eb1b15e38f068acf3826400 ]

[Why]

After unifying DCN interrupt sources under VUPDATE_NO_LOCK, we have two
remaining issues to clean up:

1. On DCN, flip completion is now delivered from VUPDATE_NO_LOCK
   (dm_crtc_high_irq_handler) instead of GRPH_PFLIP. But VUPDATE_NO_LOCK
   fires every frame, regardless of whether a flip has latched.

2. There is a window during commit where a flip is armed (pflip_status =
   SUBMITTED) but not yet programmed into HW. If the VUPDATE_NO_LOCK
   fires in that window, its handler would deliver a flip event to
   userspace before HW has latched to it. If userspace then renders to
   what it believes is now the back buffer (but HW is still latched to
   it!), it will cause display corruption. This issue seemed to have
   been introduced by:
   commit 1159898a88db ("drm/amd/display: Handle commit plane with no FB.")
   Enabling replay or psr extended the duration of this window, and
   hence made corruption more likely to be observed.

[How]

* Move acrtc->event/pflip_status arming to after
  update_planes_and_stream_adapter() has programmed the flip into HW.
  This closes the window where pflip_status is SUBMITTED but the flip is
  not yet programmed.

* Add dc_get_flip_pending_on_otg(), which reads the HUBP flip-pending
  status straight from HW for the pipe(s) bound to an OTG instance. It
  is keyed only by otg_inst and does not take or mutate a
  dc_plane_state, so it is safe to call from the OTG interrupt handler
  without racing a concurrent commit that may be modifying plane state.

* Optimistically query for flip-pending after programming, in the event
  that HW latched to the new fb between programming start and arming
  event. If it latched, send the vblank event immediately, rather than
  wait for the next vblank IRQ.

* In the VUPDATE_NO_LOCK handler, only deliver flip completion once
  dc_get_flip_pending_on_otg() reports the flip is no longer pending.
  Otherwise leave the flip armed and retry on the next vupdate.

* For DCE, maintain the existing behavior of arming flips before
  programming, and relying on GRPH_FLIP to fire at HW latch.

v2:
* Drop flip_programmed completion object, instead move
  event/pflip_status arming after programming.
* For DCN, optimistically query for flip pending immediately after
  programming, and if it latched, send event right away.

v3:
* Fix event timestamps on optimistic flip latch detection, where it's
  possible for it to run *before* the vupdate IRQ updates the timestamp.
* Add more docstrings for DCN vblank handling.
* Clean up if conditions in dm_arm_vblank_event().
* Code style cleanup on braces surrounding multi-line statements.

Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations")
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141
Assisted-by: Copilot:claude-opus-4.8
Tested-by: Mario Limonciello (AMD) 
Reviewed-by: Mario Limonciello (AMD) 
Signed-off-by: Leo Li 
Signed-off-by: Alex Deucher 
(cherry picked from commit f64a9be5653689ff43e148cd8a6483077488c8e5)
Cc: stable@vger.kernel.org # 8382cd234981: drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin