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

[Thierry Reding]

On Thu, Jan 15, 2015 at 07:19:37PM +0000, Mark Rutland wrote:
> On Wed, Jan 14, 2015 at 07:57:25AM +0000, Thierry Reding wrote:
> > On Tue, Jan 13, 2015 at 07:44:50PM +0000, Ian Campbell wrote:
> > > Hi Thierry,
> > > 
> > > I needed to boot my Jetson in NS mode (in order to boot Xen) and was
> > > investigating the possibility of PSCI support when I discovered that you
> > > had already started on it[0]. Hurrah!
> > > 
> > > I cherry-picked the relevant commit onto u-boot-tegra#master and added a
> > > few more patches and now it boots correctly for me, both running Xen
> > > (some Xen side patches are needed too) and native Linux.
> > > 
> > > The main things which was needed was to rebase for some recent Kconfig
> > > changes relating to virt and nonsec mode and to arrange for the RAM used
> > > by the secure code to be reserved in the FDT. I also reserved the RAM
> > > using the hardware MC_SECURITY_CFG registers for good measure.
> > 
> > Great, those were all things that I had wanted to do but never got
> > around to.
> > 
> > > 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).
> > 
> > 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.
> > 
> > It could probably use some cleanup because there's a bit of debug output
> > still in there. Also...
> > 
> > > 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.
> > 
> > ... 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.
> 
> We have a generic CPUidle driver on arm64 which can use PSCI as a
> backend; we should try to reuse that. The binding should certainly be
> identical.

Is there any reason that driver needs to be ARM64-specific? I would've
thought that there could be a generic PSCI driver that works anywhere.

> It looks like the tegra124 dts in mainline doesn't use enable-method in
> the DT, so a better option might be to fail early in cpuidle-tegra114.c 
> if _any_ enable-method is present.

Yes, that sounds like a good plan. The absence of an enable-method would
signal that a kernel-native method (if any) should be used.

And this reminds me that we still need to find a way to synchronize
accesses to the powergate registers between secure firmware and the
kernel. Tegra has a set of hardware semaphores, but it seems like those
can only be used to synchronize between AVP and CPU, whereas for PSCI
we'd need something to synchronize between two CPUs. Do you know of any
existing mechanism to perform that type of synchronization?

Perhaps an option would be to add some sort of global lock in the kernel
which the cpuidle driver can grab before issuing the SMC instruction.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150116/33cab463/attachment.pgp>