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

Philipp Zabel p.zabel at pengutronix.de
Tue Mar 25 07:12:39 PDT 2025


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



More information about the linux-arm-kernel mailing list