On 2015-02-09 12:26, Mark Rutland wrote:
[...]
The solution that was discussed internally would involve having the secure monitor (U-Boot's PSCI implementation in this case) program the flow controller appropriately, point the CPU reset vectors to a location containing a WFI instruction and power up the CPUs. That way they should immediately be powergated when they reach the WFI instruction and the PSCI implementation would then be able to wake them up without accessing the PMC registers once the kernel has booted.
That sounds far, far better than I had hoped!
I guess we need to tell the kernel that portions of the PMC are reserved by FW (in the sense that they must not be modified by the kernel rather than that FW is going to poke them), to avoid mishaps.
I'm not sure we need even that. As I understand it the kernel can still touch all the registers and none of it should influence the CPU power- gating done by the secure monitor.
Well, I guess you'd need to make sure that the PMC driver doesn't try to powergate or unpowergate the CPU partitions, but since the cpuidle driver is the only one doing that it should resolve itself if a generic, PSCI-based cpuidle driver takes over instead of a Tegra-specific one.
This was my concern. It would be good to avoid a case where we accidentally rely on some subtle interactiion where both the FW and kernel poke some registers in a particular way.
I guess we can check for the presence of an enable-method, and if there is one don't register the Tegra-specific cpuidle driver; in that case we expect the FW to own that side of things.
Adding Peter. Please correct me if I misunderstood what we discussed. Can you also provide Ian with pointers to the registers that need to be programmed to make this work? I suspect that a lot of it can be gleaned from the cpuidle drivers in arch/arm/mach-tegra in the upstream Linux kernel.
Also adding Paul for visibility.
One thing to bear in mind is that PSCI is only one user of the SMC space. Per SMC calling convention, portions of the SMC ID space are there to be used for other (vendor-specific) purposes.
So rather than extending PSCI, a parallel API could be implemented for power control of other devices, and the backend could arbitrate the two without the non-secure OS requiring implementation-specific mutual exclusion.
I think this has been brought up internally previously; I'll go and poke around in the area to see if we managed to figure out anything useful.
Unfortunately this doesn't change on 64-bit Tegra at all.
I suspected as much. :/
How does this bode for the tegra132 dts [1] on LAKML at the moment? Is it just the "nvidia,tegra132-pmc" device that needs to be poked by both FW and kernel, or are other devices involved?
As I understand it, only the flow controller is involved with CPU power management once the above steps have been performed by the secure monitor. And I don't think anyone in the kernel would need access to the flow controller at that point either, so I think that problem resolved itself nicely.
Also note that the above should work as far back as Tegra30.
It would be amazing if we could gain PSCI for all the platforms that covers!
It should be relatively easy to support at least Tegra114 with much the same code as Tegra124, and some slight changes on Tegra30. But yeah, it would be great to see this work.
Nice!
I should look into getting hold of a relevant platform; I only have a (T20) AC100, and I guess that's a bit different at the system-level.
To avoid duplicate work: I started to implement the suggested algorithm on the TK1. Just like Ian, I don't have access to any other platform (nor docs at hand), so I will stick with Tegra124 support for the first step. I suppose we can easily extend this later on.
Flow controller setup and the PSCI service CPU_ON already works. I'll post patches once CPU_OFF is working as well.
Jan