drivers: firmware: psci: add basic v1.0 support

Functions implemented on arm64 to check if a power_state parameter is valid and if the power_state implies context loss are not arm64 specific and should be moved to generic code so that they can be reused on arm systems too.

This patch moves the functions handling the power_state parameter to generic PSCI firmware layer code.

Signed-off-by Lorenzo Pieralisi <[email protected]>

Acked-by Will Deacon <[email protected]>

Acked-by Sudeep Holla <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Mark Rutland <[email protected]>

PSCI v1.0 augmented the power_state parameter format specification (extended stateid) and introduced a way to probe it through the PSCI_FEATURES interface.

This patch implements code that detects the power_state format at run-time through the PSCI_FEATURES interface, so that the power_state argument can be properly detected and validated in the kernel according to the information provided through firmware.

Signed-off-by Lorenzo Pieralisi <[email protected]>

Cc Mark Rutland <[email protected]>

---
 drivers/firmware/psci.c   | 34 ++++++++++++++++++++++++++++++++--
 include/uapi/linux/psci.h | 12 ++++++++++++
 2 files changed, 44 insertions(+), 2 deletions(-)

drivers/firmware/psci.c +32 -2

index 24ef3a8..bd2ba5b 100644
@@ -75,14 +75,34 @@ static u32 psci_function_id[PSCI_FN_MAX];
                                PSCI_0_2_POWER_STATE_TYPE_MASK | \
                                PSCI_0_2_POWER_STATE_AFFL_MASK)
 
+#define PSCI_1_0_EXT_POWER_STATE_MASK          \
+                               (PSCI_1_0_EXT_POWER_STATE_ID_MASK | \
+                               PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
+
+static u32 psci_cpu_suspend_feature;
+
+static inline bool psci_has_ext_power_state(void)
+{
+       return psci_cpu_suspend_feature &
+                               PSCI_1_0_FEATURES_CPU_SUSPEND_PF_MASK;
+}
+
 bool psci_power_state_loses_context(u32 state)
 {
-       return state & PSCI_0_2_POWER_STATE_TYPE_MASK;
+       const u32 mask = psci_has_ext_power_state() ?
+                                       PSCI_1_0_EXT_POWER_STATE_TYPE_MASK :
+                                       PSCI_0_2_POWER_STATE_TYPE_MASK;
+
+       return state & mask;
 }
 
 bool psci_power_state_is_valid(u32 state)
 {
-       return !(state & ~PSCI_0_2_POWER_STATE_MASK);
+       const u32 valid_mask = psci_has_ext_power_state() ?
+                              PSCI_1_0_EXT_POWER_STATE_MASK :
+                              PSCI_0_2_POWER_STATE_MASK;
+
+       return !(state & ~valid_mask);
 }
 
 static int psci_to_linux_errno(int errno)

@@ -203,6 +223,14 @@ static int __init psci_features(u32 psci_func_id)
                              psci_func_id, 0, 0);
 }
 
+static void __init psci_init_cpu_suspend(void)
+{
+       int feature = psci_features(psci_function_id[PSCI_FN_CPU_SUSPEND]);
+
+       if (feature != PSCI_RET_NOT_SUPPORTED)
+               psci_cpu_suspend_feature = feature;
+}
+
 /*
  * Detect the presence of a resident Trusted OS which may cause CPU_OFF to
  * return DENIED (which would be fatal).

@@ -287,6 +315,8 @@ static int __init psci_probe(void)
 
        psci_init_migrate();
 
+       psci_init_cpu_suspend();
+
        return 0;
 }
 

include/uapi/linux/psci.h +12 -1

index 187b828d..0a9485f 100644
@@ -58,6 +58,13 @@
 #define PSCI_0_2_POWER_STATE_AFFL_MASK         \
                                (0x3 << PSCI_0_2_POWER_STATE_AFFL_SHIFT)
 
+/* PSCI extended power state encoding for CPU_SUSPEND function */
+#define PSCI_1_0_EXT_POWER_STATE_ID_MASK       0xfffffff
+#define PSCI_1_0_EXT_POWER_STATE_ID_SHIFT      0
+#define PSCI_1_0_EXT_POWER_STATE_TYPE_SHIFT    30
+#define PSCI_1_0_EXT_POWER_STATE_TYPE_MASK     \
+                               (0x1 << PSCI_1_0_EXT_POWER_STATE_TYPE_SHIFT)
+
 /* PSCI v0.2 affinity level state returned by AFFINITY_INFO */
 #define PSCI_0_2_AFFINITY_LEVEL_ON             0
 #define PSCI_0_2_AFFINITY_LEVEL_OFF            1

@@ -78,6 +85,11 @@
 #define PSCI_VERSION_MINOR(ver)                        \
                ((ver) & PSCI_VERSION_MINOR_MASK)
 
+/* PSCI features decoding (>=1.0) */
+#define PSCI_1_0_FEATURES_CPU_SUSPEND_PF_SHIFT 1
+#define PSCI_1_0_FEATURES_CPU_SUSPEND_PF_MASK  \
+                       (0x1 << PSCI_1_0_FEATURES_CPU_SUSPEND_PF_SHIFT)
+
 /* PSCI return values (inclusive of all PSCI versions) */
 #define PSCI_RET_SUCCESS                       0
 #define PSCI_RET_NOT_SUPPORTED                 -1
--

2.2.1

Spam Status: Spamassassin CRM114

Quoted 11 lines · Lorenzo Pieralisi

PSCI v1.0 augmented the power_state parameter format specification (extended stateid) and introduced a way to probe it through the PSCI_FEATURES interface.

This patch implements code that detects the power_state format at run-time through the PSCI_FEATURES interface, so that the power_state argument can be properly detected and validated in the kernel according to the information provided through firmware.

Signed-off-by Lorenzo Pieralisi <[email protected]>

Cc Mark Rutland <[email protected]>

kernelci.org started finding a new boot failures in the arm-soc tree on arm64 qemu[1] and it was bisected down to this patch, which is in arm-soc in the form of commit a5c00bb28da0 (drivers: firmware: psci:
add extended stateid power_state support)

The patch doesn't revert cleanly, so I didn't dig much further, but this suggests that some more testing on qemu is needed (or does qemu need to be upgraded?)

Kevin

[1] http://kernelci.org/boot/all/job/arm-soc/kernel/v4.3-rc5-557-g159ca7e43189/

Quoted 23 lines · On Thursday 22 October 2015 15:07:06 Kevin Hilman wrote:

Quoted 11 lines · Lorenzo Pieralisi

PSCI v1.0 augmented the power_state parameter format specification (extended stateid) and introduced a way to probe it through the PSCI_FEATURES interface.

This patch implements code that detects the power_state format at run-time through the PSCI_FEATURES interface, so that the power_state argument can be properly detected and validated in the kernel according to the information provided through firmware.

Signed-off-by Lorenzo Pieralisi <[email protected]>

Cc Mark Rutland <[email protected]>

kernelci.org started finding a new boot failures in the arm-soc tree on arm64 qemu[1] and it was bisected down to this patch, which is in arm-soc in the form of commit a5c00bb28da0 (drivers: firmware: psci:
add extended stateid power_state support)

The patch doesn't revert cleanly, so I didn't dig much further, but this suggests that some more testing on qemu is needed (or does qemu need to be upgraded?)

Quoted 4 lines

Kevin

[1] http://kernelci.org/boot/all/job/arm-soc/kernel/v4.3-rc5-557-g159ca7e43189/

Could it be that qemu claims to support psci-1.0 but is actually not compatible?

Problem with Qemu emulation is that it does not emulate the PSCI 1.0 specs correctly (it does not even consider PSCI 1.0 functions proper PSCI calls), I tested it and I think we should update Qemu as we did with KVM kernel code instead of working around it by dodging the problem in the PSCI implementation by adding code that checks the PSCI version before issuing the PSCI calls through the respective conduit.

Thoughts appreciated.

Quoted 9 lines · On Friday 23 October 2015 11:44:58 Lorenzo Pieralisi wrote:

Problem with Qemu emulation is that it does not emulate the PSCI 1.0 specs correctly (it does not even consider PSCI 1.0 functions proper PSCI calls), I tested it and I think we should update Qemu as we did with KVM kernel code instead of working around it by dodging the problem in the PSCI implementation by adding code that checks the PSCI version before issuing the PSCI calls through the respective conduit.

Quoted 1 line

Thoughts appreciated.

I think we really cannot break existing qemu installations, but need a way to detect whether we are dealing with a broken qemu (and warn about that) or with a working PSCI implementation.

Fixing qemu is of course a good idea, but it's not sufficient.

Quoted 16 lines · Arnd Bergmann

Quoted 10 lines · On Friday 23 October 2015 11:44:58 Lorenzo Pieralisi wrote:

Problem with Qemu emulation is that it does not emulate the PSCI 1.0 specs correctly (it does not even consider PSCI 1.0 functions proper PSCI calls), I tested it and I think we should update Qemu as we did with KVM kernel code instead of working around it by dodging the problem in the PSCI implementation by adding code that checks the PSCI version before issuing the PSCI calls through the respective conduit.

Thoughts appreciated.

I think we really cannot break existing qemu installations, but need a way to detect whether we are dealing with a broken qemu (and warn about that) or with a working PSCI implementation.

Quoted 1 line

Fixing qemu is of course a good idea, but it's not sufficient.

I will patch the PSCI back-end in the kernel to issue PSCI_FEATURES calls only if the PSCI version detected is 1.0, therefore solving the issue, it is not necessary according to the specs, but that's belt and braces and sorts this niggle out.

I will send a patch shortly to be applied on top of arm-soc drivers/psci.

Quoted 24 lines · Lorenzo Pieralisi

Quoted 10 lines · Arnd Bergmann

Quoted 9 lines · On Friday 23 October 2015 11:44:58 Lorenzo Pieralisi wrote:

Problem with Qemu emulation is that it does not emulate the PSCI 1.0 specs correctly (it does not even consider PSCI 1.0 functions proper PSCI calls), I tested it and I think we should update Qemu as we did with KVM kernel code instead of working around it by dodging the problem in the PSCI implementation by adding code that checks the PSCI version before issuing the PSCI calls through the respective conduit.

Quoted 7 lines

Quoted 1 line

Thoughts appreciated.

I think we really cannot break existing qemu installations, but need a way to detect whether we are dealing with a broken qemu (and warn about that) or with a working PSCI implementation.

Fixing qemu is of course a good idea, but it's not sufficient.

I will patch the PSCI back-end in the kernel to issue PSCI_FEATURES calls only if the PSCI version detected is 1.0, therefore solving the issue, it is not necessary according to the specs, but that's belt and braces and sorts this niggle out.

Quoted 1 line

I will send a patch shortly to be applied on top of arm-soc drivers/psci.

Thanks!

In parallel, since you understandn better what qemu is/isn't doing, can you ping the qemu folks about this bug?

PSCI 1.0 is designed to be fully compliant to the PSCI 0.2 specification, with minor differences that are described in the PSCI specification.

In particular, PSCI v1.0 augments the specification with a new power_state format (extended stateid - probeable through the PSCI_FEATURES call), changes some function return codes and functions usage requirements wrt PSCI 0.2. These changes mean that 1.0 vs 0.2 compliancy should be enforced through a DT compatible string that allows firmware to specify 1.0 only compliancy so that older kernels are prevented from using PSCI 1.0 FW implementations in a non-compatible way (eg by calling a 1.0 FW implementation and expecting 0.2 behaviour).

This patch adds PSCI 1.0 DT bindings and related compatible string.

Signed-off-by Lorenzo Pieralisi <[email protected]>

Acked-by Sudeep Holla <[email protected]>

Cc Mark Rutland <[email protected]>

---
 Documentation/devicetree/bindings/arm/psci.txt | 6 ++++++
 drivers/firmware/psci.c                        | 1 +
 2 files changed, 7 insertions(+)

Documentation/devicetree/bindings/arm/psci.txt +6 -0

index 5aa40ed..a9adab8 100644
@@ -31,6 +31,10 @@ Main node required properties:
 					support, but are permitted to be present for compatibility with
 					existing software when "arm,psci" is later in the compatible list.
 
+				* "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is
+					backward compatible with PSCI 0.2 with minor specification updates,
+					as defined in the PSCI specification[2].
+
  - method        : The method of calling the PSCI firmware. Permitted
                    values are:
 

@@ -100,3 +104,5 @@ Case 3: PSCI v0.2 and PSCI v0.1.
 
 [1] Kernel documentation - ARM idle states bindings
     Documentation/devicetree/bindings/arm/idle-states.txt
+[2] Power State Coordination Interface (PSCI) specification
+    http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

drivers/firmware/psci.c +1 -0

index bd2ba5b..5b544d7 100644
@@ -392,6 +392,7 @@ out_put_node:
 static const struct of_device_id psci_of_match[] __initconst = {
 	{ .compatible = "arm,psci",	.data = psci_0_1_init},
 	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
+	{ .compatible = "arm,psci-1.0",	.data = psci_0_2_init},
 	{},
 };
 

Hi Lorenzo,

sorry for this late reply, but this came up recently during an IRC discussion:

Quoted 3 lines · Lorenzo Pieralisi

PSCI 1.0 is designed to be fully compliant to the PSCI 0.2 specification, with minor differences that are described in the PSCI specification.

So if PSCI 1.0 is fully compliant to the 0.2 spec and PSCI 0.2 mandates a version function, why do we need a new binding here?

IIRC device tree bindings are just for features that cannot be probed, whereas the availability of PSCI 1.0 features can be safely probed by issuing the PSCI_VERSION call and checking for bits [16:32] >= 1. So can't we just skip this extra binding and keep the compatible string to 0.2 for every upcoming PSCI implementation?

This should actually be the last binding we need, since availability of specific functions can be checked as well with the PSCI_FEATURES call in the future.

Hi Lorenzo,

sorry for this late reply, but this came up recently during an IRC discussion:

Quoted 3 lines · Lorenzo Pieralisi

PSCI 1.0 is designed to be fully compliant to the PSCI 0.2 specification, with minor differences that are described in the PSCI specification.

So if PSCI 1.0 is fully compliant to the 0.2 spec and PSCI 0.2 mandates a version function, why do we need a new binding here?
IIRC device tree bindings are just for features that cannot be probed, whereas the availability of PSCI 1.0 features can be safely probed by issuing the PSCI_VERSION call and checking for bits [16:32] >= 1. So can't we just skip this extra binding and keep the compatible string to 0.2 for every upcoming PSCI implementation?
This should actually be the last binding we need, since availability of specific functions can be checked as well with the PSCI_FEATURES call in the future.

Cheers,
Andre

Quoted 56 lines

In particular, PSCI v1.0 augments the specification with a new power_state format (extended stateid - probeable through the PSCI_FEATURES call), changes some function return codes and functions usage requirements wrt PSCI 0.2. These changes mean that 1.0 vs 0.2 compliancy should be enforced through a DT compatible string that allows firmware to specify 1.0 only compliancy so that older kernels are prevented from using PSCI 1.0 FW implementations in a non-compatible way (eg by calling a 1.0 FW implementation and expecting 0.2 behaviour).

This patch adds PSCI 1.0 DT bindings and related compatible string.

Signed-off-by Lorenzo Pieralisi <[email protected]>

Acked-by Sudeep Holla <[email protected]>

Cc Mark Rutland <[email protected]>

---
 Documentation/devicetree/bindings/arm/psci.txt | 6 ++++++
 drivers/firmware/psci.c                        | 1 +
 2 files changed, 7 insertions(+)

Documentation/devicetree/bindings/arm/psci.txt +6 -0

index 5aa40ed..a9adab8 100644
@@ -31,6 +31,10 @@ Main node required properties:
 					support, but are permitted to be present for compatibility with
 					existing software when "arm,psci" is later in the compatible list.
 
+				* "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is
+					backward compatible with PSCI 0.2 with minor specification updates,
+					as defined in the PSCI specification[2].
+
  - method        : The method of calling the PSCI firmware. Permitted
                    values are:
 

@@ -100,3 +104,5 @@ Case 3: PSCI v0.2 and PSCI v0.1.
 
 [1] Kernel documentation - ARM idle states bindings
     Documentation/devicetree/bindings/arm/idle-states.txt
+[2] Power State Coordination Interface (PSCI) specification
+    http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

drivers/firmware/psci.c +1 -0

index bd2ba5b..5b544d7 100644
@@ -392,6 +392,7 @@ out_put_node:
 static const struct of_device_id psci_of_match[] __initconst = {
 	{ .compatible = "arm,psci",	.data = psci_0_1_init},
 	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
+	{ .compatible = "arm,psci-1.0",	.data = psci_0_2_init},
 	{},
 };
 

This series is a v2 of a previous posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/347352.html

v1 -> v2:

- rebased against v4.2-rc1
- added version to 1.0 specific macros

The PSCI v1.0 specification[1] introduces a brand new set of features (ie OS initiated mode and system suspend being the most notable ones) and provides updates to the PSCI 0.2 specification, keeping backward compatibility.

PSCI v1.0 applies minor changes to function return codes and function behaviour (ie AFFINITY_INFO requirements, INVALID_ADDRESS return value) and introduces a new power_state parameter format (extended stateid) that is probeable with the newly introduced PSCI_FEATURES call.

This series upgrades the current kernel PSCI layer implementation with a set of patches that make the kernel PSCI v1.0 compliant.

The series augments the PSCI firmware layer with a hook to retrieve the features for a specific PSCI function (ie based on the PSCI_FEATURES call) and uses it to detect the power_state parameter format, updating the power_state parameter handling functions accordingly.

In order to prevent firmware interfaces mismatch, a new compatible string is added to the DT bindings to characterize a 1.0 compliant firmware interface.

The series is built on top of M.Rutland's patch series:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/353795.html

Tested on a Juno board.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

Lorenzo Pieralisi (5):
drivers: firmware: psci: add INVALID_ADDRESS return value
drivers: firmware: psci: move power_state handling to generic code
drivers: firmware: psci: add PSCI_FEATURES call
drivers: firmware: psci: add extended stateid power_state support
drivers: firmware: psci: add PSCI v1.0 DT bindings

 Documentation/devicetree/bindings/arm/psci.txt |  6 +++
 arch/arm64/kernel/psci.c                       | 14 -------
 drivers/firmware/psci.c                        | 53 ++++++++++++++++++++++++++
 include/linux/psci.h                           |  2 +
 include/uapi/linux/psci.h                      | 15 ++++++++
 5 files changed, 76 insertions(+), 14 deletions(-)

Signature · 1 line

2.2.1

Quoted 31 lines · Lorenzo Pieralisi

This series is a v2 of a previous posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/347352.html

v1 -> v2:

- rebased against v4.2-rc1
- added version to 1.0 specific macros

The PSCI v1.0 specification[1] introduces a brand new set of features (ie OS initiated mode and system suspend being the most notable ones) and provides updates to the PSCI 0.2 specification, keeping backward compatibility.

PSCI v1.0 applies minor changes to function return codes and function behaviour (ie AFFINITY_INFO requirements, INVALID_ADDRESS return value) and introduces a new power_state parameter format (extended stateid) that is probeable with the newly introduced PSCI_FEATURES call.

This series upgrades the current kernel PSCI layer implementation with a set of patches that make the kernel PSCI v1.0 compliant.

The series augments the PSCI firmware layer with a hook to retrieve the features for a specific PSCI function (ie based on the PSCI_FEATURES call) and uses it to detect the power_state parameter format, updating the power_state parameter handling functions accordingly.

In order to prevent firmware interfaces mismatch, a new compatible string is added to the DT bindings to characterize a 1.0 compliant firmware interface.

Quoted 5 lines

The series is built on top of M.Rutland's patch series:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/353795.html

Tested on a Juno board.

Rebased against 4.3-rc1 (that includes the patch series above), if there are no objections I will queue this series for v4.4.

Thanks,
Lorenzo

Quoted 20 lines

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

Lorenzo Pieralisi (5):
drivers: firmware: psci: add INVALID_ADDRESS return value
drivers: firmware: psci: move power_state handling to generic code
drivers: firmware: psci: add PSCI_FEATURES call
drivers: firmware: psci: add extended stateid power_state support
drivers: firmware: psci: add PSCI v1.0 DT bindings

 Documentation/devicetree/bindings/arm/psci.txt |  6 +++
 arch/arm64/kernel/psci.c                       | 14 -------
 drivers/firmware/psci.c                        | 53 ++++++++++++++++++++++++++
 include/linux/psci.h                           |  2 +
 include/uapi/linux/psci.h                      | 15 ++++++++
 5 files changed, 76 insertions(+), 14 deletions(-)

Signature · 1 line

2.2.1