schemas: wakeup-source: Possibility for power states #150
Conversation
dtschema/schemas/wakeup-source.yaml
Outdated
| type: boolean | ||
| oneOf: | ||
| - type: boolean | ||
| - $ref: /schemas/types.yaml#/definitions/string-array |
There was a problem hiding this comment.
You need to constrain the values somewhere. Either here or in device schema (which I do not see you doing here https://lore.kernel.org/all/20241219-topic-am62-partialio-v6-12-b4-v4-2-1cb8eabd407e@baylibre.com/ ). If here, then the next question is - what is suspend? What sort of suspend? Shall we include all known/supported by Linux? s2idle? s2ram? or even ACPI states?
Maybe 'suspend' would mean all of them and if anyone needs more fine-grained then we add 'suspend-to-ram'?
Or maybe we should use something from Documentation/devicetree/bindings/cpu/idle-states.yaml ?
There was a problem hiding this comment.
I looked into the cpu/idle-states.yaml and Documentation/devicetree/bindings/power/domain-idle-state.yaml as well. I think these would be a flexible way to define the states without it being hardcoded strings. But they require entry/exit latency which does not make sense for Partial-IO as it is a power-off state. It can't be resumed, just wakeup and do a normal boot.
Maybe we could drop some of the required properties to be able to describe it as part of these idle states?
Or introduce poweroff-states that describe states that do not offer a resume path, just a boot? wakeup-source could then be a list of phandles to one of these nodes each?
There was a problem hiding this comment.
Maybe we could drop some of the required properties to be able to describe it as part of these idle states?
Or introduce poweroff-states that describe states that do not offer a resume path, just a boot? wakeup-source could then be a list of phandles to one of these nodes each
I think domain-idle-states are specific to PM domains, so when I proposed to use their approach I thought to rather build on top or rework, not use directly. You do not need entry/exit latencies now, but we might need them in the future, so as you said - hard-coded strings are a bit limited.
I think you could go with entirely new bindings "system-idle-states" with as little properties as just name ("idle-state-name"). This can grow later.
I do not see your patchset introducing DTS user at all (and this will a blocker also for dtschema - why do we want all this if there is no DTS user?), so tricky to say what you still need, but I guess you need to differentiate between suspend/wakeup states? If yes either by idle-state-name or by compatible.
There was a problem hiding this comment.
Thank you. This sounds good. I will rework everything.
There are DTS users in these patches, in this previous example they were still using fixed string literals:
https://lore.kernel.org/all/20241219-topic-mcan-wakeup-source-v6-12-v6-5-1356c7f7cfda@baylibre.com/
I will rework all of it and update everything.
Add a new binding to describe system states. Many new SoCs have a number of different states the system as a whole can be in. Certain devices or parts of the SoC could be for example powered off. As an example am62a and am62p have states called 'Partial-IO', 'IO+DDR' and 'MCU Only' which serve different needs and have different parts enabled/disabled. Signed-off-by: Markus Schneider-Pargmann <[email protected]>
wakeup-source in its current form ignores system states. But with modern SoCs there are many different system states that have a different set of devices enabled. Also there are more complex wakeup mechanisms available. As an example TI's am62 SoC has a power state called 'Partial-IO' in which most of the SoC is powered off and only the pin logic of a few pins is active that can wakeup the SoC. But most devices that are usually able to wakeup the SoC are not capable to do it in Partial-IO. In order to properly describe the wakeup-source property depending on the system state, this patch extends the definition to be either boolean or a list of system state phandles in which this device is capable of wakeup. Signed-off-by: Markus Schneider-Pargmann <[email protected]>
scosu
force-pushed
the
topic/wakeup-source-power
branch
from
2564f36 to
ce18ad8
Compare
wakeup-source in its current form ignores power states. But with modern SoCs there are many powerstates that have a different set of devices enabled. Also there are more complex wakeup mechanisms available.
As an example TI's am62 SoC has a power state called 'Partial-IO' in which most of the SoC is powered off and only a small device logic is present for a few select devices that can still wakeup the SoC. But most devices that are usually able to wakeup the SoC are not capable to do it in Partial-IO.
In order to properly describe the wakeup-source property depending on the power state, this patch extends the definition to be either boolean or a list of power state names in which this device is capable of wakeup.
This is the Linux Kernel series that adds support for Partial-IO:
https://lore.kernel.org/all/20241219-topic-am62-partialio-v6-12-b4-v4-0-1cb8eabd407e@baylibre.com/
This is was my previous patch adding this binding before realizing the wakeup-source property is defined in this schema repository:
https://lore.kernel.org/all/20241219-topic-mcan-wakeup-source-v6-12-v6-1-1356c7f7cfda@baylibre.com/