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

[Marek Vasut]

On 9/4/25 5:20 PM, Boris Brezillon wrote:
> On Thu, 4 Sep 2025 16:54:38 +0200
> Marek Vasut <marek.vasut at 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 ?