On 9/4/25 5:20 PM, Boris Brezillon wrote:
On Thu, 4 Sep 2025 16:54:38 +0200
Marek Vasut <marek.va...@mailbox.org> wrote:
On 9/4/25 4:04 PM, Boris Brezillon wrote:
Hello Boris,
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.
I believe it does, otherwise you wouldn't be able to kick the MCU
and get things working until the first runtime suspend happens. I gut
feeling is that there's something fishy in the FW or SoC integration
that causes the FW HALT request to put the MCU/GPU in a bad state
preventing further MCU_CONTROL(AUTO_START) from functioning correctly
after that point.
I wonder who at NXP could chime in ... Peng, do you know ?
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 ?
Yes, there's an MCU_STATUS register [1].
Is that the only register I can use , or is there something more
detailed ? This register only returns values 0..3 which is not very
informative.
Not that I'm aware.
Hmmmmm ... is there any way we can progress with the MX95 upstreaming
with full reset , as a hardware implementation workaround in the driver,
or some such ?
