On Di, 2025-03-25 at 15:27 +0100, Marek Vasut wrote: > On 3/25/25 3:12 PM, Philipp Zabel wrote: > > 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. > Maybe the reset-simple driver can be extended with some mode of > operation like this instead , to make it skip assert once deasserted , > for specific reset controllers ?
How about a second reset_control_ops struct without .assert, selected in reset_simple_probe() by a new flag in reset_simple_devdata. regards Philipp
