Jetson-TK1 support for PSCI

Ian Campbell u-boot 1 version Jan 16, 2015 New

Get series with b4

b4 am [email protected]

Versions newest first

v1 Latest Jan 16, 20150 of 4 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 4 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [U-Boot] [PATCH v1 0/4] Jetson-TK1 support for PSCI

Quoted 64 lines · Thierry Reding

Quoted 54 lines · Ian Campbell
Quoted 10 lines · Thierry Reding
Quoted 9 lines · Ian Campbell
Quoted 8 lines · Thierry Reding
Quoted 7 lines
I also pushed my tree to gitorious:
https://gitorious.org/ijc/u-boot jetson-psci-v1
I would Ack your patch, but I don't think you've posted it and it has no S-o-b so that would seem a bit premature/rude of me. For the same reason I've not actually included it in the series posted (but it is in the gitorious branch).
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Feel free to take ownership of that patch. I currently don't have the time to work on this and it seems you've made good progress on it.
Will do. Could you offer a S-o-b for it please so I can pick it up.
Sure:
Signed-off-by Thierry Reding <[email protected]>
Thanks!
Quoted 18 lines
Quoted 18 lines
Quoted 7 lines
It could probably use some cleanup because there's a bit of debug output still in there. Also...
Quoted 3 lines
FWIW I think you could drop your stub versions of psci_cpu_off and psci_cpu_suspend (assuming you don't want to implement them) since the common code has stubs.
Quoted 7 lines
... I'd think you'd need to implement these so that you can get proper suspend/resume support in the kernel. I've had to disable cpuidle (via #undef CONFIG_PM_SLEEP in arch/arm/mach-tegra/cpuidle-tegra114.c) in the kernel to make that code not powergate CPUs. Ideally I think the kernel would check that it's running with PSCI support and disable the cpuidle driver. Maybe that could be done by introducing a new cpuidle driver that checks for PSCI availability and uses it when present.
Hrm, I'm not sure how this all fits together, it's not a problem I've noted before.
Quoted 7 lines
Quoted 3 lines
FWIW I think cpu_off and cpu_suspend are optional in PSCI v0.1 so an initial version doesn't necessarily need to implement them (sunxi doesn't for example), but as you say they do enable useful features.
I think when I tried last time, without disable the cpuidle driver things would hang at boot. I would expect that problem to exist for any board. Perhaps you've disabled PM_SLEEP in your config?
I don't think so:
# grep PM_SLEEP /boot/config-3.18.0-trunk-armmp-lpae 
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP_DEBUG=y
Quoted 4 lines
I don't see anything about cpuidle in dmesg either.
Did you perhaps mean CPU_IDLE rather than PM_SLEEP because:
# CONFIG_CPU_IDLE is not set
Yes, I think that would have the same effect as disable PM_SLEEP (at least regarding the powergate stuff that's conflicting with the PSCI implementation).

Quoted 6 lines

Note also, as mentioned in another reply, that with the PSCI support there's now two sources that can simultaneously access the powergate functionality in the PMC. We have some locking in place to make sure that concurrent accesses from within the kernel are serialized, but there's no mechanism in place to protect from concurrent accesses in secure firmware and the kernel.

The docs are on another machine, but I take it the PMC registers are available to NS mode? Is that configurable (from S mode) perhaps?

Quoted 3 lines

I don't have any good ideas on how to solve this nicely. The best I could come up with is to make sure that we grab a lock before doing any PSCI calls from the kernel and release the lock upon return.

Ian.

Read the cover letter in its thread