[...] > > > 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. Thanks, Mark. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
