linux-stable.git/drivers/gpu/drm/v3d, branch master

BackMerge tag 'v7.2' into drm-next

2026-08-20T00:58:44+00:00

Linux 7.2

There was a lot of conflicts this round between fixes and next,
and I'd like to get the merge resolutions that we have in drm-tip.

Signed-off-by: Dave Airlie

Revert "drm/v3d: Remove drm_sched_init_args->num_rqs usage"

2026-08-11T16:34:01+00:00

This reverts commit a1bf9381fc62f3c4e26a2caedb8317046383a559.

Signed-off-by: Tvrtko Ursulin 
Cc: Luke.Wildhardt@proton.me
Cc: Matthew Brost 
Cc: Danilo Krummrich 
Cc: Philipp Stanner 
Cc: Christian König 
Signed-off-by: Tvrtko Ursulin 
Link: https://lore.kernel.org/r/20260811163139.99746-4-tvrtko.ursulin@igalia.com

drm/v3d: Serialize the scheduler timeout handlers

2026-08-02T21:39:20+00:00

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

drm/v3d: Idle AXI transactions before disabling the clock on suspend

2026-07-22T13:36:43+00:00

Currently, v3d_power_suspend() removes the GPU clock without first
quiescing the GPU's memory interface (AXI). If the clock is cut while the
core still has outstanding AXI transactions in flight, the hardware is
frozen mid-transaction. That corrupted state survives the power cycle, and
the first job submitted after the next resume will cause a GPU hang
accompanied by an L2T "pte invalid" MMU fault.

The hardware already provides a safe-powerdown sequence for this: request
the GMP to stop and wait for outstanding reads/writes to drain
(v3d_idle_axi()), plus the GCA safe shutdown on pre-4.1 HW
(v3d_idle_gca()). The driver implements both, but the runtime PM support
added later never invoked them when powering the GPU down.

Perform the safe-powerdown sequence in v3d_power_suspend() before
disabling the clock, while the core is still powered.

Link: https://github.com/raspberrypi/linux/issues/7443
Link: https://github.com/raspberrypi/linux/issues/7488
Fixes: 458f2a712ab4 ("drm/v3d: Introduce Runtime Power Management")
Reviewed-by: Iago Toral Quiroga 
Link: https://patch.msgid.link/20260718-v3d-pm-axi-transactions-v1-2-4ecd7729ed70@igalia.com
Signed-off-by: Maíra Canal

drm/v3d: Reach the GMP through the hub registers on V3D 7.x

2026-07-22T13:34:43+00:00

v3d_idle_axi() drains the GPU's memory interface for a safe powerdown by
using the V3D_GMP_CFG register. It reached both registers with the macros
V3D_CORE_READ and V3D_CORE_WRITE.

On V3D 7.x the GMP is no longer a per-core block; it lives in the hub
register region. Reaching it through the per-core register block addresses
the wrong region.

Select the hub accessors (V3D_{READ,WRITE}) for the GMP on V3D 7.x and
keep the per-core path for earlier generations.

Cc: stable@vger.kernel.org
Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x")
Link: https://patch.msgid.link/20260718-v3d-pm-axi-transactions-v1-1-4ecd7729ed70@igalia.com
Reviewed-by: Iago Toral Quiroga 
Signed-off-by: Maíra Canal

drm/v3d: Associate BOs with every job that accesses them

2026-07-18T13:28:44+00:00

A submission can expand into a chain of jobs (e.g. bin + render + cache
clean). Implicit synchronization in v3d_submit_lock_reservations() is gated
on each job's bo[], but the BO list was only ever attached to the last job
of the chain. When that last job is a trailing CACHE_CLEAN job, the job
that actually consumes the BOs (that is, a RENDER or CSD job) was left with
bo_count == 0 and picked up no implicit dependencies. It could therefore
be dispatched to the hardware and read a BO while another context was still
writing it, leading to data corruption.

Attach the BOs to the job that consumes them, so (1) it acquires the
correct implicit dependencies during reservation locking and (2) they are
kept mapped until the end of the submission. Give it references to all
consuming job's BOs through v3d_job_reference_bos() instead of looking the
handles up a second time; that avoids a redundant lookup and guarantees
both jobs reference the exact same objects.

As the CACHE_CLEAN job now carries a BO array as well, add a per-job
`has_implicit_dep` flag so that only the consuming jobs take implicit
dependencies. The CACHE_CLEAN job (a global flush) and the BIN job (binning
waiting on another context is not a realistic scenario) are excluded.

Fixes: dffa9b7a78c4 ("drm/v3d: Add missing implicit synchronization.")
Reviewed-by: Iago Toral Quiroga 
Link: https://patch.msgid.link/20260710114734.2731000-1-mcanal@igalia.com
Signed-off-by: Maíra Canal

drm/v3d: bound CPU-job query writes to their destination BO

2026-07-08T12:15:42+00:00

The V3D_SUBMIT_CPU CPU jobs take user-supplied offsets and indices and
consume them at exec time without checking that the accesses stay inside
their BO:

  - TIMESTAMP_QUERY and RESET_TIMESTAMP_QUERY write one u64 per query
    into bo[0] at a fully user-controlled per-query offset.
  - COPY_TIMESTAMP_QUERY copies one u64 per query into bo[0] at
    offset + i * stride, and reads each result from a user-controlled
    offset in the source bo[1].
  - COPY_PERFORMANCE_QUERY writes nperfmons * DRM_V3D_MAX_PERF_COUNTERS
    counter slots plus an availability slot into bo[0] at the same
    geometry.
  - INDIRECT_CSD reads three u32 work-group counts from bo[0] at a
    user-controlled offset, then writes each count back into the
    indirect BO at a user-controlled u32 index (wg_uniform_offsets[]).

A render-node user (DRM_RENDER_ALLOW, no master, no capability) can make
the handlers read or write past a BO's vmap mapping.

Validate the full access extent against the BO size once the BOs are
looked up, before the job is queued, rejecting out-of-range geometry
with -EINVAL. The copy extent offset + (count - 1) * stride + write_size
is computed in u64, mirroring the u8 * pointer arithmetic in the
executors: (count - 1) * stride is a u32 * u32 product that is exact in
u64, so one overflow check on the total guards the bound. The
performance slot count and the bare timestamp, copy-source and indirect
offsets are computed in u64 the same way, so a user value cannot wrap
the comparison.

Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job")
Fixes: 9ba0ff3e083f ("drm/v3d: Create a CPU job extension for the timestamp query job")
Fixes: 34a101e64296 ("drm/v3d: Create a CPU job extension for the reset timestamp job")
Fixes: 6745f3e44a20 ("drm/v3d: Create a CPU job extension to copy timestamp query to a buffer")
Fixes: 209e8d2695ee ("drm/v3d: Create a CPU job extension for the copy performance query job")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito 
Reviewed-by: Maíra Canal 
Signed-off-by: Maíra Canal 
Link: https://patch.msgid.link/20260707221334.3854433-1-michael.bommarito@gmail.com

drm/v3d: Reject invalid indirect BO handle in indirect CSD setup

2026-07-07T21:52:13+00:00

v3d_get_cpu_indirect_csd_params() looks up the indirect buffer object
from a userspace-supplied handle but never checks the result. A bogus
or stale handle makes drm_gem_object_lookup() return NULL, which is
then stored in info->indirect and only dereferenced later when the
indirect CSD job runs, turning a userspace mistake into a NULL pointer
dereference in the kernel.

Bail out with -ENOENT as soon as the lookup fails, so the bad handle is
rejected at submission time.

Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job")
Reviewed-by: Iago Toral Quiroga 
Signed-off-by: Maíra Canal 
Link: https://patch.msgid.link/20260703-v3d-cpu-job-fixes-v3-2-bc51b1f3eeb5@igalia.com

drm/v3d: Use write_to_buffer() helper in performance query copy

2026-07-07T21:21:42+00:00

The copy of performance query results to the output buffer open-codes
the 32-bit/64-bit selection with two nearly identical loops. As the
write_to_buffer() helper already encapsulates the do_64bit decision,
use it instead of open-coding it.

Reviewed-by: Iago Toral Quiroga 
Link: https://patch.msgid.link/20260703-v3d-cpu-job-fixes-v3-3-bc51b1f3eeb5@igalia.com
Signed-off-by: Maíra Canal

drm/v3d: Serialize jobs across queues when a perfmon is attached

2026-07-07T19:58:46+00:00

A non-global perfmon is meant to count events generated by a specific
submission, but the scheduler can run jobs from different queues
concurrently on the same V3D core. Without explicit serialization, an
unrelated job running in parallel with a perfmon-carrying job pollutes
the counters and generates unusable results.

To address such issue, we must enforce cross-queue serialization when we
detect a perfmon-carrying submission. It's possible to implement
serialization by enforcing two rules:

  1. A job that carries a non-global perfmon must wait for every job
    currently in-flight across all HW queues to finish.

  2. While a perfmon-carrying job is still in-flight, all subsequently
    submitted jobs must wait for it.

Note that serialization is not needed in the global perfmon case, as the
global perfmon tracks activity from all jobs, so concurrency is desirable.

Therefore, check if serialization is needed during job submission and if
so, attach fence dependences to enforce cross-queue serialization.

Reviewed-by: Iago Toral Quiroga 
Link: https://patch.msgid.link/20260706-v3d-perfmon-lifetime-v4-2-d7b312ff2c83@igalia.com
Signed-off-by: Maíra Canal