kernel/linux.git/drivers/gpu/drm/imagination/pvr_device.c, branch linux-7.0.y

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: Warn or error on unsupported hardware

2026-01-19T11:20:22+00:00

Gate the use of unsupported hardware behind a new module parameter (exp_hw_support). Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260113-device-support-info-v1-6-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster

drm/imagination: KUnit test for pvr_gpuid_decode_string()

2026-01-19T11:20:22+00:00

This is a nice self-contained function to serve as the basis of our first KUnit tests. Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260113-device-support-info-v1-5-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Add gpuid module parameter

2026-01-19T11:20:22+00:00

The "gpuid" module parameter is used to override the gpuid read from a hardware register and is useful for testing the loading of different firmware (including processing of the firmware header) without having the hardware to hand. Signed-off-by: Alexandru Dadu Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260113-device-support-info-v1-4-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Simplify module parameters

2026-01-19T11:20:21+00:00

We had a whole load of bloaty infrastructure to deal with module parameters in a way that's wholly unnecessary. Strip it all back to basics to make adding new parameters less of a headache. Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260113-device-support-info-v1-1-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Fix reference to devm_platform_get_and_ioremap_resource()

2025-10-31T14:34:53+00:00

The call to devm_platform_ioremap_resource() was replaced by a call to devm_platform_get_and_ioremap_resource(), but the comment referring to the function's possible returned error codes was not updated. Fixes: 927f3e0253c11276 ("drm/imagination: Implement MIPS firmware processor and MMU support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Matt Coster Link: https://patch.msgid.link/2266514318480d17f52c7e5e67578dae6827914e.1761745586.git.geert+renesas@glider.be Signed-off-by: Matt Coster

drm/imagination: Use pwrseq for TH1520 GPU power management

2025-09-01T11:11:00+00:00

Update the Imagination PVR DRM driver to leverage the pwrseq framework for managing the complex power sequence of the GPU on the T-HEAD TH1520 SoC. To cleanly separate platform-specific logic from the generic driver, this patch introduces an `init` callback to the `pwr_power_sequence_ops` struct. This allows for different power management strategies to be selected at probe time based on the device's compatible string. A `pvr_device_data` struct, associated with each compatible in the of_device_id table, points to the appropriate ops table (manual or pwrseq). At probe time, the driver now calls the `->init()` op. For pwrseq-based platforms, this callback calls `devm_pwrseq_get("gpu-power")`, deferring probe if the sequencer is not yet available. For other platforms, it falls back to the existing manual clock and reset handling. The runtime PM callbacks continue to call the appropriate functions via the ops table. Signed-off-by: Michal Wilczynski Reviewed-by: Ulf Hansson Reviewed-by: Matt Coster Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-1-af656f7cc6c3@samsung.com Signed-off-by: Matt Coster

drm/imagination: Add reset controller support for GPU initialization

2025-04-24T10:08:48+00:00

All IMG Rogue GPUs include a reset line that participates in the power-up sequence. On some SoCs (e.g., T-Head TH1520 and Banana Pi BPI-F3), this reset line is exposed and must be driven explicitly to ensure proper initialization. On others, such as the currently supported TI SoC, the reset logic is handled in hardware or firmware without exposing the line directly. In platforms where the reset line is externally accessible, if it is not driven correctly, the GPU may remain in an undefined state, leading to instability or performance issues. This commit adds a dedicated reset controller to the drm/imagination driver. By managing the reset line (where applicable) as part of normal GPU bring-up, the driver ensures reliable initialization across platforms regardless of whether the reset is controlled externally or handled internally. Signed-off-by: Michal Wilczynski Reviewed-by: Matt Coster Link: https://lore.kernel.org/r/20250418-apr_18_reset_img-v6-2-85a06757b698@samsung.com Signed-off-by: Matt Coster

drm/imagination: Remove firmware enable_reg

2025-04-15T11:21:51+00:00

After a previous commit ("drm/imagination: Mask GPU IRQs in threaded handler"), this register is now only used to enable firmware interrupts at start-of-day. This is, however, unnecessary since they are enabled by default. In addition, the soon-to-be-added RISC-V firmware processors do not have an equivalent register. Reviewed-by: Frank Binns Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-8-eda620c5865f@imgtec.com Signed-off-by: Matt Coster

drm/imagination: Handle Rogue safety event IRQs

2025-04-15T11:21:50+00:00

Extend interrupt handling logic to check for safety event IRQs, then clear and handle them in the IRQ handler thread. Safety events need to be checked and cleared with a different set of GPU registers than those the IRQ handler has been using so far. Only two safety events need to be handled on the host: FW fault (ECC error correction or detection) and device watchdog timeout. Handling right now simply consists of clearing any error and logging the event. If either of these events results in an unrecoverable GPU or FW, the driver will eventually attempt to recover from it e.g. via pvr_power_reset(). Note that Rogue GPUs may send interrupts to the host for all types of safety events, not just the two above. For events not handled by the host, clearing the associated interrupt is sufficient. Signed-off-by: Alessio Belle Reviewed-by: Frank Binns Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-7-eda620c5865f@imgtec.com Signed-off-by: Matt Coster