[U-Boot] ARM: PSCI 0.1 vs 0.2

Jan Kiszka jan.kiszka at web.de
Fri Nov 28 11:24:43 CET 2014


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: <http://lists.denx.de/pipermail/u-boot/attachments/20141128/2c25ed8d/attachment.pgp>


More information about the U-Boot mailing list