1* Generic PM domains 2 3System on chip designs are often divided into multiple PM domains that can be 4used for power gating of selected IP blocks for power saving by reduced leakage 5current. 6 7This device tree binding can be used to bind PM domain consumer devices with 8their PM domains provided by PM domain providers. A PM domain provider can be 9represented by any node in the device tree and can provide one or more PM 10domains. A consumer node can refer to the provider by a phandle and a set of 11phandle arguments (so called PM domain specifiers) of length specified by the 12#power-domain-cells property in the PM domain provider node. 13 14==PM domain providers== 15 16Required properties: 17 - #power-domain-cells : Number of cells in a PM domain specifier; 18 Typically 0 for nodes representing a single PM domain and 1 for nodes 19 providing multiple PM domains (e.g. power controllers), but can be any value 20 as specified by device tree binding documentation of particular provider. 21 22Optional properties: 23 - power-domains : A phandle and PM domain specifier as defined by bindings of 24 the power controller specified by phandle. 25 Some power domains might be powered from another power domain (or have 26 other hardware specific dependencies). For representing such dependency 27 a standard PM domain consumer binding is used. When provided, all domains 28 created by the given provider should be subdomains of the domain 29 specified by this binding. More details about power domain specifier are 30 available in the next section. 31 32- domain-idle-states : A phandle of an idle-state that shall be soaked into a 33 generic domain power state. The idle state definitions are 34 compatible with domain-idle-state specified in [1]. 35 The domain-idle-state property reflects the idle state of this PM domain and 36 not the idle states of the devices or sub-domains in the PM domain. Devices 37 and sub-domains have their own idle-states independent of the parent 38 domain's idle states. In the absence of this property, the domain would be 39 considered as capable of being powered-on or powered-off. 40 41Example: 42 43 power: power-controller@12340000 { 44 compatible = "foo,power-controller"; 45 reg = <0x12340000 0x1000>; 46 #power-domain-cells = <1>; 47 }; 48 49The node above defines a power controller that is a PM domain provider and 50expects one cell as its phandle argument. 51 52Example 2: 53 54 parent: power-controller@12340000 { 55 compatible = "foo,power-controller"; 56 reg = <0x12340000 0x1000>; 57 #power-domain-cells = <1>; 58 }; 59 60 child: power-controller@12341000 { 61 compatible = "foo,power-controller"; 62 reg = <0x12341000 0x1000>; 63 power-domains = <&parent 0>; 64 #power-domain-cells = <1>; 65 }; 66 67The nodes above define two power controllers: 'parent' and 'child'. 68Domains created by the 'child' power controller are subdomains of '0' power 69domain provided by the 'parent' power controller. 70 71Example 3: 72 parent: power-controller@12340000 { 73 compatible = "foo,power-controller"; 74 reg = <0x12340000 0x1000>; 75 #power-domain-cells = <0>; 76 domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>; 77 }; 78 79 child: power-controller@12341000 { 80 compatible = "foo,power-controller"; 81 reg = <0x12341000 0x1000>; 82 power-domains = <&parent 0>; 83 #power-domain-cells = <0>; 84 domain-idle-states = <&DOMAIN_PWR_DN>; 85 }; 86 87 DOMAIN_RET: state@0 { 88 compatible = "domain-idle-state"; 89 reg = <0x0>; 90 entry-latency-us = <1000>; 91 exit-latency-us = <2000>; 92 min-residency-us = <10000>; 93 }; 94 95 DOMAIN_PWR_DN: state@1 { 96 compatible = "domain-idle-state"; 97 reg = <0x1>; 98 entry-latency-us = <5000>; 99 exit-latency-us = <8000>; 100 min-residency-us = <7000>; 101 }; 102 103==PM domain consumers== 104 105Required properties: 106 - power-domains : A phandle and PM domain specifier as defined by bindings of 107 the power controller specified by phandle. 108 109Example: 110 111 leaky-device@12350000 { 112 compatible = "foo,i-leak-current"; 113 reg = <0x12350000 0x1000>; 114 power-domains = <&power 0>; 115 }; 116 117The node above defines a typical PM domain consumer device, which is located 118inside a PM domain with index 0 of a power controller represented by a node 119with the label "power". 120 121[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt 122