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

[Mark Rutland]

[...]

> > > 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.