All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM: PSCI 0.1 vs 0.2
Date: Fri, 28 Nov 2014 10:05:49 +0000	[thread overview]
Message-ID: <547848FD.1090002@arm.com> (raw)
In-Reply-To: <547837B2.1020700@web.de>

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...

  reply	other threads:[~2014-11-28 10:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2014-11-28 10:24           ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547848FD.1090002@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.