On Tue, 21 Nov 2023 18:08:44 +0100 Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > non-linefetch access, but it might be caused by a register access after > > the clock or power domain driving the register bank has been disabled. > > The following diff might help validate this theory. If that works, we > > probably want to make sure we synchronize IRQs before disabling in the > > suspend path. > > > > --->8--- > > diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h b/drivers/gpu/drm/panfrost/panfrost_regs.h > > index 55ec807550b3..98df66e5cc9b 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_regs.h > > +++ b/drivers/gpu/drm/panfrost/panfrost_regs.h > > @@ -34,8 +34,6 @@ > > (GPU_IRQ_FAULT |\ > > GPU_IRQ_MULTIPLE_FAULT |\ > > GPU_IRQ_RESET_COMPLETED |\ > > - GPU_IRQ_POWER_CHANGED |\ > > - GPU_IRQ_POWER_CHANGED_ALL |\ > > This helped, at least for this issue (next-20231121). Much later in > user-space boot I have lockups: > watchdog: BUG: soft lockup - CPU#4 stuck for 26s! [kworker/4:1:61] Hm, if this doesn't happen with "drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()" reverted, it might be related to the issue Angelo was describing, though I'd expect it to lead to job timeouts, not the sort of soft lockup reported here. > > [ 56.329224] smp_call_function_single from > __sync_rcu_exp_select_node_cpus+0x29c/0x78c > [ 56.337111] __sync_rcu_exp_select_node_cpus from > sync_rcu_exp_select_cpus+0x334/0x878 > [ 56.344995] sync_rcu_exp_select_cpus from wait_rcu_exp_gp+0xc/0x18 > [ 56.351231] wait_rcu_exp_gp from process_one_work+0x20c/0x620 > [ 56.357038] process_one_work from worker_thread+0x1d0/0x488 > [ 56.362668] worker_thread from kthread+0x104/0x138 > [ 56.367521] kthread from ret_from_fork+0x14/0x28 > > But anyway the external abort does not appear. Thanks for testing! As I said in my previous reply, I think the proper fix for this particular issue would be to mask all panfrost IRQs (writing 0 to xxx_INT_MASK) + call synchronize_irq() from panfrost_device_suspend(), to make sure pending interrupts are flushed and the handlers can't be called again (or at least not with real interrupts to process, if the IRQ line is shared) until the device is resumed. FWIW, after fighting with annoying bugs in the interrupt handling logic and its interactions with runtime PM, I've decided to automate some of this in panthor [1]. Also made the power on/off logic generic [2], with macros to allow powering on/off specific blocks. Not saying we should do that in panfrost, just posting it as a reference, in case someone is interested. [1]https://gitlab.freedesktop.org/bbrezillon/linux/-/blob/panthor-v3+rk3588/drivers/gpu/drm/panthor/panthor_device.h?ref_type=heads#L279 [2]https://gitlab.freedesktop.org/bbrezillon/linux/-/blob/panthor-v3+rk3588/drivers/gpu/drm/panthor/panthor_gpu.c?ref_type=heads#L279 [3]https://gitlab.freedesktop.org/bbrezillon/linux/-/blob/panthor-v3+rk3588/drivers/gpu/drm/panthor/panthor_gpu.h?ref_type=heads#L24
