Hi DT-folks, On 08/10/13 13:55, Sudeep KarkadaNagesha wrote: > On 07/10/13 17:01, Rob Herring wrote: >> On 10/01/2013 08:32 AM, Sudeep KarkadaNagesha wrote: >>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@xxxxxxx> >>> >>> If more than one similar devices share the same operating points(OPPs) >>> being in the same clock domain, currently we need to replicate the >>> OPP entries in all the nodes. >>> >>> This patch extends existing binding by adding a new property named >>> 'operating-points-phandle' to specify the phandle in any device node >>> pointing to another node which contains the actual OPP tuples. >>> This helps to avoid replication if multiple devices share the OPPs. >>> >>> Cc: Rob Herring <rob.herring@xxxxxxxxxxx> >>> Cc: Pawel Moll <pawel.moll@xxxxxxx> >>> Cc: Mark Rutland <mark.rutland@xxxxxxx> >>> Cc: Stephen Warren <swarren@xxxxxxxxxxxxx> >>> Cc: "Rafael J. Wysocki" <rjw@xxxxxxx> >>> Cc: Nishanth Menon <nm@xxxxxx> >>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@xxxxxxx> >>> --- >>> Documentation/devicetree/bindings/power/opp.txt | 161 ++++++++++++++++++++++-- >>> 1 file changed, 149 insertions(+), 12 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt >>> index 74499e5..f59b878 100644 >>> --- a/Documentation/devicetree/bindings/power/opp.txt >>> +++ b/Documentation/devicetree/bindings/power/opp.txt >>> @@ -4,22 +4,159 @@ SoCs have a standard set of tuples consisting of frequency and >>> voltage pairs that the device will support per voltage domain. These >>> are called Operating Performance Points or OPPs. >>> >>> -Properties: >>> +Required Properties: >>> - operating-points: An array of 2-tuples items, and each item consists >>> of frequency and voltage like <freq-kHz vol-uV>. >>> freq: clock frequency in kHz >>> vol: voltage in microvolt >>> >>> +- operating-points-phandle: phandle to the device tree node which contains >>> + the operating points tuples(recommended to be used if multiple >>> + devices are in the same clock domain and hence share OPPs, as it >>> + avoids replication of OPPs) >>> + >>> + operating-points and operating-points-phandle are mutually exclusive, only >>> + one of them can be present in any device node. >>> + >>> Examples: >>> >>> -cpu@0 { >>> - compatible = "arm,cortex-a9"; >>> - reg = <0>; >>> - next-level-cache = <&L2>; >>> - operating-points = < >>> - /* kHz uV */ >>> - 792000 1100000 >>> - 396000 950000 >>> - 198000 850000 >>> - >; >>> -}; >>> +1. A uniprocessor system (phandle not required) >>> + >>> + cpu0: cpu@0 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <0>; >>> + operating-points = < >>> + /* kHz uV */ >>> + 792000 1100000 >>> + 396000 950000 >>> + 198000 850000 >>> + >; >>> + }; >>> + >>> +2a. Consider a SMP system with 4 CPUs in the same clock domain(no phandle) >>> + Some existing DTs describe homogenous SMP systems by only listing the >>> + OPPs in the cpu@0 node. For compatiblity with existing DTs, an >>> + operating system may handle this case specially. >>> + >>> + cpu0: cpu@0 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <0>; >>> + operating-points = < >>> + /* kHz uV */ >>> + 792000 1100000 >>> + 396000 950000 >>> + 198000 850000 >>> + >; >>> + }; >>> + >>> + cpu1: cpu@1 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <1>; >>> + }; >>> + >>> + cpu2: cpu@2 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <2>; >>> + }; >>> + >>> + cpu3: cpu@3 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <3>; >>> + }; >>> + >>> +2b. Consider a SMP system with 4 CPUs in the same clock domain(with phandle) >>> + If more than one device of same type share the same OPPs, for example >>> + all the CPUs on a SoC or in a single cluster on a SoC, then we can avoid >>> + replicating the OPPs in all the nodes. We can specify the phandle of >>> + the node which contains the OPP tuples instead. >>> + >>> + cpu0: cpu@0 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <0>; >>> + operating-points-phandle = <&cpu_opp>; >>> + }; >>> + >>> + cpu1: cpu@1 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <1>; >>> + operating-points-phandle = <&cpu_opp>; >>> + }; >>> + >>> + cpu2: cpu@2 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <2>; >>> + operating-points-phandle = <&cpu_opp>; >>> + }; >>> + >>> + cpu3: cpu@3 { >>> + compatible = "arm,cortex-a9"; >>> + reg = <3>; >>> + operating-points-phandle = <&cpu_opp>; >>> + }; >>> + >>> + opps-table { >>> + cpu_opp: cpu_opp { >>> + operating-points = < >>> + /* kHz uV */ >>> + 792000 1100000 >>> + 396000 950000 >>> + 198000 850000 >>> + >; >>> + }; >>> + ... /* other device OPP nodes */ >> >> But this is a subnode of /cpus. IMO, OPPs should be located near what >> they control. >> > No, the idea was to group all the shared OPPs in a container node like clocks or > pinmux. So opps-table in above example need not be subnode of /cpus. > >> >>> + } >>> + >>> +4. Consider an AMP(asymmetric multi-processor) sytem with 2 clusters of >>> + CPUs. Each cluster has 2 CPUs and all the CPUs within the cluster share >>> + the clock domain. >>> + >>> + cpu0: cpu@0 { >>> + compatible = "arm,cortex-a15"; >>> + reg = <0>; >>> + operating-points-phandle = <&cluster0_opp>; >>> + }; >>> + >>> + cpu1: cpu@1 { >>> + compatible = "arm,cortex-a15"; >>> + reg = <1>; >>> + operating-points-phandle = <&cluster0_opp>; >>> + }; >>> + >>> + cpu2: cpu@100 { >>> + compatible = "arm,cortex-a7"; >>> + reg = <100>; >>> + operating-points-phandle = <&cluster1_opp>; >>> + }; >>> + >>> + cpu3: cpu@101 { >>> + compatible = "arm,cortex-a7"; >>> + reg = <101>; >>> + operating-points-phandle = <&cluster1_opp>; >>> + }; >>> + >>> + opps-table { >>> + cluster0_opp: cluster0_opp { >> >> Why not use the cpu topology? Then the operating point can apply to >> cores based on the position in the topology. You don't even need a >> phandle in that case. You can look for OPPs in either a cpu node or in >> the topology. >> > Agreed but few thoughts behind this binding: > > 1. OPPs are not just cpu specific: > How do we share OPPs for 2 devices in the same clock domain ? > Also moving the OPP into cpu-topo makes parsing specific to cpu. > Currently the OPP library fetches the of_node from the device struct > which is applicable to any devices. > > 2. Should cpu topology(i.e. cpu-map) just contain the topology info ? and > phandles to these nodes should be used to setup any affinity ? > > 3. As part of RFC[1][2], it was also discussed that on some SoCs we need > multiple OPP profiles/options which it provides but only one of them can > be used based on the board design. phandle to OPP will also help resolve > that issue. > > Let me know your thoughts. > (pinging to get this discussion alive again) Is this extension to the binding to support shared OPPs acceptable ? If not, any ideas to progress on this is helpful. Regards, Sudeep > > [1] http://www.spinics.net/lists/cpufreq/msg06556.html > [2] http://www.spinics.net/lists/cpufreq/msg06685.html > > -- > 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 > -- 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