Re: [RFC PATCH v1 2/2] dt-bindings: arm: Add description to the new property for-s2idle-only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 13, 2020 at 03:00:14PM +0800, zhang.lyra@xxxxxxxxx wrote:
> From: Chunyan Zhang <chunyan.zhang@xxxxxxxxxx>
> 
> Add a new property for-s2idle-only. The idle-state marked with this
> property will be set with CPUIDLE_FLAG_S2IDLE during initialization
> and it would be expected to be found as deepest state for s2idle
> rather than other cases like play_idle().
> 
> Signed-off-by: Chunyan Zhang <chunyan.zhang@xxxxxxxxxx>
> ---
>  Documentation/devicetree/bindings/arm/idle-states.yaml | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.yaml b/Documentation/devicetree/bindings/arm/idle-states.yaml
> index ea805c1e6b20..cec47b3a447f 100644
> --- a/Documentation/devicetree/bindings/arm/idle-states.yaml
> +++ b/Documentation/devicetree/bindings/arm/idle-states.yaml
> @@ -263,7 +263,6 @@ patternProperties:
>      description: |
>        Each state node represents an idle state description and must be defined
>        as follows.
> -
>        The idle state entered by executing the wfi instruction (idle_standby
>        SBSA,[3][4]) is considered standard on all ARM platforms and therefore
>        must not be listed.
> @@ -283,6 +282,15 @@ patternProperties:
>               lost on state entry, otherwise it is retained.
>          type: boolean
>  
> +      for-s2idle-only:
> +        description:
> +          This indicates that the state only can be found as deepest state
> +          for s2idle rather than other cases like play_idle(). In general,
> +          the state having this property should have longer min-residency
> +          than the cpuidle target min-residency which CPU QoS constraints
> +          defines, to avoid being used by runtime cpuidle.
> +        type: boolean

This is very Linux-specific, and is encoding a policy ratehr than a
property of the state.

As on patch 1, can you please describe the expected properties of this
idle state, with some rationale as to why it's not suited for idle in
general? A real example in the commit message would be very helpful.

Thanks,
Mark.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux