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

[Marek Vasut]

On 3/25/25 3:35 PM, Boris Brezillon wrote:
> On Tue, 25 Mar 2025 14:50:32 +0100
> Marek Vasut <marex at 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 at 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.