kernel/linux.git/drivers/gpu/drm/imagination, branch master

BackMerge tag 'v7.0-rc6' into drm-next

2026-03-30T21:51:02+00:00

Linux 7.0-rc6 Requested by a few people on irc to resolve conflicts in other tress. Signed-off-by: Dave Airlie

drm/imagination: Implement handling of context reset notification

2026-03-24T08:22:21+00:00

The firmware will send the context reset notification message as part of handling hardware recovery (HWR) events deecoding the message and printing via drm_info(). This eliminates the "Unknown FWCCB command" message that was previously printed. Co-developed-by: Sarah Walker Signed-off-by: Sarah Walker Signed-off-by: Alexandru Dadu Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260323-b4-firmware-context-reset-notification-handling-v3-3-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Switch reset_reason fields from enum to u32

2026-03-24T08:19:59+00:00

Update the reset_reason fwif structure fields from enum to u32 to remove any ambiguity from the interface (enum is not a fixed size thus is unfit for the purpose of the data type). Fixes: a26f067feac1f ("drm/imagination: Add FWIF headers") Signed-off-by: Alexandru Dadu Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260323-b4-firmware-context-reset-notification-handling-v3-2-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Add missing rogue context reset reasons

2026-03-24T08:19:59+00:00

Update the context reset reason enum with the missing reset reasons in the 6-11 value gap: - CDM Mission/safety checksum mismatch; - TRP checksum mismatch; - GPU ECC error (corrected, OK); - GPU ECC error (uncorrected, HWR); - FW ECC error (corrected, OK); - FW ECC error (uncorrected, ERR); Co-developed-by: Sarah Walker Signed-off-by: Sarah Walker Signed-off-by: Alexandru Dadu Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260323-b4-firmware-context-reset-notification-handling-v3-1-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Skip 2nd thread DM association for non META Firmware

2026-03-23T15:02:05+00:00

Only a META firmware can have two threads. Signed-off-by: Brajesh Gupta Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260313-b4-staging-layout_mars_base-v2-2-9e3c251d278e@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Improve firmware power off for layout_mars config

2026-03-23T15:01:05+00:00

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 Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260313-b4-staging-layout_mars_base-v2-1-9e3c251d278e@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Disable interrupts before suspending the GPU

2026-03-17T14:27:42+00:00

This is an additional safety layer to ensure no accesses to the GPU registers can be made while it is powered off. While we can disable IRQ generation from GPU, META firmware, MIPS firmware and for safety events, we cannot do the same for the RISC-V firmware. To keep a unified approach, once the firmware has completed its power off sequence, disable IRQs for the while GPU at the kernel level instead. Signed-off-by: Alessio Belle Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260310-drain-irqs-before-suspend-v1-2-bf4f9ed68e75@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Synchronize interrupts before suspending the GPU

2026-03-17T14:27:42+00:00

The runtime PM suspend callback doesn't know whether the IRQ handler is in progress on a different CPU core and doesn't wait for it to finish. Depending on timing, the IRQ handler could be running while the GPU is suspended, leading to kernel crashes when trying to access GPU registers. See example signature below. In a power off sequence initiated by the runtime PM suspend callback, wait for any IRQ handlers in progress on other CPU cores to finish, by calling synchronize_irq(). At the same time, remove the runtime PM resume/put calls in the threaded IRQ handler. On top of not being the right approach to begin with, and being at the wrong place as they should have wrapped all GPU register accesses, the driver would hit a deadlock between synchronize_irq() being called from a runtime PM suspend callback, holding the device power lock, and the resume callback requiring the same. Example crash signature on a TI AM68 SK platform: [ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] Tainted: [M]=MACHINE_CHECK [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pc : pvr_riscv_irq_pending+0xc/0x24 [ 337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310 [ 337.241282] sp : ffff800085b0bd30 [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10 [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000 [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30 [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00 [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003 [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000 [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000 [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] Tainted: [M]=MACHINE_CHECK [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241345] Call trace: [ 337.241348] show_stack+0x18/0x24 (C) [ 337.241357] dump_stack_lvl+0x60/0x80 [ 337.241364] dump_stack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] add_taint+0x0/0xbc [ 337.241384] arm64_serror_panic+0x70/0x80 [ 337.241389] do_serror+0x3c/0x74 [ 337.241392] el1h_64_error_handler+0x30/0x48 [ 337.241400] el1h_64_error+0x6c/0x70 [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P) [ 337.241410] irq_thread_fn+0x2c/0xb0 [ 337.241416] irq_thread+0x170/0x334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] ret_from_fork+0x10/0x20 [ 337.241434] SMP: stopping secondary CPUs [ 337.241451] Kernel Offset: disabled [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b [ 337.241456] Memory Limit: none [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Fixes: 96822d38ff57 ("drm/imagination: Handle Rogue safety event IRQs") Cc: stable@vger.kernel.org # see patch description, needs adjustments for < 6.16 Signed-off-by: Alessio Belle Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260310-drain-irqs-before-suspend-v1-1-bf4f9ed68e75@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Fix deadlock in soft reset sequence

2026-03-17T14:27:04+00:00

The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disable_irq() which internally waits for IRQ handlers, i.e. itself, to complete. Use disable_irq_nosync() during a soft reset instead. Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Cc: stable@vger.kernel.org Signed-off-by: Alessio Belle Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260309-fix-soft-reset-v1-1-121113be554f@imgtec.com Signed-off-by: Matt Coster

drm/gem-shmem: Track folio accessed/dirty status in vmap

2026-03-11T08:33:43+00:00

On successful vmap, set the page_mark_accessed_on_put and _dirty_on_put flags in the gem-shmem object. Signals that the contained pages require LRU and dirty tracking when they are being released back to SHMEM. Clear these flags on put, so that the buffer remains quiet until the next call to vmap. There's no means of handling dirty status in vmap as there's no write-only mapping available. Both flags, _accessed_on_put and _dirty_on_put, have always been part of the gem-shmem object, but never used much. So most drivers did not track the page status correctly. Only the v3d and imagination drivers make limited use of _dirty_on_put. In the case of imagination, move the flag setting from init to cleanup. This ensures writeback of modified pages but does not interfere with the internal vmap/vunmap calls. V3d already implements this behaviour. Signed-off-by: Thomas Zimmermann Reviewed-by: Boris Brezillon # gem-shmem Acked-by: Frank Binns # imagination Tested-by: Frank Binns # imagination Link: https://patch.msgid.link/20260227114509.165572-7-tzimmermann@suse.de