Re: [PATCH RFC 2/2] Documentation: arm: define DT C-states bindings

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

 




On Dec 3, 2013, at 4:40 AM, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote:

> On Mon, Dec 02, 2013 at 06:08:16PM +0000, Kumar Gala wrote:
>> 
>> On Dec 2, 2013, at 10:20 AM, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> 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.
>> 
>> Where is this spec'd today in the kernel?
> 
> How can it be in the kernel given that these bindings have just been posted ?
> I started coding the layer managing the C-states in the kernel, even
> though I would avoid writing it and then restart from scratch if these
> bindings are scrapped. Bindings should not depend on kernel code, it
> is the other way around, right ?

I was guessing that there is existing code in the kernel that uses some platform data structures.  I was wondering what that code looked like today.

> 
> [...]
> 
>>> +===========================================
>>> +2 - state node
>>> +===========================================
>>> +
>>> +A state node represents a C-state description and must be defined as follows:
>>> +
>>> +- state node
>>> +
>>> +     Description: must be child of the cpu-power-states node.
>>> +
>>> +     The state node name must be "state", with unit address provided by the
>>> +     "reg" property following standard DT requirements[4].
>>> +
>>> +     A state node defines the following properties:
>>> +
>>> +     - reg
>>> +             Usage: Required
>>> +             Value type: <u32>
>>> +             Definition: Standard device tree property [4] used for
>>> +                         enumeration purposes.
>> 
>> I'm not sure what purpose reg is really serving here.
> 
> Enumeration, that's it.
> 
>>> +
>>> +     - 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).
>> 
>> any reason not to call it c-state-index"
> 
> Well, they are called "state" nodes, so I called it "index".
> 
> I really do not care, can change it if we think we should call states
> c-states.
> 
>>> +
>>> +     - entry-method
>>> +             Value type: <stringlist>
>>> +             Usage: Required
>>> +             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: <u32>
>>> +             Definition: Worst case latency in microseconds required to
>>> +                         enter and exit the C-state.
>>> +
>>> +     - min-residency
>>> +             Usage: Required
>>> +             Value type: <u32>
>>> +             Definition: 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).
>>> +                         This parameter depends on the operating conditions
>>> +                         (operating point, cache state) and must assume
>>> +                         worst case scenario.
>>> +
>>> +     - cpus
>>> +             Usage: Optional
>>> +             Value type: <phandle>
>>> +             Definition: If defined, the phandle points to a node in the
>>> +                         cpu-map[2] representing all CPUs on which C-state
>>> +                         is valid. If not present or system is UP, the
>>> +                         C-state has to be considered valid for all CPUs in
>>> +                         the system.
>>> +
>>> +     - affinity
>>> +             Usage: Optional
>>> +             Value type: <phandle>
>>> +             Definition: If defined, phandle points to a node in the
>>> +                         cpu-map[2] that represents all CPUs that are
>>> +                         affected (ie share) by the C-state and have to
>>> +                         be coordinated on C-state entry/exit. If not
>>> +                         present or system is UP, the C-state is local to
>>> +                         a CPU and need no coordination (ie it is a CPU
>>> +                         state, that does not require coordination with
>>> +                         other CPUs). If present, the affinity property
>>> +                         must contain a phandle to a cpu-map node that
>>> +                         represents a subset, possibly inclusive of the
>>> +                         CPUs described through the cpus property.
>>> +
>>> +     - power-depth
>>> +             Usage: Required
>>> +             Value type: <u32>
>>> +             Definition: Integer value, starting from 2 (value 0 meaning
>>> +                         running and value 1 representing power depth of
>>> +                         wfi (C1)), that defines the level of depth of a
>>> +                         power state.
>>> +                         The system denotes power states with different
>>> +                         depths, an increasing value meaning less power
>>> +                         consumption and might involve powering down more
>>> +                         components.  Devices that are affected by
>>> +                         C-states entry must define the maximum power
>>> +                         depth supported in their respective device tree
>>> +                         bindings so that OSPM can take decision on how
>>> +                         to handle the device in question when the C-state
>>> +                         is entered. All devices (per-CPU or external) with
>>> +                         a power depth lower than the one defined in the
>>> +                         C-state entry stop operating when the C-state
>>> +                         is entered and action is required by OSPM to
>>> +                         guarantee their logic and memory content is saved
>>> +                         restored to guarantee proper functioning.
>> 
>> How is this different from the c-state index?
> 
> The idea, not sure it is worthwhile, is to represent a unique value in
> the system. There can be multiple eg C2 states (two clusters in two
> different power domains) with same index and different power depths.
> 
> Devices attached to power domains can check the power depth to detect if
> the CPU must be prevented from entering the C-state or not, and on the
> other hand, power depth allows to understand if a device state must be
> saved and restored.
> 
> I should have added an example but there is already lots of stuff to
> discuss for bindings as they are IMHO.
> 
> Lorenzo
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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