Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1254237 > unrolled thread

Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding Mark Brown <broonie@kernel.org> - 2015-10-23 01:40 +0200
    Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding Viresh Kumar <viresh.kumar@linaro.org> - 2015-10-27 09:20 +0100
      Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding Mark Brown <broonie@kernel.org> - 2015-10-28 09:20 +0100
        Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding Stephen Boyd <sboyd@codeaurora.org> - 2015-10-30 00:40 +0100

#1254237 — Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding

[Multipart message — attachments visible in raw view] — view raw

On Sat, Oct 17, 2015 at 09:40:55AM +0530, Viresh Kumar wrote:

> Okay here is the problem statement:

> We have two supplies for a device and the device node will have
> something like:

> name1-supply = <&supply1>;
> name2-supply = <&supply2>;

> And the OPP node needs to have voltages for both of them:

> opp-microvolt = <X1 Y1 Z1>, <X2 Y2 Z2>;

> Where XYZ(1) are for supply1 and XYZ(2) are for supply2.

> Now we need to identify the supplies for which the values are present
> here and their order as well. How do we do that?

> The way I am suggesting is to add a property in opp node which will
> keep "name1" and "name2" in it.

When we start doing this we also start having to worry about things like
the sequencing of the updates between the various supplies and end up in
full on power sequencing (or at least baking some sequencing into the DT
which will doubtless need extending at some point).  I'm not sure that's
a place we want to end up just yet, I think it's safer to just have a
little bit of code in the kernel that glues things together in the cases
where this is needed.  

[toc] | [next] | [standalone]

#1256553

On 23-10-15, 01:39, Mark Brown wrote:
> When we start doing this we also start having to worry about things like
> the sequencing of the updates between the various supplies and end up in
> full on power sequencing (or at least baking some sequencing into the DT
> which will doubtless need extending at some point).

Absolutely.

> I'm not sure that's
> a place we want to end up just yet, I think it's safer to just have a
> little bit of code in the kernel that glues things together in the cases
> where this is needed.  

So you are effectively saying that we shouldn't go ahead with multi
regulator support in OPP library, right?

I went ahead with it as it came as a requirement (specially from
Qcom).

To the problem of sequencing, maybe we can just support that for the
simple case, where supplies will be programmed in the order in which
they are present in the property I added in this patch. And not try to
solve problem for the complex cases, if we feel it is getting ugly.

@Stephen ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1257772

[Multipart message — attachments visible in raw view] — view raw

On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote:
> On 23-10-15, 01:39, Mark Brown wrote:

> > I'm not sure that's
> > a place we want to end up just yet, I think it's safer to just have a
> > little bit of code in the kernel that glues things together in the cases
> > where this is needed.  

> So you are effectively saying that we shouldn't go ahead with multi
> regulator support in OPP library, right?

Well, I think things like libraries for getting the data tables out of
DT are fine but I'm not convinced that trying to avoid having any device
specific code at all is sufficiently clear yet - as far as I know we're
mostly looking at a fairly small subset of devices still and with things
like sequencing in the mix it's a bit worrying to me to be putting it
all into an ABI intended to be used with no knowledge of the platform.

[toc] | [prev] | [next] | [standalone]

#1259101

On 10/28, Mark Brown wrote:
> On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote:
> > On 23-10-15, 01:39, Mark Brown wrote:
> 
> > > I'm not sure that's
> > > a place we want to end up just yet, I think it's safer to just have a
> > > little bit of code in the kernel that glues things together in the cases
> > > where this is needed.  
> 
> > So you are effectively saying that we shouldn't go ahead with multi
> > regulator support in OPP library, right?
> 
> Well, I think things like libraries for getting the data tables out of
> DT are fine but I'm not convinced that trying to avoid having any device
> specific code at all is sufficiently clear yet - as far as I know we're
> mostly looking at a fairly small subset of devices still and with things
> like sequencing in the mix it's a bit worrying to me to be putting it
> all into an ABI intended to be used with no knowledge of the platform.

Agreed. Looking at the current oppv2 binding I'm confused how it
even works. It shows cpu-supply = <&phandle1>, <&phandle2>, etc.
which doesn't work with the regulator bindings design. It seems
that Viresh figured that out when implementing support for
multiple regulators, so the binding was changed to put names in
the opp tables and then use that to get regulators in the opp
core. Urgh.

I think I understand the goal here though. The goal is to move
all the clk_get()/regulator_get() and clock and regulator API
interactions into the OPP framework so that we can say "go to OPP
at index 4" from the cpufreq core and the OPP framework takes
care of actually doing the transition. Given that doing such a
transition could be very machine specific, we probably ought to
make the OPP framework flexible enough to let us decide how to do
that.

Perhaps we need to expand on the compatible string in the opp
node to have compatible = "vendor,cool-transition",
"operating-points-v2"? Then we can plug in vendor specific
drivers that handle the frequency/voltage transition and they'll
know that the fourth column in the voltage entry corresponds to
this particular device's foo-supply and in what order to change
voltages. A generic driver could exist for the simple case of one
regulator and one clock that matches on "operating-points-v2".

Or we can avoid doing any clk_get()/regulator_get() stuff inside
the OPP framework, and let OPP consumers tell the OPP framework
about each clock and regulator it wants the framework to manage
on the consumer's behalf. It could even tell the framework which
regulator corresponds to which voltage column and in what order
to change the voltages so that the OPP framework doesn't need to
know these device specific details. Then the consumer can still
say go to OPP level 4 and that all works without introducing some
new DT ABI.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web