Messages in this thread | | | Date | Wed, 22 Nov 2023 10:29:45 +0100 | Subject | Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off() | From | Krzysztof Kozlowski <> |
| |
On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
>>>>> >>>> >>>> Hey Krzysztof, >>>> >>>> This is interesting. It might be about the cores that are missing from the partial >>>> core_mask raising interrupts, but an external abort on non-linefetch is strange to >>>> see here. >>> >>> I've seen such external aborts in the past, and the fault type has >>> often been misleading. It's unlikely to have anything to do with a >> >> Yeah, often accessing device with power or clocks gated. >> > > Except my commit does *not* gate SoC power, nor SoC clocks 🙂
It could be that something (like clocks or power supplies) was missing on this board/SoC, which was not critical till your patch came.
> > What the "Really power off ..." commit does is to ask the GPU to internally power > off the shaders, tilers and L2, that's why I say that it is strange to see that > kind of abort. > > The GPU_INT_CLEAR GPU_INT_STAT, GPU_FAULT_STATUS and GPU_FAULT_ADDRESS_{HI/LO} > registers should still be accessible even with shaders, tilers and cache OFF. > > Anyway, yes, synchronizing IRQs before calling the poweroff sequence would also > work, but that'd add up quite a bit of latency on the runtime_suspend() call, so > in this case I'd be more for avoiding to execute any register r/w in the handler > by either checking if the GPU is supposed to be OFF, or clearing interrupts, which > may not work if those are generated after the execution of the poweroff function. > Or we could simply disable the irq after power_off, but that'd be hacky (as well). > > > Let's see if asking to poweroff *everything* works:
Worked.
Best regards, Krzysztof
| |