* [U-Boot] ARM: PSCI 0.1 vs 0.2 @ 2014-11-10 12:51 Jan Kiszka 2014-11-10 13:08 ` Marc Zyngier 0 siblings, 1 reply; 9+ messages in thread From: Jan Kiszka @ 2014-11-10 12:51 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-10 12:51 [U-Boot] ARM: PSCI 0.1 vs 0.2 Jan Kiszka @ 2014-11-10 13:08 ` Marc Zyngier 2014-11-10 13:25 ` Jan Kiszka 0 siblings, 1 reply; 9+ messages in thread From: Marc Zyngier @ 2014-11-10 13:08 UTC (permalink / raw) To: u-boot 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. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-10 13:08 ` Marc Zyngier @ 2014-11-10 13:25 ` Jan Kiszka 2014-11-10 13:29 ` bhupesh.sharma at freescale.com 2014-11-10 13:36 ` Marc Zyngier 0 siblings, 2 replies; 9+ messages in thread From: Jan Kiszka @ 2014-11-10 13:25 UTC (permalink / raw) To: u-boot 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 -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-10 13:25 ` Jan Kiszka @ 2014-11-10 13:29 ` bhupesh.sharma at freescale.com 2014-11-10 13:35 ` Jan Kiszka 2014-11-10 13:36 ` Marc Zyngier 1 sibling, 1 reply; 9+ messages in thread From: bhupesh.sharma at freescale.com @ 2014-11-10 13:29 UTC (permalink / raw) To: u-boot Hi, > -----Original Message----- > From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] > On Behalf Of Jan Kiszka > Sent: Monday, November 10, 2014 6:56 PM > To: Marc Zyngier > Cc: u-boot at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-10 13:29 ` bhupesh.sharma at freescale.com @ 2014-11-10 13:35 ` Jan Kiszka 0 siblings, 0 replies; 9+ messages in thread From: Jan Kiszka @ 2014-11-10 13:35 UTC (permalink / raw) To: u-boot On 2014-11-10 14:29, bhupesh.sharma at freescale.com wrote: > Hi, > >> -----Original Message----- >> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] >> On Behalf Of Jan Kiszka >> Sent: Monday, November 10, 2014 6:56 PM >> To: Marc Zyngier >> Cc: u-boot at 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 -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-10 13:25 ` Jan Kiszka 2014-11-10 13:29 ` bhupesh.sharma at freescale.com @ 2014-11-10 13:36 ` Marc Zyngier 2014-11-28 8:52 ` Jan Kiszka 1 sibling, 1 reply; 9+ messages in thread From: Marc Zyngier @ 2014-11-10 13:36 UTC (permalink / raw) To: u-boot 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. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-10 13:36 ` Marc Zyngier @ 2014-11-28 8:52 ` Jan Kiszka 2014-11-28 10:05 ` Marc Zyngier 0 siblings, 1 reply; 9+ messages in thread From: Jan Kiszka @ 2014-11-28 8:52 UTC (permalink / raw) To: u-boot 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 -------------- 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/fb097821/attachment.pgp> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-28 8:52 ` Jan Kiszka @ 2014-11-28 10:05 ` Marc Zyngier 2014-11-28 10:24 ` Jan Kiszka 0 siblings, 1 reply; 9+ messages in thread From: Marc Zyngier @ 2014-11-28 10:05 UTC (permalink / raw) To: u-boot 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. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] ARM: PSCI 0.1 vs 0.2 2014-11-28 10:05 ` Marc Zyngier @ 2014-11-28 10:24 ` Jan Kiszka 0 siblings, 0 replies; 9+ messages in thread From: Jan Kiszka @ 2014-11-28 10:24 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-11-28 10:24 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-10 12:51 [U-Boot] ARM: PSCI 0.1 vs 0.2 Jan Kiszka 2014-11-10 13:08 ` Marc Zyngier 2014-11-10 13:25 ` Jan Kiszka 2014-11-10 13:29 ` bhupesh.sharma at freescale.com 2014-11-10 13:35 ` Jan Kiszka 2014-11-10 13:36 ` Marc Zyngier 2014-11-28 8:52 ` Jan Kiszka 2014-11-28 10:05 ` Marc Zyngier 2014-11-28 10:24 ` Jan Kiszka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox