From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Fri, 28 Nov 2014 11:24:43 +0100 Subject: [U-Boot] ARM: PSCI 0.1 vs 0.2 In-Reply-To: <547848FD.1090002@arm.com> References: <5460B4B5.2060602@siemens.com> <5460B8E8.9070706@arm.com> <5460BCE0.2020301@siemens.com> <5460BF71.8010508@arm.com> <547837B2.1020700@web.de> <547848FD.1090002@arm.com> Message-ID: <54784D6B.8020704@web.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2014-11-28 11:05, Marc Zyngier wrote: > On 28/11/14 08:52, Jan Kiszka wrote: >> On 2014-11-10 14:36, Marc Zyngier wrote: >>> On 10/11/14 13:25, Jan Kiszka wrote: >>>> On 2014-11-10 14:08, Marc Zyngier wrote: >>>>> On 10/11/14 12:51, Jan Kiszka wrote: >>>>>> Hi Marc, >>>>>> >>>>>> what is the motivation to expose a PSCI 0.1 interface in U-boot, instead >>>>>> of 0.2? Support for preexisting users of 0.1? The kernel seems to be >>>>>> happy with both, and I'm now wondering if we should actually add the >>>>>> legacy version to Jailhouse as well (I hope we can avoid this). >>>>> >>>>> The initial rational was simple: at the time this code was written, the >>>>> 0.2 spec still in review, and nobody was implementing it. Supporting 0.1 >>>>> was the only viable use-case. >>>>> >>>>>> Still studying the logic: Is it possible to provide both interfaces, and >>>>>> would it make sense? >>>>> >>>>> Supporting both is very easy. Just output the 0.2 function numbers that >>>>> actually make sense for 0.1 and have both compatible strings. >>>> >>>> Ah, cool - parameters and return values of, say, CPU_ON/OFF are >>>> compatible across both versions? >>> >>> That was the idea of the spec (broadly compatible across revisions...). >> >> There is one major problem with v0.2, though, and I bet this also >> applies to the ARMv8 implementation: >> >> v0.2 mandates that the firmware provides SYSTEM_RESET - that's rather >> simple - and SYSTEM_OFF. The latter seems non-trivial for the sunxi as >> the power controller is attached via i2c. I guess that will be quite a >> bit of code in the PSCI monitor for a feature that already works fine >> for Linux with v0.1. Or am I missing something? > > I seem to remember that you're allowed to return something like "Not > Implemented" (of course, I could be wrong). The spec says that both SYSTEM functions do not return, thus also return no error code. > > But even that is not that hard. I'm pretty sure the i2c pins can be > switched to be GPIOs, and bit-banging i2c is not too difficult (see > drivers/i2c/algos/i2c-algo-bit.c). I'm still searching for specs that describe all the interfaces and chips... > > I was hoping for something slightly simpler though... What concerns me in addition are potential variations due to different boards and such - the PSCI code base may quickly grow. Too bad the standard does not allow this to be optional. Then it could be activated as needed, e.g. when running in a hypervisor. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: