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

[Philipp Zabel <p.zabel@pengutronix.de>]

On Mo, 2025-03-24 at 20:05 +0100, Marek Vasut 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?
> The reset on the MX95 is not really a reset, it is clear-only 
> set-never-again bit which goes only one way, the "unreset" way, so I 
> don't think this has any impact.

This sounds like the bit is initially set to 1 (reset asserted) and can
be cleared by writing 0 (once, to deassert the reset). But in the
reset-simple patch it looks to be the other way around (active_low =
true)?

If the reset control can't be asserted again on this hardware, it would
be better to have custom driver that doesn't implement the .assert()
callback at all.

regards
Philipp