Tom Rini | 53633a8 | 2024-02-29 12:33:36 -0500 | [diff] [blame] | 1 | # SPDX-License-Identifier: GPL-2.0 |
| 2 | %YAML 1.2 |
| 3 | --- |
| 4 | $id: http://devicetree.org/schemas/power/power-domain.yaml# |
| 5 | $schema: http://devicetree.org/meta-schemas/core.yaml# |
| 6 | |
| 7 | title: Generic PM domains |
| 8 | |
| 9 | maintainers: |
| 10 | - Rafael J. Wysocki <rjw@rjwysocki.net> |
| 11 | - Kevin Hilman <khilman@kernel.org> |
| 12 | - Ulf Hansson <ulf.hansson@linaro.org> |
| 13 | |
| 14 | description: |+ |
| 15 | System on chip designs are often divided into multiple PM domains that can be |
| 16 | used for power gating of selected IP blocks for power saving by reduced |
| 17 | leakage current. Moreover, in some cases the similar PM domains may also be |
| 18 | capable of scaling performance for a group of IP blocks. |
| 19 | |
| 20 | This device tree binding can be used to bind PM domain consumer devices with |
| 21 | their PM domains provided by PM domain providers. A PM domain provider can be |
| 22 | represented by any node in the device tree and can provide one or more PM |
| 23 | domains. A consumer node can refer to the provider by a phandle and a set of |
| 24 | phandle arguments (so called PM domain specifiers) of length specified by the |
| 25 | \#power-domain-cells property in the PM domain provider node. |
| 26 | |
| 27 | properties: |
| 28 | $nodename: |
| 29 | pattern: "^(power-controller|power-domain|performance-domain)([@-].*)?$" |
| 30 | |
| 31 | domain-idle-states: |
| 32 | $ref: /schemas/types.yaml#/definitions/phandle-array |
| 33 | items: |
| 34 | maxItems: 1 |
| 35 | description: | |
| 36 | Phandles of idle states that defines the available states for the |
| 37 | power-domain provider. The idle state definitions are compatible with the |
| 38 | domain-idle-state bindings, specified in ./domain-idle-state.yaml. |
| 39 | |
| 40 | Note that, the domain-idle-state property reflects the idle states of this |
| 41 | PM domain and not the idle states of the devices or sub-domains in the PM |
| 42 | domain. Devices and sub-domains have their own idle states independent of |
| 43 | the parent domain's idle states. In the absence of this property, the |
| 44 | domain would be considered as capable of being powered-on or powered-off. |
| 45 | |
| 46 | operating-points-v2: |
| 47 | description: |
| 48 | Phandles to the OPP tables of power domains that are capable of scaling |
| 49 | performance, provided by a power domain provider. If the provider provides |
| 50 | a single power domain only or all the power domains provided by the |
| 51 | provider have identical OPP tables, then this shall contain a single |
| 52 | phandle. Refer to ../opp/opp-v2-base.yaml for more information. |
| 53 | |
| 54 | "#power-domain-cells": |
| 55 | description: |
| 56 | Number of cells in a PM domain specifier. Typically 0 for nodes |
| 57 | representing a single PM domain and 1 for nodes providing multiple PM |
| 58 | domains (e.g. power controllers), but can be any value as specified |
| 59 | by device tree binding documentation of particular provider. |
| 60 | |
| 61 | power-domains: |
| 62 | description: |
| 63 | A phandle and PM domain specifier as defined by bindings of the power |
| 64 | controller specified by phandle. Some power domains might be powered |
| 65 | from another power domain (or have other hardware specific |
| 66 | dependencies). For representing such dependency a standard PM domain |
| 67 | consumer binding is used. When provided, all domains created |
| 68 | by the given provider should be subdomains of the domain specified |
| 69 | by this binding. |
| 70 | |
| 71 | required: |
| 72 | - "#power-domain-cells" |
| 73 | |
| 74 | additionalProperties: true |
| 75 | |
| 76 | examples: |
| 77 | - | |
| 78 | power: power-controller@12340000 { |
| 79 | compatible = "foo,power-controller"; |
| 80 | reg = <0x12340000 0x1000>; |
| 81 | #power-domain-cells = <1>; |
| 82 | }; |
| 83 | |
| 84 | // The node above defines a power controller that is a PM domain provider and |
| 85 | // expects one cell as its phandle argument. |
| 86 | |
| 87 | - | |
| 88 | parent2: power-controller@12340000 { |
| 89 | compatible = "foo,power-controller"; |
| 90 | reg = <0x12340000 0x1000>; |
| 91 | #power-domain-cells = <1>; |
| 92 | }; |
| 93 | |
| 94 | child2: power-controller@12341000 { |
| 95 | compatible = "foo,power-controller"; |
| 96 | reg = <0x12341000 0x1000>; |
| 97 | power-domains = <&parent2 0>; |
| 98 | #power-domain-cells = <1>; |
| 99 | }; |
| 100 | |
| 101 | // The nodes above define two power controllers: 'parent' and 'child'. |
| 102 | // Domains created by the 'child' power controller are subdomains of '0' power |
| 103 | // domain provided by the 'parent' power controller. |
| 104 | |
| 105 | - | |
| 106 | parent3: power-controller@12340000 { |
| 107 | compatible = "foo,power-controller"; |
| 108 | reg = <0x12340000 0x1000>; |
| 109 | #power-domain-cells = <0>; |
| 110 | domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>; |
| 111 | }; |
| 112 | |
| 113 | child3: power-controller@12341000 { |
| 114 | compatible = "foo,power-controller"; |
| 115 | reg = <0x12341000 0x1000>; |
| 116 | power-domains = <&parent3>; |
| 117 | #power-domain-cells = <0>; |
| 118 | domain-idle-states = <&DOMAIN_PWR_DN>; |
| 119 | }; |
| 120 | |
| 121 | domain-idle-states { |
| 122 | DOMAIN_RET: domain-retention { |
| 123 | compatible = "domain-idle-state"; |
| 124 | entry-latency-us = <1000>; |
| 125 | exit-latency-us = <2000>; |
| 126 | min-residency-us = <10000>; |
| 127 | }; |
| 128 | |
| 129 | DOMAIN_PWR_DN: domain-pwr-dn { |
| 130 | compatible = "domain-idle-state"; |
| 131 | entry-latency-us = <5000>; |
| 132 | exit-latency-us = <8000>; |
| 133 | min-residency-us = <7000>; |
| 134 | }; |
| 135 | }; |