Thread (8 messages) 8 messages, 3 authors, 2021-07-19

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

From: Marek Vasut <marex@denx.de>
Date: 2021-07-01 02:01:20

On 7/1/21 3:53 AM, Peng Fan wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help