All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Masters <jonathan@jonmasters.org>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Al Stone <al.stone@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	ACPI Devel Mailing List <linux-acpi@vger.kernel.org>,
	Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>
Subject: Re: [RFC] ACPI on arm64 TODO List
Date: Wed, 17 Dec 2014 23:57:05 -0500	[thread overview]
Message-ID: <54925EA1.1030901@jonmasters.org> (raw)
In-Reply-To: <20141217092505.GA9475@e104818-lin.cambridge.arm.com>

On 12/17/14, 4:25 AM, Catalin Marinas wrote:
> On Wed, Dec 17, 2014 at 12:03:06AM +0000, Al Stone wrote:

>> That being said, the early systems still don't provide PSCI.

Clarification: some early systems are capable of PSCI but the firmware 
was in progress (and thus they implemented the Parking Protocol 
initially but will do full PSCI) - for example AMD Seattle - while one 
other implementation is unable to provide PSCI and will only do Parking 
Protocol. Both are trivially supportable through bits in the ACPI MADT.

>> They will
>> at some point in the future, but not now.  Regardless, I think it's
>> reasonable for us to say that if you want ACPI support, PSCI must be
>> used for secondary CPU startup.  People can hack something up to get
>> the parking protocol to work on development branches if they want, but
>> I personally see no need to get that into the kernel -- and it needs
>> to be said explicitly in arm-acpi.txt.

That could be ok for upstream - it's up to you guys - but note that 
there will be some early hardware that doesn't do PSCI. I've sat on 
*everyone* over the past couple of years behind the scenes to ensure 
that all future designs will do PSCI, but this takes time to realize.

> I'm fine with this. But note that it pretty much rules out the APM
> boards (I think we ruled them out a few times already) which don't have
> an EL3 to host PSCI firmware. EL2 is not suitable as it is likely that
> we want this level for KVM or Xen rather than platform firmware.

The gen1 APM boards work great with UEFI and ACPI using the Parking 
Protocol. It's trivial to support, and it's a fairly constrained since 
everyone is headed toward PSCI. Personally I consider it unfair to 
punish the first guy out of the gate for something that was standardized 
after they made their design. My recommendation would be to get the 
relevant document updated in the public repository. Patches that 
implement Parking Protocol are already in existence/working well as an 
alternative to PSCI (which is always preferred if available).

Jon.

WARNING: multiple messages have this Message-ID (diff)
From: jonathan@jonmasters.org (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] ACPI on arm64 TODO List
Date: Wed, 17 Dec 2014 23:57:05 -0500	[thread overview]
Message-ID: <54925EA1.1030901@jonmasters.org> (raw)
In-Reply-To: <20141217092505.GA9475@e104818-lin.cambridge.arm.com>

On 12/17/14, 4:25 AM, Catalin Marinas wrote:
> On Wed, Dec 17, 2014 at 12:03:06AM +0000, Al Stone wrote:

>> That being said, the early systems still don't provide PSCI.

Clarification: some early systems are capable of PSCI but the firmware 
was in progress (and thus they implemented the Parking Protocol 
initially but will do full PSCI) - for example AMD Seattle - while one 
other implementation is unable to provide PSCI and will only do Parking 
Protocol. Both are trivially supportable through bits in the ACPI MADT.

>> They will
>> at some point in the future, but not now.  Regardless, I think it's
>> reasonable for us to say that if you want ACPI support, PSCI must be
>> used for secondary CPU startup.  People can hack something up to get
>> the parking protocol to work on development branches if they want, but
>> I personally see no need to get that into the kernel -- and it needs
>> to be said explicitly in arm-acpi.txt.

That could be ok for upstream - it's up to you guys - but note that 
there will be some early hardware that doesn't do PSCI. I've sat on 
*everyone* over the past couple of years behind the scenes to ensure 
that all future designs will do PSCI, but this takes time to realize.

> I'm fine with this. But note that it pretty much rules out the APM
> boards (I think we ruled them out a few times already) which don't have
> an EL3 to host PSCI firmware. EL2 is not suitable as it is likely that
> we want this level for KVM or Xen rather than platform firmware.

The gen1 APM boards work great with UEFI and ACPI using the Parking 
Protocol. It's trivial to support, and it's a fairly constrained since 
everyone is headed toward PSCI. Personally I consider it unfair to 
punish the first guy out of the gate for something that was standardized 
after they made their design. My recommendation would be to get the 
relevant document updated in the public repository. Patches that 
implement Parking Protocol are already in existence/working well as an 
alternative to PSCI (which is always preferred if available).

Jon.

  reply	other threads:[~2014-12-18  4:57 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16  2:18 [RFC] ACPI on arm64 TODO List Al Stone
2014-12-16  2:18 ` Al Stone
2014-12-16 11:27 ` Arnd Bergmann
2014-12-16 11:27   ` Arnd Bergmann
2014-12-16 15:27   ` Catalin Marinas
2014-12-16 15:27     ` Catalin Marinas
2014-12-17  0:03     ` Al Stone
2014-12-17  0:03       ` Al Stone
2014-12-17  9:25       ` Catalin Marinas
2014-12-17  9:25         ` Catalin Marinas
2014-12-18  4:57         ` Jon Masters [this message]
2014-12-18  4:57           ` Jon Masters
2014-12-18  9:55           ` Catalin Marinas
2014-12-18  9:55             ` Catalin Marinas
2014-12-17 13:43       ` [Linaro-acpi] " Charles Garcia-Tobin
2014-12-17 13:43         ` Charles Garcia-Tobin
2014-12-16 15:48   ` Mark Rutland
2014-12-16 15:48     ` Mark Rutland
2014-12-17  0:37     ` Al Stone
2014-12-17  0:37       ` Al Stone
2014-12-17  9:08       ` G Gregory
2014-12-17  9:08         ` G Gregory
2014-12-17 16:02       ` Mark Rutland
2014-12-17 16:02         ` Mark Rutland
2014-12-17 16:52         ` Hurwitz, Sherry
2014-12-17 16:52           ` Hurwitz, Sherry
2014-12-17 18:14       ` Lorenzo Pieralisi
2014-12-17 18:14         ` Lorenzo Pieralisi
2014-12-18  5:04       ` Jon Masters
2014-12-18  5:04         ` Jon Masters
2014-12-18 14:36         ` Jon Masters
2014-12-18 14:36           ` Jon Masters
2014-12-16 22:55   ` Al Stone
2014-12-16 22:55     ` Al Stone
2014-12-17 17:31     ` Catalin Marinas
2014-12-17 17:31       ` Catalin Marinas
2014-12-17 22:26   ` Grant Likely
2014-12-17 22:26     ` Grant Likely
2015-01-10 14:44     ` Grant Likely
2015-01-10 14:44       ` Grant Likely
2015-01-12 10:21       ` Arnd Bergmann
2015-01-12 10:21         ` Arnd Bergmann
2015-01-12 12:00         ` Grant Likely
2015-01-12 12:00           ` Grant Likely
2015-01-12 19:40           ` [Linaro-acpi] " Arnd Bergmann
2015-01-12 19:40             ` Arnd Bergmann
2015-01-13 17:22             ` Grant Likely
2015-01-13 17:22               ` Grant Likely
2015-01-14  0:26               ` Al Stone
2015-01-14  0:26                 ` Al Stone
2015-01-15  4:07                 ` Hanjun Guo
2015-01-15  4:07                   ` Hanjun Guo
2015-01-15 17:15                   ` Arnd Bergmann
2015-01-15 17:15                     ` Arnd Bergmann
2015-01-15 17:19                 ` Arnd Bergmann
2015-01-15 17:19                   ` Arnd Bergmann
2015-01-12 14:23       ` Pavel Machek
2015-01-12 14:23         ` Pavel Machek
2015-01-12 14:41         ` Grant Likely
2015-01-12 14:41           ` Grant Likely
2015-01-12 19:39           ` Pavel Machek
2015-01-12 19:39             ` Pavel Machek
2015-01-12 19:55             ` Arnd Bergmann
2015-01-12 19:55               ` Arnd Bergmann
2015-01-13 14:12             ` Grant Likely
2015-01-13 14:12               ` Grant Likely
2015-01-14  1:21             ` Al Stone
2015-01-14  1:21               ` Al Stone
2015-01-15 17:45               ` [Linaro-acpi] " Linda Knippers
2015-01-15 17:45                 ` Linda Knippers
2015-01-13 17:02         ` Grant Likely
2015-01-13 17:02           ` Grant Likely
2015-01-05 20:52 ` Pavel Machek
2015-01-05 20:52   ` Pavel Machek
2015-01-06 11:53   ` Catalin Marinas
2015-01-06 11:53     ` Catalin Marinas

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=54925EA1.1030901@jonmasters.org \
    --to=jonathan@jonmasters.org \
    --cc=al.stone@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=grant.likely@linaro.org \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=olof@lixom.net \
    --cc=rjw@rjwysocki.net \
    /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.