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

[Marek Vasut <marex@denx.de>]

On 7/1/21 3:53 AM, Peng Fan wrote:
>> Subject: [PATCH] soc: imx: gpcv2: Assert reset before ungating clock
>>
>> 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
> 
> In 2.4 ATF, only VPU_H1/G1/G2 needs reset assert/deassert early,
> but actually in first power on, it is in reset assert, so I think no need
> reset assert again. I think only need to reset assert when power off.
> 
> Would the following patch help you hang case?

No, in my case the VPU hangs in imx_pgc_power_up() , and it generally 
happens after multiple reboots, so I think the state of the hardware is 
undefined. That's why I think we should assert the reset (like the ATF 
does), to make sure the hardware is in defined state, before operating 
the power domain controls.

What I find puzzling is why each MIX domain has different requirements 
for the placement of reset assert/deassert calls. It is that way in ATF, 
but it is still odd.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel