ARM/arm64: renesas: Add SYSC PM Domain DT Support
Get series with b4
b4 am 4841673.3GCjGElFcY@avalonVersions newest first · linked by author and title
- v2 Latest posting 3/30 of 11 patches 0 repliesNew
- v2 posting 2/30 of 11 patches 0 repliesSuperseded
- v2 posting 1/39 of 11 patches 0 repliesSuperseded
Patches in v2 posting 3/3 No applies recorded yet
None of the 11 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH/RFC v2 00/11] ARM/arm64: renesas: Add SYSC PM Domain DT Support
Hi Geert,
Here's an update.
Quoted 23 lines · On Sunday 28 February 2016 17:04:47 Laurent Pinchart wrote:
Quoted 7 lines · On Sunday 28 February 2016 09:55:32 Geert Uytterhoeven wrote:
Quoted 2 lines · Laurent Pinchart
After rebasing this series on top of Simon's latest devel branch, I'm experiencing hard system freezes when using the VSP.
Is this due to the rebasing? Did it work in
renesas-drivers-2016-02-16-v4.5-rc4 or
renesas-drivers-2016-02-23-v4.5-rc5?I thought it was, but after further investigations I've been unable to get it working at all even on my older branches, so I think the problem has always been there.
Quoted 10 lines
Quoted 9 lines
What makes the problem curious is that PM runtime works fine when the VSP instances are probed, the A3VP power domain is turned on and off correctly for each instance. However, after booting the system, if I try to RPM resume the device, the system hangs.
I've traced this (using printk debugging) down to the SYSCISCR write in
rcar_sysc_power(). The value written is0x00000200, which corresponds to the A3VP power domain, and the resume request completion wait loop doesn't time out.
Quoted 5 lines
Quoted 1 line
So the second write to SYSCISCR in that function locks up the system?
Correct, and only after the kernel has booted, there's a bunch of calls to
rcar_sysc_power()to enable/disable the A3VP power domain at boot time when the vsp devices are probed, and those don't cause any issue.
I've investigated the problem further, and realized the freeze was caused by writing to the PWRONCR_OFFS register, not the SYSCISCR register. It doesn't occur immediately though, I had to put longer delays between the register writes to locate the faulty one.
Furthermore, I've also realized that commenting out the A3SH power domain from DT seemed to fix the problem. Unused power domains are powered off at the end of the boot sequence, and it looks like powering A3SH there somehow messes up the SYSC and hangs the system the next time a power domain is turned on.
Given that the latest version of the datasheet doesn't document the A3SH power domain it would probably be a good idea to remove it, at least until we can get more information from the hardware team.
Signature · 3 lines
Regards, Laurent Pinchart