On Tue, 25 Mar 2025 14:50:32 +0100 Marek Vasut <ma...@denx.de> wrote:
> On 3/25/25 8:43 AM, Boris Brezillon wrote: > > On Tue, 25 Mar 2025 00:37:59 +0100 > > Marek Vasut <ma...@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.
