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

[Boris Brezillon <boris.brezillon@collabora.com>]

On Tue, 25 Mar 2025 15:37:01 +0100
Marek Vasut <marex@denx.de> wrote:

> On 3/25/25 3:35 PM, Boris Brezillon wrote:
> > On Tue, 25 Mar 2025 14:50:32 +0100
> > Marek Vasut <marex@denx.de> wrote:
> >   
> >> On 3/25/25 8:43 AM, Boris Brezillon wrote:  
> >>> On Tue, 25 Mar 2025 00:37:59 +0100
> >>> Marek Vasut <marex@denx.de> wrote:
> >>>      
> >>>> On 3/24/25 9:43 AM, Boris Brezillon wrote:
> >>>>
> >>>> [...]
> >>>>     
> >>>>>> @@ -563,6 +585,7 @@ int panthor_device_suspend(struct device *dev)
> >>>>>>     
> >>>>>>     	panthor_devfreq_suspend(ptdev);
> >>>>>>     
> >>>>>> +	reset_control_assert(ptdev->resets);  
> >>>>>
> >>>>> Hm, that might be the cause of the fast reset issue (which is a fast
> >>>>> resume more than a fast reset BTW): if you re-assert the reset line on
> >>>>> runtime suspend, I guess this causes a full GPU reset, and the MCU ends
> >>>>> up in a state where it needs a slow reset (all data sections reset to
> >>>>> their initial state). Can you try to move the reset_control_[de]assert
> >>>>> to the unplug/init functions?  
> >>>> Is it correct to assume , that if I remove all reset_control_assert()
> >>>> calls (and keep only the _deassert() calls), the slow resume problem
> >>>> should go away too ?  
> >>>
> >>> Yeah, dropping the _assert()s should do the trick.  
> >> Hmmm, no, that does not help. I was hoping maybe NXP can chime in and
> >> suggest something too ?  
> > 
> > Can you try keep all the clks/regulators/power-domains/... on after
> > init, and see if the fast resume works with that. If it does,
> > re-introduce one resource at a time to find out which one causes the
> > MCU to lose its state.  
> 
> I already tried that too . I spent quite a while until I reached that L2 
> workaround in fact.

So, with your RPM suspend/resume being NOPs, it still doesn't work?
Unless the FW is doing something behind our back, I don't really see
why this would fail on your platform, but not on the rk3588. Are you
sure the power domains are kept on at all times. I'm asking, because if
you linked all the PDs, the on/off sequence is automatically handled by
the RPM core at suspend/resume time.