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).
Still studying the logic: Is it possible to provide both interfaces, and would it make sense?
Jan
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.
Thanks,
M.
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?
Jan
Hi,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Jan Kiszka Sent: Monday, November 10, 2014 6:56 PM To: Marc Zyngier Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] ARM: PSCI 0.1 vs 0.2
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?
Jan
--
We did send out some ARMv8 PSCI v0.2 u-boot patches, which can be seen here:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/194210
Regards, Bhupesh
On 2014-11-10 14:29, bhupesh.sharma@freescale.com wrote:
Hi,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Jan Kiszka Sent: Monday, November 10, 2014 6:56 PM To: Marc Zyngier Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] ARM: PSCI 0.1 vs 0.2
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?
Jan
--
We did send out some ARMv8 PSCI v0.2 u-boot patches, which can be seen here:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/194210
Nice. I guess that could be reused for ARMv7 as well, at least conceptually. You are using C for some PSCI functions, specifically for cache flushing? Need to dig deeper...
Jan
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...).
Thanks,
M.
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?
Jan
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).
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 was hoping for something slightly simpler though...
Thanks,
M.
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
participants (4)
-
bhupesh.sharma＠freescale.com -
Jan Kiszka -
Jan Kiszka -
Marc Zyngier