From: Viresh Kumar <viresh.kumar@linaro.org> To: Stephen Boyd <sboyd@codeaurora.org> Cc: Rafael Wysocki <rjw@rjwysocki.net>, rob.herring@linaro.org, linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, arnd.bergmann@linaro.org, nm@ti.com, broonie@kernel.org, mike.turquette@linaro.org, grant.likely@linaro.org, olof@lixom.net, Sudeep.Holla@arm.com, devicetree@vger.kernel.org, viswanath.puttagunta@linaro.org, l.stach@pengutronix.de, thomas.petazzoni@free-electrons.com, linux-arm-kernel@lists.infradead.org, ta.omasab@gmail.com, kesavan.abhilash@gmail.com, khilman@linaro.org, santosh.shilimkar@oracle.com Subject: Re: [PATCH V6 1/3] OPP: Add new bindings to address shortcomings of existing bindings Date: Wed, 3 Jun 2015 10:10:06 +0530 [thread overview] Message-ID: <20150603044006.GB4527@linux> (raw) In-Reply-To: <20150602183120.GB24349@codeaurora.org> On 02-06-15, 11:31, Stephen Boyd wrote: > Also, is there already code written to handle these new > bindings in the OPP library? If not, it would be good to write > some to flush out any problems that may be lurking in actual > implementation. I had written code earlier for V2 or something, but then we went back to the improvements in bindings and I stopped writing code for it. http://marc.info/?i=cover.1423642246.git.viresh.kumar%40linaro.org But that just requires to be updated a bit now. Will do that once I am sure the bindings are all good now, with all Acks and RBYs. > > + > > +Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. > > + > > +/ { > > + cpus { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + cpu@0 { > > + compatible = "arm,cortex-a9"; > > + reg = <0>; > > + next-level-cache = <&L2>; > > + clocks = <&clk_controller 0>; > > + clock-names = "cpu"; > > + opp-supply = <&cpu_supply0>; > > opp-supply isn't mentioned anywhere. Is that intentional? Is it This should have been 'cpu-supply' instead. > supposed to be cpu-supply still? Yes. > It isn't clear to me from the > previous discussion where this all ended up, but I'm not sure how > the in-kernel API is going to match up regulators with OPPs. I > mean, how are we going to ask the OPP library what the > min/max/target voltage is at a particular frequency when we have > multiple regulators? Is that some string based interface? > > dev_pm_opp_get_voltage(name, &target, &min, &max); > > Or a regulator pointer interface? > > dev_pm_opp_get_voltage(regulator, &target, &min, &max); Probably this. > Or something else? Does this mean the OPP library is going to get > the CPU device to request the opp-supply from the CPU node? Maybe yes. That will clarify more with more code in place. > Furthermore, why don't we care about opp-clocks? Are clocks > somehow special? There shouldn't be opp-supply in the first place and so no need of opp-clocks as well. -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V6 1/3] OPP: Add new bindings to address shortcomings of existing bindings Date: Wed, 3 Jun 2015 10:10:06 +0530 [thread overview] Message-ID: <20150603044006.GB4527@linux> (raw) In-Reply-To: <20150602183120.GB24349@codeaurora.org> On 02-06-15, 11:31, Stephen Boyd wrote: > Also, is there already code written to handle these new > bindings in the OPP library? If not, it would be good to write > some to flush out any problems that may be lurking in actual > implementation. I had written code earlier for V2 or something, but then we went back to the improvements in bindings and I stopped writing code for it. http://marc.info/?i=cover.1423642246.git.viresh.kumar%40linaro.org But that just requires to be updated a bit now. Will do that once I am sure the bindings are all good now, with all Acks and RBYs. > > + > > +Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. > > + > > +/ { > > + cpus { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + cpu at 0 { > > + compatible = "arm,cortex-a9"; > > + reg = <0>; > > + next-level-cache = <&L2>; > > + clocks = <&clk_controller 0>; > > + clock-names = "cpu"; > > + opp-supply = <&cpu_supply0>; > > opp-supply isn't mentioned anywhere. Is that intentional? Is it This should have been 'cpu-supply' instead. > supposed to be cpu-supply still? Yes. > It isn't clear to me from the > previous discussion where this all ended up, but I'm not sure how > the in-kernel API is going to match up regulators with OPPs. I > mean, how are we going to ask the OPP library what the > min/max/target voltage is at a particular frequency when we have > multiple regulators? Is that some string based interface? > > dev_pm_opp_get_voltage(name, &target, &min, &max); > > Or a regulator pointer interface? > > dev_pm_opp_get_voltage(regulator, &target, &min, &max); Probably this. > Or something else? Does this mean the OPP library is going to get > the CPU device to request the opp-supply from the CPU node? Maybe yes. That will clarify more with more code in place. > Furthermore, why don't we care about opp-clocks? Are clocks > somehow special? There shouldn't be opp-supply in the first place and so no need of opp-clocks as well. -- viresh
next prev parent reply other threads:[~2015-06-03 4:40 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-28 7:29 [PATCH V6 0/3] OPP: Introduce OPP (V2) bindings Viresh Kumar 2015-05-28 7:29 ` Viresh Kumar 2015-05-28 7:29 ` [PATCH V6 1/3] OPP: Add new bindings to address shortcomings of existing bindings Viresh Kumar 2015-05-28 7:29 ` Viresh Kumar 2015-06-02 18:31 ` Stephen Boyd 2015-06-02 18:31 ` Stephen Boyd [not found] ` <20150602183120.GB24349-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-06-02 19:14 ` Mark Brown 2015-06-02 19:14 ` Mark Brown 2015-06-03 4:40 ` Viresh Kumar [this message] 2015-06-03 4:40 ` Viresh Kumar 2015-05-28 7:29 ` [PATCH V6 2/3] OPP: Allow multiple OPP tables to be passed via DT Viresh Kumar 2015-05-28 7:29 ` Viresh Kumar 2015-05-28 7:29 ` [PATCH V6 3/3] OPP: Add binding for 'opp-suspend' Viresh Kumar 2015-05-28 7:29 ` 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=20150603044006.GB4527@linux \ --to=viresh.kumar@linaro.org \ --cc=Sudeep.Holla@arm.com \ --cc=arnd.bergmann@linaro.org \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=grant.likely@linaro.org \ --cc=kesavan.abhilash@gmail.com \ --cc=khilman@linaro.org \ --cc=l.stach@pengutronix.de \ --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@oracle.com \ --cc=sboyd@codeaurora.org \ --cc=ta.omasab@gmail.com \ --cc=thomas.petazzoni@free-electrons.com \ --cc=viswanath.puttagunta@linaro.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.