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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
