From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Date: Mon, 19 Jan 2015 10:25:58 +0100 Subject: [U-Boot] [PATCH v1 0/4] Jetson-TK1 support for PSCI In-Reply-To: <1421424679.19839.80.camel@hellion.org.uk> References: <1421178290.11796.159.camel@hellion.org.uk> <20150114075724.GD9491@ulmo.nvidia.com> <1421225921.11796.172.camel@hellion.org.uk> <20150115145539.GA14092@ulmo.nvidia.com> <1421401402.19839.24.camel@hellion.org.uk> <20150116100527.GG9170@ulmo.nvidia.com> <1421403843.19839.41.camel@hellion.org.uk> <20150116160357.GA32698@ulmo.nvidia.com> <1421424679.19839.80.camel@hellion.org.uk> Message-ID: <20150119092557.GA6487@ulmo.nvidia.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Jan 16, 2015 at 04:11:19PM +0000, Ian Campbell wrote: > On Fri, 2015-01-16 at 17:03 +0100, Thierry Reding wrote: > > On Fri, Jan 16, 2015 at 10:24:03AM +0000, Ian Campbell wrote: > > > On Fri, 2015-01-16 at 11:05 +0100, Thierry Reding wrote: > > > > On Fri, Jan 16, 2015 at 09:43:22AM +0000, Ian Campbell wrote: > > > > > On Thu, 2015-01-15 at 15:55 +0100, Thierry Reding wrote: > > > > > > On Wed, Jan 14, 2015 at 08:58:41AM +0000, Ian Campbell wrote: > > > > > > > On Wed, 2015-01-14 at 08:57 +0100, Thierry Reding wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > Will do. Could you offer a S-o-b for it please so I can pick it up. > > > > > > > > > > > > Sure: > > > > > > > > > > > > Signed-off-by: Thierry Reding > > > > > > > > > > Thanks! > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Hrm, I'm not sure how this all fits together, it's not a problem I've > > > > > > > noted before. > > > > > > > > > > > > > > FWIW I think cpu_off and cpu_suspend are optional in PSCI v0.1 so an > > > > > > > initial version doesn't necessarily need to implement them (sunxi > > > > > > > doesn't for example), but as you say they do enable useful features. > > > > > > > > > > > > I think when I tried last time, without disable the cpuidle driver > > > > > > things would hang at boot. I would expect that problem to exist for > > > > > > any board. Perhaps you've disabled PM_SLEEP in your config? > > > > > > > > > > I don't think so: > > > > > # grep PM_SLEEP /boot/config-3.18.0-trunk-armmp-lpae > > > > > CONFIG_PM_SLEEP=y > > > > > CONFIG_PM_SLEEP_SMP=y > > > > > CONFIG_PM_SLEEP_DEBUG=y > > > > > > > > > > I don't see anything about cpuidle in dmesg either. > > > > > > > > > > Did you perhaps mean CPU_IDLE rather than PM_SLEEP because: > > > > > # CONFIG_CPU_IDLE is not set > > > > > > > > Yes, I think that would have the same effect as disable PM_SLEEP (at > > > > least regarding the powergate stuff that's conflicting with the PSCI > > > > implementation). > > > > > > > > Note also, as mentioned in another reply, that with the PSCI support > > > > there's now two sources that can simultaneously access the powergate > > > > functionality in the PMC. We have some locking in place to make sure > > > > that concurrent accesses from within the kernel are serialized, but > > > > there's no mechanism in place to protect from concurrent accesses in > > > > secure firmware and the kernel. > > > > > > The docs are on another machine, but I take it the PMC registers are > > > available to NS mode? Is that configurable (from S mode) perhaps? > > > > I don't see how that's relevant. Even if it was possible to secure the > > registers against access from NS mode, there's no way we could do that > > because many drivers rely on controlling their power domain using that > > functionality. > > > > Or perhaps I misunderstand what you're suggesting. > > If the PMC registers aren't available to NS then the damage the > powergate driver can do by conflicting with PSCI is more limited i.e not > going to fry the h/w somehow. As far as I can tell these registers are available in NS mode. They have to because a bunch of drivers rely on it. The powergate driver controls not only CPU power domains, but also display, SATA, PCIe and so on. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: