[PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
Amit Kucheria
amit.kucheria at linaro.org
Tue Jan 21 09:35:11 EST 2014
Hi Lorenzo,
On Mon, Jan 20, 2014 at 11:17 PM, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> ARM based platforms implement a variety of power management schemes that
> allow processors to enter at run-time low-power states, aka C-states
> in ACPI jargon. The parameters defining these C-states vary on a per-platform
> basis forcing the OS to hardcode the state parameters in platform
> specific static tables whose size grows as the number of platforms supported
> in the kernel increases and hampers device drivers standardization.
>
> Therefore, this patch aims at standardizing C-state device tree bindings for
> ARM platforms. Bindings define C-state parameters inclusive of entry methods
> and state latencies, to allow operating systems to retrieve the
> configuration entries from the device tree and initialize the related
> power management drivers, paving the way for common code in the kernel
> to deal with power states and removing the need for static data in current
> and previous kernel versions.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
> Documentation/devicetree/bindings/arm/c-states.txt | 774 +++++++++++++++++++++
> Documentation/devicetree/bindings/arm/cpus.txt | 10 +
> 2 files changed, 784 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/c-states.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/c-states.txt b/Documentation/devicetree/bindings/arm/c-states.txt
s/c-states/idle-states?
While C-states are widely used when talking about idle-states as
you've noted, idle-states are still the correct generic term for them.
> new file mode 100644
> index 0000000..0b5617b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/c-states.txt
> @@ -0,0 +1,774 @@
> +==========================================
> +ARM C-states binding description
> +==========================================
> +
> +==========================================
> +1 - Introduction
> +==========================================
> +
> +ARM systems contain HW capable of managing power consumption dynamically,
> +where cores can be put in different low-power states (ranging from simple
> +wfi to power gating) according to OSPM policies. Borrowing concepts
> +from the ACPI specification[1], the CPU states representing the range of
> +dynamic states that a processor can enter at run-time, aka C-state, can be
> +specified through device tree bindings representing the parameters required to
> +enter/exit specific C-states on a given processor.
> +
> +The state an ARM CPU can be put into is loosely identified by one of the
> +following operating modes:
> +
> +- Running:
> + # Processor core is executing instructions
> +
> +- Wait for Interrupt:
> + # An ARM processor enters wait for interrupt (WFI) low power
> + state by executing a wfi instruction. When a processor enters
> + wfi state it disables most of the clocks while keeping the processor
> + powered up. This state is standard on all ARM processors and it is
> + defined as C1 in the remainder of this document.
> +
> +- Dormant:
> + # Dormant mode is entered by executing wfi instructions and by sending
> + platform specific commands to the platform power controller (coupled
> + with processor specific SW/HW control sequences).
> + In dormant mode, most of the processor control and debug logic is
> + powered up but cache RAM can be put in retention state, providing
> + additional power savings.
> +
> +- Sleep:
> + # Sleep mode is entered by executing the wfi instruction and by sending
> + platform specific commands to the platform power controller (coupled
> + with processor specific SW/HW control sequences). In sleep mode, a
> + processor and its caches are shutdown, the entire processor state is
> + lost.
> +
> +Building on top of the previous processor modes, ARM platforms implement power
Nitpick: s/previous/above
> +management schemes that allow an OS PM implementation to put the processor in
> +different CPU states (C-states). C-states parameters (eg latency) are
> +platform specific and need to be characterized with bindings that provide the
> +required information to OSPM code so that it can build the required tables and
> +use them at runtime.
> +
> +The device tree binding definition for ARM C-states is the subject of this
> +document.
> +
> +===========================================
> +2 - cpu-power-states node
> +===========================================
> +
> +ARM processor C-states are defined within the cpu-power-states node, which is
> +a direct child of the cpus node and provides a container where the processor
> +states, defined as device tree nodes, are listed.
> +
> +- cpu-power-states node
What do you think of s/cpu-power-states/cpu-idle-states?
CPU Power management is more than just idle. Unless you have plans to
add more properties to the cpu-power-states node later.
> +
> + Usage: Optional - On ARM systems, is a container of processor C-state
> + nodes. If the system does not provide CPU power
> + management capabilities or the processor just
> + supports WFI (C1 state) a cpu-power-states node is
> + not required.
> +
> + Description: cpu-power-states node is a container node, where its
> + subnodes describe the CPU low-power C-states.
> +
> + Node name must be "cpu-power-states".
> +
> + The cpu-power-states node's parent node must be cpus node.
> +
> + The cpu-power-states node's child nodes can be:
> +
> + - one or more state nodes
> +
> + Any other configuration is considered invalid.
> +
> +The nodes describing the C-states (state) can only be defined within the
> +cpu-power-states node.
> +
> +Any other configuration is consider invalid and therefore must be ignored.
> +
> +===========================================
> +2 - state node
> +===========================================
> +
> +A state node represents a C-state description and must be defined as follows:
> +
> +- state node
> +
> + Description: must be child of either the cpu-power-states node or
> + a state node.
> +
> + The state node name shall be "stateN", where N = {0, 1, ...} is
> + the node number; state nodes which are siblings within a single common
> + parent node must be given a unique and sequential N value, starting
> + from 0.
> +
> + A state node can contain state child nodes. Child nodes inherit
> + properties from the parent state nodes that work as state
> + properties aggregators (ie contain properties valid on all state
> + nodes children).
> +
> + A state node defines the following properties (either explicitly
> + or by inheriting them from a parent node):
> +
> + - compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must be "arm,cpu-power-state".
> +
> + - index
> + Usage: Required
> + Value type: <u32>
> + Definition: It represents C-state index, starting from 2 (index
> + 0 represents the processor state "running" and
> + index 1 represents processor mode "WFI"; indexes 0
> + and 1 are standard ARM states that need not be
> + described).
> +
> + - power-domain
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: List of phandle and power domain specifiers
> + as defined by bindings of power controller
> + specified by the phandle [3]. It represents the
> + power domains associated with the C-state. The
> + power domains list can be used by OSPM to
> + retrieve the devices belonging to the power
> + domains and carry out corresponding actions to
> + preserve functionality across power cycles
> + (ie context save/restore, cache flushing).
> +
> + - entry-method
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Describes the method by which a CPU enters the
> + C-state. This property is required and must be one
> + of:
> +
> + - "psci"
> + ARM Standard firmware interface
> +
> + - "[vendor],[method]"
> + An implementation dependent string with
> + format "vendor,method", where vendor is a string
> + denoting the name of the manufacturer and
> + method is a string specifying the mechanism
> + used to enter the C-state.
> +
> + - psci-power-state
> + Usage: Required if entry-method property value is set to
> + "psci".
> + Value type: <u32>
> + Definition: power_state parameter to pass to the PSCI
> + suspend call to enter the C-state.
> +
> + - latency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: List of u32 values representing worst case latency
> + in microseconds required to enter and exit the
> + C-state, one value per OPP [2]. The list should
> + be specified in the same order as the operating
> + points property list of the cpu this state is
> + valid on.
> + If no OPP bindings are present, the latency value
> + is associated with the current OPP of CPUs in the
> + system.
DT-newbie here. What would happen if a vendor does not characterise
the latency at each OPP? IOW, the table only contains latency values
for a subset of the OPPs.
> +
> + - min-residency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: List of u32 values representing time in
> + microseconds required for the CPU to be in
> + the C-state to make up for the dynamic power
> + consumed to enter/exit the C-state in order to
> + break even in terms of power consumption compared
> + to C1 state (wfi), one value per-OPP [2].
> + This parameter depends on the operating conditions
> + (HW state) and must assume worst case scenario.
> + The list should be specified in the same order as
> + the operating points property list of the cpu this
> + state is valid on.
> + If no OPP bindings are present the min-residency
> + value is associated with the current OPP of CPUs
> + in the system.
Same question as latency above.
> +
> +===========================================
> +3 - Examples
> +===========================================
> +
> +Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
^^^^^^^^^^^^^
clusters of cpus?
> +
> +pd_clusters: power-domain-clusters at 80002000 {
> + compatible = "arm,power-controller";
> + reg = <0x0 0x80002000 0x0 0x1000>;
> + #power-domain-cells = <1>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pd_cores: power-domain-cores at 80000000 {
> + compatible = "arm,power-controller";
> + reg = <0x0 0x80000000 0x0 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +};
> +
<snip>
More information about the linux-arm-kernel
mailing list