[PATCH] soc: imx: gpcv2: Assert reset before ungating clock

[Marek Vasut]

On 7/17/21 11:07 AM, Lucas Stach wrote:
> Am Samstag, dem 17.07.2021 um 02:55 +0200 schrieb Marek Vasut:
>> On 7/17/21 1:32 AM, Lucas Stach wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> Am Donnerstag, dem 01.07.2021 um 00:59 +0200 schrieb Marek Vasut:
>>>> In case the power domain clock are ungated before the reset is asserted,
>>>> the system might freeze completely. However, the MX8MM GPUMIX and VPUMIX
>>>> domains require different reset deassertion timing, and incorrect reset
>>>> deassertion timing also leads to hang.
>>>>
>>>> Add per-domain reset_{,de}assert_early flags which allow fine-grained
>>>> control of the reset assertion and deassertion sequence. Currently, on
>>>> MX8MM, the behavior is as follows and aligned with NXP downstream ATF
>>>> fork:
>>>> - VPUMIX: reset assert, reset deassert, domain power up
>>>> - GPUMIX: reset assert, domain power on, reset deassert
>>>>
>>> This patch should now be necessary, as my testing over the last few
>>> days showed that the VPUMIX isn't actually different and copes just
>>> fine with the reset being asserted early, just like the GPUMIX domain.
>>
>> Yes, this patch is absolutely essential, otherwise the system hangs at
>> random, as explained in the commit message.
> 
> And I was tired. This should have read *not* be necessary. Please take
> a look at the series I posted, where I just reverted the patch which
> changed the reset order to a late reset. With this the GPC now once
> again uses the reset order as required by the GPU, without any
> additional complexity.

During my extensive testing in the last few months, I've noticed random 
hangs of the platform and the reset/clock enablement order does matter, 
and it is different for different domains. The code in NXP ATF fork 
seems to confirm that.

Why do you think that is not the case , is there some documentation 
which confirms your hypothesis ?