From: Viresh Kumar <viresh.kumar@linaro.org> To: Olof Johansson <olof@lixom.net> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>, Mike Turquette <mike.turquette@linaro.org>, Rob Herring <rob.herring@linaro.org>, Grant Likely <grant.likely@linaro.org>, "linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>, Nishanth Menon <nm@ti.com>, Sudeep Holla <Sudeep.Holla@arm.com>, Stephen Boyd <sboyd@codeaurora.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Santosh Shilimkar <santosh.shilimkar@ti.com>, Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>, Arvind Chauhan <arvind.chauhan@arm.com>, Arnd Bergmann <arnd.bergmann@linaro.org> Subject: Re: [RFC] cpufreq: Add bindings for CPU clock sharing topology Date: Sat, 19 Jul 2014 20:16:36 +0530 [thread overview] Message-ID: <CAKohpokLqrydV3b=innvOWrW9ijXtZwPKdT5Ew65cjMxsY2Mvw@mail.gmail.com> (raw) In-Reply-To: <CAOesGMhuNzVtUkaUjF+JjNgHcgf08WiM0DG-kzwtcyUxkK_zow@mail.gmail.com> On 19 July 2014 03:22, Olof Johansson <olof@lixom.net> wrote: > What is the current API that is being broken, in your opinion? So, currently the nodes doesn't have any such property. And drivers consider all of them as sharing clocks, for eg: cpufreq-cpu0. Now, if we use those older DT's after the new changes, drivers would consider CPUs as having separate clocks. And that would be opposite of what currently happens. Not sure if this counts as broken. >> But if that isn't the case, the bindings are very simple & clear to handle. >> Diff for new bindings: > > It's somewhat confusing to see a diff to the patch instead of a new > version. It seems to remove the cpu 0 entry now? Not really, I removed an unwanted example. This is how it looks: * Generic CPUFreq clock bindings Clock lines may or may not be shared among different CPUs on a platform. Possible configurations: 1.) All CPUs share a single clock line 2.) All CPUs have independent clock lines 3.) CPUs within a group/cluster share clock line but each group/cluster have a separate line for itself Optional Properties: - clock-master: Contains phandle of the master cpu controlling clocks. Ideally there is nothing like a "master" CPU as any CPU can play with DVFS settings. But we have to choose one cpu out of a group, so that others can point to it. If there is no "clock-master" property for a cpu node, it is considered as master. It may or may not have other slave CPUs pointing towards it. Examples: 1.) All CPUs share a single clock line cpus { #address-cells = <1>; #size-cells = <0>; cpu0: cpu@0 { compatible = "arm,cortex-a15"; reg = <0>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu1: cpu@1 { compatible = "arm,cortex-a15"; reg = <1>; next-level-cache = <&L2>; clock-master = <&cpu0>; }; }; 2.) All CPUs have independent clock lines cpus { #address-cells = <1>; #size-cells = <0>; cpu0: cpu@0 { compatible = "arm,cortex-a15"; reg = <0>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu1: cpu@1 { compatible = "arm,cortex-a15"; reg = <1>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; }; 3.) CPUs within a group/cluster share single clock line but each group/cluster have a separate line for itself cpus { #address-cells = <1>; #size-cells = <0>; cpu0: cpu@0 { compatible = "arm,cortex-a15"; reg = <0>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu1: cpu@1 { compatible = "arm,cortex-a15"; reg = <1>; next-level-cache = <&L2>; clock-master = <&cpu0>; }; cpu2: cpu@100 { compatible = "arm,cortex-a7"; reg = <100>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 950000 396000 750000 198000 450000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu3: cpu@101 { compatible = "arm,cortex-a7"; reg = <101>; next-level-cache = <&L2>; clock-master = <&cpu2>; }; };
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar) To: linux-arm-kernel@lists.infradead.org Subject: [RFC] cpufreq: Add bindings for CPU clock sharing topology Date: Sat, 19 Jul 2014 20:16:36 +0530 [thread overview] Message-ID: <CAKohpokLqrydV3b=innvOWrW9ijXtZwPKdT5Ew65cjMxsY2Mvw@mail.gmail.com> (raw) In-Reply-To: <CAOesGMhuNzVtUkaUjF+JjNgHcgf08WiM0DG-kzwtcyUxkK_zow@mail.gmail.com> On 19 July 2014 03:22, Olof Johansson <olof@lixom.net> wrote: > What is the current API that is being broken, in your opinion? So, currently the nodes doesn't have any such property. And drivers consider all of them as sharing clocks, for eg: cpufreq-cpu0. Now, if we use those older DT's after the new changes, drivers would consider CPUs as having separate clocks. And that would be opposite of what currently happens. Not sure if this counts as broken. >> But if that isn't the case, the bindings are very simple & clear to handle. >> Diff for new bindings: > > It's somewhat confusing to see a diff to the patch instead of a new > version. It seems to remove the cpu 0 entry now? Not really, I removed an unwanted example. This is how it looks: * Generic CPUFreq clock bindings Clock lines may or may not be shared among different CPUs on a platform. Possible configurations: 1.) All CPUs share a single clock line 2.) All CPUs have independent clock lines 3.) CPUs within a group/cluster share clock line but each group/cluster have a separate line for itself Optional Properties: - clock-master: Contains phandle of the master cpu controlling clocks. Ideally there is nothing like a "master" CPU as any CPU can play with DVFS settings. But we have to choose one cpu out of a group, so that others can point to it. If there is no "clock-master" property for a cpu node, it is considered as master. It may or may not have other slave CPUs pointing towards it. Examples: 1.) All CPUs share a single clock line cpus { #address-cells = <1>; #size-cells = <0>; cpu0: cpu at 0 { compatible = "arm,cortex-a15"; reg = <0>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu1: cpu at 1 { compatible = "arm,cortex-a15"; reg = <1>; next-level-cache = <&L2>; clock-master = <&cpu0>; }; }; 2.) All CPUs have independent clock lines cpus { #address-cells = <1>; #size-cells = <0>; cpu0: cpu at 0 { compatible = "arm,cortex-a15"; reg = <0>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu1: cpu at 1 { compatible = "arm,cortex-a15"; reg = <1>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; }; 3.) CPUs within a group/cluster share single clock line but each group/cluster have a separate line for itself cpus { #address-cells = <1>; #size-cells = <0>; cpu0: cpu at 0 { compatible = "arm,cortex-a15"; reg = <0>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 1100000 396000 950000 198000 850000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu1: cpu at 1 { compatible = "arm,cortex-a15"; reg = <1>; next-level-cache = <&L2>; clock-master = <&cpu0>; }; cpu2: cpu at 100 { compatible = "arm,cortex-a7"; reg = <100>; next-level-cache = <&L2>; operating-points = < /* kHz uV */ 792000 950000 396000 750000 198000 450000 >; clock-latency = <61036>; /* two CLK32 periods */ }; cpu3: cpu at 101 { compatible = "arm,cortex-a7"; reg = <101>; next-level-cache = <&L2>; clock-master = <&cpu2>; }; };
next prev parent reply other threads:[~2014-07-19 14:46 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-18 5:35 [RFC] cpufreq: Add bindings for CPU clock sharing topology Viresh Kumar 2014-07-18 5:35 ` Viresh Kumar 2014-07-18 6:17 ` Olof Johansson 2014-07-18 6:17 ` Olof Johansson 2014-07-18 6:40 ` Viresh Kumar 2014-07-18 6:40 ` Viresh Kumar 2014-07-18 21:52 ` Olof Johansson 2014-07-18 21:52 ` Olof Johansson 2014-07-19 14:46 ` Viresh Kumar [this message] 2014-07-19 14:46 ` Viresh Kumar 2014-07-19 15:24 ` Santosh Shilimkar 2014-07-19 15:24 ` Santosh Shilimkar 2014-07-20 12:07 ` Viresh Kumar 2014-07-20 12:07 ` Viresh Kumar 2014-07-21 13:40 ` Santosh Shilimkar 2014-07-21 13:40 ` Santosh Shilimkar 2014-07-24 0:33 ` Mike Turquette 2014-07-24 0:33 ` Mike Turquette 2014-07-24 2:24 ` Rob Herring 2014-07-24 2:24 ` Rob Herring 2014-07-24 10:39 ` Viresh Kumar 2014-07-24 10:39 ` Viresh Kumar 2014-07-25 20:02 ` Mike Turquette 2014-07-25 20:02 ` Mike Turquette 2014-08-25 7:05 ` Viresh Kumar 2014-08-25 7:05 ` Viresh Kumar 2014-07-21 17:00 ` Rob Herring 2014-07-21 17:00 ` Rob Herring 2014-07-23 4:55 ` Viresh Kumar 2014-07-23 4:55 ` Viresh Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKohpokLqrydV3b=innvOWrW9ijXtZwPKdT5Ew65cjMxsY2Mvw@mail.gmail.com' \ --to=viresh.kumar@linaro.org \ --cc=Lorenzo.Pieralisi@arm.com \ --cc=Sudeep.Holla@arm.com \ --cc=arnd.bergmann@linaro.org \ --cc=arvind.chauhan@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=grant.likely@linaro.org \ --cc=linaro-kernel@lists.linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=mike.turquette@linaro.org \ --cc=nm@ti.com \ --cc=olof@lixom.net \ --cc=rjw@rjwysocki.net \ --cc=rob.herring@linaro.org \ --cc=santosh.shilimkar@ti.com \ --cc=sboyd@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.