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

Marek Vasut
2025-03-25T14:27:19Z

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 ?