On Thu, Mar 13, 2014 at 08:59:31AM +0000, Charles Garcia-Tobin wrote:
Hi
-----Original Message----- From: linaro-acpi-bounces@lists.linaro.org [mailto:linaro-acpi- bounces@lists.linaro.org] On Behalf Of Graeme Gregory Sent: 13 March 2014 08:46 To: Ashwin Chaugule Cc: linaro-acpi@lists.linaro.org Subject: Re: [Linaro-acpi] [PATCH] Restructure code to get static PSCI function ID's
On Thu, Mar 13, 2014 at 12:27:29AM -0400, Ashwin Chaugule wrote:
The PSCI Function ID's are well defined for ARM32 and ARM64. See PSCI spec v0.2. The initial version of the PSCI ACPI spec will only have provisions for discovering PSCI and the conduit. (i.e. SMC or HVC)
Reformat code in preparation for patches that discover PSCI and the conduit via FACP flags.
Signed-off-by: Ashwin Chaugule ashwin.chaugule@linaro.org
arch/arm/include/asm/psci.h | 13 ++++++++++++ arch/arm64/include/asm/psci.h | 13 ++++++++++++ arch/arm64/kernel/psci.c | 47 +++++++++++++++++-------------------------- 3 files changed, 44 insertions(+), 29 deletions(-)
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h index c4ae171..901de0f 100644 --- a/arch/arm/include/asm/psci.h +++ b/arch/arm/include/asm/psci.h @@ -34,6 +34,19 @@ struct psci_operations { extern struct psci_operations psci_ops; extern struct smp_operations psci_smp_ops;
+/* PSCI Function ID's for ARM32 as per PSCI spec v0.2 */
+#define PSCI_ID_VERSION 0x84000000 +#define PSCI_ID_CPU_SUSPEND 0x84000001 +#define PSCI_ID_CPU_OFF 0x84000002 +#define PSCI_ID_CPU_ON 0x84000003 +#define PSCI_ID_AFFINITY_INFO 0x84000004 +#define PSCI_ID_CPU_MIGRATE 0x84000005 +#define PSCI_ID_MIGRATE_INFO_TYPE 0x84000006 +#define PSCI_ID_MIGRATE_INFO_UP_CPU 0x84000007 +#define PSCI_ID_SYSTEM_OFF 0x84000008 +#define PSCI_ID_SYSTEM_RESET 0x84000009
I get the feeling this is actually generic stuff and shows an error in DTB bingings in that the bindings themselves should not define these states.
DT bindings have caused quite a lot of debate and I am not even sure that's closed. There we allowed the option to override. However I think what would make sense from a spec POV would be that there are defaults that may be overridden. Ccing Mark for opinion question on this whole thing.
The original bindings were created before there were well-defined function IDs. As we suspected implementations might vary wildly we had the function IDs in the DT.
The debate was mainly over whether the new IDs should be in the DT, for which I believe the eventual answer was no. The IDs are well-defined, and any implementation not using those IDs is not PSCI 0.2 compliant. If we have such broken implementations, we can allocate new compatible strings and/or mechanisms to provide the IDs, but shouldn't do that from the start.
For platforms which want to boot existing kernels while also providing PSCI 0.2 features (e.g. KVM), it needs to be possible to describe PSCI 0.2 in a backwards-compatible fashion. So far there's no binding upstream, but I think in such cases the PSCI node could (optionally) claim compatibility with "arm,psci", and list the CPU_{SUSPEND,OFF,ON} and MIGRATE function IDs explicitly:
psci { compatible = "arm,psci-0.2", "arm,psci"; method = "hvc";
/* * For compatibility with kernels which understand * "arm,psci" only. No new function IDs should be added * here. */ cpu_suspend = <0x84000001>; cpu_off = <0x84000002>; cpu_on = <0x84000003>; migrate = <0x84000005>; };
For ACPI we have no existing PSCI description and should be able to assume PSCI 0.2+. We can then use PSCI_VERSION and other calls to work out which function IDs are available.
Thanks, Mark.