206 lines
6.9 KiB
Plaintext
206 lines
6.9 KiB
Plaintext
* Generic PM domains
|
|
|
|
System on chip designs are often divided into multiple PM domains that can be
|
|
used for power gating of selected IP blocks for power saving by reduced leakage
|
|
current.
|
|
|
|
This device tree binding can be used to bind PM domain consumer devices with
|
|
their PM domains provided by PM domain providers. A PM domain provider can be
|
|
represented by any node in the device tree and can provide one or more PM
|
|
domains. A consumer node can refer to the provider by a phandle and a set of
|
|
phandle arguments (so called PM domain specifiers) of length specified by the
|
|
#power-domain-cells property in the PM domain provider node.
|
|
|
|
==PM domain providers==
|
|
|
|
Required properties:
|
|
- #power-domain-cells : Number of cells in a PM domain specifier;
|
|
Typically 0 for nodes representing a single PM domain and 1 for nodes
|
|
providing multiple PM domains (e.g. power controllers), but can be any value
|
|
as specified by device tree binding documentation of particular provider.
|
|
|
|
Optional properties:
|
|
- power-domains : A phandle and PM domain specifier as defined by bindings of
|
|
the power controller specified by phandle.
|
|
Some power domains might be powered from another power domain (or have
|
|
other hardware specific dependencies). For representing such dependency
|
|
a standard PM domain consumer binding is used. When provided, all domains
|
|
created by the given provider should be subdomains of the domain
|
|
specified by this binding. More details about power domain specifier are
|
|
available in the next section.
|
|
|
|
- domain-idle-states : A phandle of an idle-state that shall be soaked into a
|
|
generic domain power state. The idle state definitions are
|
|
compatible with domain-idle-state specified in [1]. phandles
|
|
that are not compatible with domain-idle-state will be
|
|
ignored.
|
|
The domain-idle-state property reflects the idle state of this PM domain and
|
|
not the idle states of the devices or sub-domains in the PM domain. Devices
|
|
and sub-domains have their own idle-states independent of the parent
|
|
domain's idle states. In the absence of this property, the domain would be
|
|
considered as capable of being powered-on or powered-off.
|
|
|
|
- operating-points-v2 : Phandles to the OPP tables of power domains provided by
|
|
a power domain provider. If the provider provides a single power domain only
|
|
or all the power domains provided by the provider have identical OPP tables,
|
|
then this shall contain a single phandle. Refer to ../opp/opp.txt for more
|
|
information.
|
|
|
|
Example:
|
|
|
|
power: power-controller@12340000 {
|
|
compatible = "foo,power-controller";
|
|
reg = <0x12340000 0x1000>;
|
|
#power-domain-cells = <1>;
|
|
};
|
|
|
|
The node above defines a power controller that is a PM domain provider and
|
|
expects one cell as its phandle argument.
|
|
|
|
Example 2:
|
|
|
|
parent: power-controller@12340000 {
|
|
compatible = "foo,power-controller";
|
|
reg = <0x12340000 0x1000>;
|
|
#power-domain-cells = <1>;
|
|
};
|
|
|
|
child: power-controller@12341000 {
|
|
compatible = "foo,power-controller";
|
|
reg = <0x12341000 0x1000>;
|
|
power-domains = <&parent 0>;
|
|
#power-domain-cells = <1>;
|
|
};
|
|
|
|
The nodes above define two power controllers: 'parent' and 'child'.
|
|
Domains created by the 'child' power controller are subdomains of '0' power
|
|
domain provided by the 'parent' power controller.
|
|
|
|
Example 3:
|
|
parent: power-controller@12340000 {
|
|
compatible = "foo,power-controller";
|
|
reg = <0x12340000 0x1000>;
|
|
#power-domain-cells = <0>;
|
|
domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
|
|
};
|
|
|
|
child: power-controller@12341000 {
|
|
compatible = "foo,power-controller";
|
|
reg = <0x12341000 0x1000>;
|
|
power-domains = <&parent>;
|
|
#power-domain-cells = <0>;
|
|
domain-idle-states = <&DOMAIN_PWR_DN>;
|
|
};
|
|
|
|
DOMAIN_RET: state@0 {
|
|
compatible = "domain-idle-state";
|
|
reg = <0x0>;
|
|
entry-latency-us = <1000>;
|
|
exit-latency-us = <2000>;
|
|
min-residency-us = <10000>;
|
|
};
|
|
|
|
DOMAIN_PWR_DN: state@1 {
|
|
compatible = "domain-idle-state";
|
|
reg = <0x1>;
|
|
entry-latency-us = <5000>;
|
|
exit-latency-us = <8000>;
|
|
min-residency-us = <7000>;
|
|
};
|
|
|
|
==PM domain consumers==
|
|
|
|
Required properties:
|
|
- power-domains : A list of PM domain specifiers, as defined by bindings of
|
|
the power controller that is the PM domain provider.
|
|
|
|
Optional properties:
|
|
- power-domain-names : A list of power domain name strings sorted in the same
|
|
order as the power-domains property. Consumers drivers will use
|
|
power-domain-names to match power domains with power-domains
|
|
specifiers.
|
|
|
|
Example:
|
|
|
|
leaky-device@12350000 {
|
|
compatible = "foo,i-leak-current";
|
|
reg = <0x12350000 0x1000>;
|
|
power-domains = <&power 0>;
|
|
power-domain-names = "io";
|
|
};
|
|
|
|
leaky-device@12351000 {
|
|
compatible = "foo,i-leak-current";
|
|
reg = <0x12351000 0x1000>;
|
|
power-domains = <&power 0>, <&power 1> ;
|
|
power-domain-names = "io", "clk";
|
|
};
|
|
|
|
The first example above defines a typical PM domain consumer device, which is
|
|
located inside a PM domain with index 0 of a power controller represented by a
|
|
node with the label "power".
|
|
In the second example the consumer device are partitioned across two PM domains,
|
|
the first with index 0 and the second with index 1, of a power controller that
|
|
is represented by a node with the label "power".
|
|
|
|
Optional properties:
|
|
- required-opps: This contains phandle to an OPP node in another device's OPP
|
|
table. It may contain an array of phandles, where each phandle points to an
|
|
OPP of a different device. It should not contain multiple phandles to the OPP
|
|
nodes in the same OPP table. This specifies the minimum required OPP of the
|
|
device(s), whose OPP's phandle is present in this property, for the
|
|
functioning of the current device at the current OPP (where this property is
|
|
present).
|
|
|
|
Example:
|
|
- OPP table for domain provider that provides two domains.
|
|
|
|
domain0_opp_table: opp-table0 {
|
|
compatible = "operating-points-v2";
|
|
|
|
domain0_opp_0: opp-1000000000 {
|
|
opp-hz = /bits/ 64 <1000000000>;
|
|
opp-microvolt = <975000 970000 985000>;
|
|
};
|
|
domain0_opp_1: opp-1100000000 {
|
|
opp-hz = /bits/ 64 <1100000000>;
|
|
opp-microvolt = <1000000 980000 1010000>;
|
|
};
|
|
};
|
|
|
|
domain1_opp_table: opp-table1 {
|
|
compatible = "operating-points-v2";
|
|
|
|
domain1_opp_0: opp-1200000000 {
|
|
opp-hz = /bits/ 64 <1200000000>;
|
|
opp-microvolt = <975000 970000 985000>;
|
|
};
|
|
domain1_opp_1: opp-1300000000 {
|
|
opp-hz = /bits/ 64 <1300000000>;
|
|
opp-microvolt = <1000000 980000 1010000>;
|
|
};
|
|
};
|
|
|
|
power: power-controller@12340000 {
|
|
compatible = "foo,power-controller";
|
|
reg = <0x12340000 0x1000>;
|
|
#power-domain-cells = <1>;
|
|
operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
|
|
};
|
|
|
|
leaky-device0@12350000 {
|
|
compatible = "foo,i-leak-current";
|
|
reg = <0x12350000 0x1000>;
|
|
power-domains = <&power 0>;
|
|
required-opps = <&domain0_opp_0>;
|
|
};
|
|
|
|
leaky-device1@12350000 {
|
|
compatible = "foo,i-leak-current";
|
|
reg = <0x12350000 0x1000>;
|
|
power-domains = <&power 1>;
|
|
required-opps = <&domain1_opp_1>;
|
|
};
|
|
|
|
[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
|