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

[Rain Yang <jiyu.yang@oss.nxp.com>]

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

Hi Boris,

you're right.
*0x4d810008=1, this register is a write-once register, so it was moved into SM
since imx 6.12.3 release, and latest 6.6.52 release. some document work is still
needed in the future.

Hi Marek,
thanks for your effort to make the i.MX95 GPU upstreamed.
I created one PR to support i.MX95 GPU expcept the multi power domain[1],
but it seemed to be placed in the wrong location. No one responded to it,
so I closed it.

for the suspend/resume issue, the panthor driver works well with 6.12.34 
patched with pm_domains operation like you did.
run vkmark->suspend 10min in the 4th console->wakeup in the 4th console.

can you show me your SM version when uboot start,
and the G310 firmware version which can be found by search git_sha string.

[1] https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/13