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

Mark Rutland
2015-01-15T19:19:37Z

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.

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.

Thanks,
Mark.