devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2015-06-03  4:40 UTC|newest]

Thread overview: 7+ 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 ` [PATCH V6 1/3] OPP: Add new bindings to address shortcomings of existing bindings Viresh Kumar
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-03  4:40     ` Viresh Kumar [this message]
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 ` [PATCH V6 3/3] OPP: Add binding for 'opp-suspend' 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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).