Re: [PATCH v2 4/9] drm/panthor: Implement optional reset

[Marek Vasut <marek.vasut@mailbox.org>]

On 9/4/25 8:22 AM, Boris Brezillon wrote:
> Hello Marek,

Hello Boris,

>> Can you please test the following patch (also attached) on one of your
>> devices, and tell me what the status is at the end . The diff sets the
>> GLB_HALT bit and then clears it again, which I suspect should first halt
>> the GPU and (this is what I am unsure about) then again un-halt/resume
>> the GPU ?
> 
> It doesn't work like that. What you're describing is like executing
> "shutdown" on your terminal and then typing "boot" on the keyboard
> after your computer has been shut down.

That is what I thought , yes .

I think what I am looking for is the "power key" .

[...]

>> That means, the GPU remains halted at the end, even if the "GLB_HALT"
>> bit is cleared before the last print. The clearing of GLB_HALT is also
>> what panthor_fw_post_reset() does.
> 
> After the halt has been processed by the FW, the memory region where
> you check the halt status again is inert, since the micro-controller
> (MCU) supposed to update those bits is off at this point. The FW
> interface is really just a shared memory region between the CPU and
> MCU, nothing more.

Right.

>> I suspect the extra soft reset I did before "un-halted" the GPU and
>> allowed it to proceed.
> 
> Hm, not quite. I mean, you still need to explicitly boot the MCU after
> a reset, which is what the write to MCU_CONTROL [1] does. What the
> soft-reset does though, is reset all GPU blocks, including the MCU.
> This means the MCU starts from a fresh state when you reach [1].

I have a feeling the write to MCU_CONTROL does nothing in my case.

Is there some way to probe the MCU state before/after setting GLB_HALT, 
and also before/after the MCU_CONTROL write, using 
gpu_read()/gpu_write() register operations, to find out what is going on 
with the MCU at each point ?