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 ?
