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

Groups > linux.kernel > #1631139 > unrolled thread

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

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 V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Rajendra Nayak <rnayak@codeaurora.org> - 2017-04-26 06:40 +0200
    Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Mark Brown <broonie@kernel.org> - 2017-04-26 16:00 +0200
      Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Sudeep Holla <sudeep.holla@arm.com> - 2017-04-27 11:50 +0200
        Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Rajendra Nayak <rnayak@codeaurora.org> - 2017-04-27 13:00 +0200
          Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Viresh Kumar <viresh.kumar@linaro.org> - 2017-04-28 07:10 +0200
            Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Sudeep Holla <sudeep.holla@arm.com> - 2017-04-28 11:50 +0200
              Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Viresh Kumar <viresh.kumar@linaro.org> - 2017-04-28 13:20 +0200
        Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Mark Brown <broonie@kernel.org> - 2017-04-30 14:50 +0200
          Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for  power-domains Sudeep Holla <sudeep.holla@arm.com> - 2017-05-03 13:30 +0200

#1631139 — Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

> On 17/04/17 06:27, Viresh Kumar wrote:
>> On 13-04-17, 14:42, Sudeep Holla wrote:
>>> What I was referring is about power domain provider with multiple power
>>> domains(simply #power-domain-cells=<1> case as explained in the
>>> power-domain specification.
>>
>> I am not sure if we should be looking to target such a situation for now, as
>> that would be like this:
>>
>> Device controlled by Domain A. Domain A itself is controlled by Domain B and
>> Domain C.
>>
> 
> No, may be I was not so clear. I am just referring a power controller
> that provides say 3 different power domains and are indexed 0 - 2.
> The consumer just passes the index along with the phandle for the power
> domain info.
> 
>> Though we will end up converting the domain-performance-state property to an
>> array if that is required in near future.
>>
> 
> OK, better to document that so that we know how to extend it. We have
> #power-domain-cells=<1> on Juno with SCPI.
> 
>>> Yes. To simplify what not we just have power-domain for a device and
>>> change state of that domain to change the performance of that device.
>>
>> Consider this case to understand what I have in Mind.
>>
>> The power domain have its states as A, B, C, D. There can be multiple devices
>> regulated by that domain and one of the devices have its power states as: A1,
>> A2, A3, B1, B2, B3, C1, C2, C3, D1, D2, D3 and all these states have different
>> frequency/voltages.
>>
>> IOW, the devices can have regulators as well and may want to fine tune within
>> the domain performance-state.
>>
> 
> Understood. I would incline towards reusing regulators we that's what is
> changed behind the scene. Calling this operating performance point
> is misleading and doesn't align well with existing specs/features.

[]...
 
>>> If we are looking this power-domains with performance as just some
>>> *advanced regulators*, I don't like the complexity added.

+ Mark

I don;t see any public discussions on why we ruled out using regulators to
support this but maybe there were some offline discussions on this.

Mark, this is a long thread, so just summarizing here to give you the context.

At qualcomm, we have an external M3 core (running its own firmware) which controls
a few voltage rails (including AVS on those). The devices vote for the voltage levels
(or performance levels) they need by passing an integer value to the M3 (not actual
voltage values). Since that didn't fit well with the existing regulator apis it was
proposed we look at modeling these as powerdomain performance levels (and reuse genpd
framework) which is what this series from Viresh is about.

Since the discussion now is moving towards 'why not use regulator framework for this
instead of adding all the complexity with powerdomain performance levels since
these are regulators underneath', I looped you in so you can provide some feedback
on can these really be modeled as some *advanced regulators* with some apis to set some
regulator performance levels (instead of voltage levels).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[toc] | [next] | [standalone]

#1631465

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

On Wed, Apr 26, 2017 at 10:02:39AM +0530, Rajendra Nayak wrote:
> > On 17/04/17 06:27, Viresh Kumar wrote:

> >>> If we are looking this power-domains with performance as just some
> >>> *advanced regulators*, I don't like the complexity added.

> + Mark

> I don;t see any public discussions on why we ruled out using regulators to
> support this but maybe there were some offline discussions on this.

> Mark, this is a long thread, so just summarizing here to give you the context.

> At qualcomm, we have an external M3 core (running its own firmware) which controls
> a few voltage rails (including AVS on those). The devices vote for the voltage levels
> (or performance levels) they need by passing an integer value to the M3 (not actual
> voltage values). Since that didn't fit well with the existing regulator apis it was

As I'm getting fed up of saying: if the values you are setting are not
voltages and do not behave like voltages then the hardware should not be
represented as a voltage regulator since if they are represented as
voltage regulators things will expect to be able to control them as
voltage regulators.  This hardware is quite clearly providing OPPs
directly, I would expect this to be handled in the OPP code somehow.

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

#1631995

On 26/04/17 14:55, Mark Brown wrote:
> On Wed, Apr 26, 2017 at 10:02:39AM +0530, Rajendra Nayak wrote:
>>> On 17/04/17 06:27, Viresh Kumar wrote:
> 
>>>>> If we are looking this power-domains with performance as just some
>>>>> *advanced regulators*, I don't like the complexity added.
> 
>> + Mark
> 
>> I don;t see any public discussions on why we ruled out using regulators to
>> support this but maybe there were some offline discussions on this.
> 
>> Mark, this is a long thread, so just summarizing here to give you the context.
> 
>> At qualcomm, we have an external M3 core (running its own firmware) which controls
>> a few voltage rails (including AVS on those). The devices vote for the voltage levels

Thanks for explicitly mentioning this, but ...

>> (or performance levels) they need by passing an integer value to the M3 (not actual

you contradict here, is it just voltage or performance(i.e. frequency)
or both ? We need clarity there to choose the right representation.

>> voltage values). Since that didn't fit well with the existing regulator apis it was
> 
> As I'm getting fed up of saying: if the values you are setting are not
> voltages and do not behave like voltages then the hardware should not be
> represented as a voltage regulator since if they are represented as
> voltage regulators things will expect to be able to control them as
> voltage regulators.  This hardware is quite clearly providing OPPs
> directly, I would expect this to be handled in the OPP code somehow.

I agree with you that we need to be absolutely sure on what it actually
represents.

But as more and more platform are pushing such power controls to
dedicated M3 or similar processors, we need abstraction. Though we are
controlling hardware, we do so indirectly. Since there were discussions
around device tree representing hardware vs platform, I tend to think,
we are moving towards platform(something similar to ACPI).

-- 
Regards,
Sudeep

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

#1632026

On 04/27/2017 03:12 PM, Sudeep Holla wrote:
[]..

>>
>>> At qualcomm, we have an external M3 core (running its own firmware) which controls
>>> a few voltage rails (including AVS on those). The devices vote for the voltage levels
> 
> Thanks for explicitly mentioning this, but ...
> 
>>> (or performance levels) they need by passing an integer value to the M3 (not actual
> 
> you contradict here, is it just voltage or performance(i.e. frequency)
> or both ? We need clarity there to choose the right representation.

Its just voltage.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

#1632526

On 27-04-17, 16:20, Rajendra Nayak wrote:
> 
> On 04/27/2017 03:12 PM, Sudeep Holla wrote:
> []..
> 
> >>
> >>> At qualcomm, we have an external M3 core (running its own firmware) which controls
> >>> a few voltage rails (including AVS on those). The devices vote for the voltage levels
> > 
> > Thanks for explicitly mentioning this, but ...
> > 
> >>> (or performance levels) they need by passing an integer value to the M3 (not actual
> > 
> > you contradict here, is it just voltage or performance(i.e. frequency)
> > or both ? We need clarity there to choose the right representation.
> 
> Its just voltage.

Right. Its just voltage in this case, but we can't speak of future
platforms here and we have to consider this thing as an operating
performance point only. I still think that this thread is moving in
the right direction, specially after V6 which looks much better.

If we have anything strong against the way V6 is trying to solve it, I
want to talk about it right now and get inputs from all the parties
involved. Scrapping all this work is fine, but I would like to do it
ASAP in that case :)

-- 
viresh

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

#1632748

On 28/04/17 06:00, Viresh Kumar wrote:
> On 27-04-17, 16:20, Rajendra Nayak wrote:
>>
>> On 04/27/2017 03:12 PM, Sudeep Holla wrote:
>> []..
>>
>>>>
>>>>> At qualcomm, we have an external M3 core (running its own firmware) which controls
>>>>> a few voltage rails (including AVS on those). The devices vote for the voltage levels
>>>
>>> Thanks for explicitly mentioning this, but ...
>>>
>>>>> (or performance levels) they need by passing an integer value to the M3 (not actual
>>>
>>> you contradict here, is it just voltage or performance(i.e. frequency)
>>> or both ? We need clarity there to choose the right representation.
>>
>> Its just voltage.
> 
> Right. Its just voltage in this case, but we can't speak of future
> platforms here and we have to consider this thing as an operating
> performance point only. I still think that this thread is moving in
> the right direction, specially after V6 which looks much better.
> 

Just thinking out loud, I can see platforms with have OPPs can move to
this binding in future eliminating the need to specify the clock and
regulators explicitly. So, I am not saying I against this idea, but I
see it might complicate the above case in terms of the precedence that
we consider in DT from backward compatibility.

E.g. if you now use this for just regulators, then I assume you continue
to use clocks. However, that makes it difficult for platforms
implementing *real* OPPs to reuse this binding as they may expect to
skip clock altogether.

Also we may need OPPs(both volt/freq), voltage only and clock only
bindings though all 3 are driven by the firmware and all are at abstract
levels. I am trying to broaden the scope now without having to churn
this binding again in near future.

So I don't totally agree that voltage regulators much have *real*
voltages and not abstract scale. Yes the correct bindings might have
such restrictions but can't we extend it ?

Anyways these are just my opinion.

> If we have anything strong against the way V6 is trying to solve it, I
> want to talk about it right now and get inputs from all the parties
> involved. Scrapping all this work is fine, but I would like to do it
> ASAP in that case :)
> 

As I said I am not against it, but I see it useful for a different
use-case, just not the one you are trying to solve here ;)

-- 
Regards,
Sudeep

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

#1632804

On 28-04-17, 10:44, Sudeep Holla wrote:
> Just thinking out loud, I can see platforms with have OPPs can move to
> this binding in future eliminating the need to specify the clock and
> regulators explicitly. So, I am not saying I against this idea, but I
> see it might complicate the above case in terms of the precedence that
> we consider in DT from backward compatibility.
> 
> E.g. if you now use this for just regulators, then I assume you continue
> to use clocks. However, that makes it difficult for platforms
> implementing *real* OPPs to reuse this binding as they may expect to
> skip clock altogether.
> 
> Also we may need OPPs(both volt/freq), voltage only and clock only
> bindings though all 3 are driven by the firmware and all are at abstract
> levels. I am trying to broaden the scope now without having to churn
> this binding again in near future.
> 
> So I don't totally agree that voltage regulators much have *real*
> voltages and not abstract scale. Yes the correct bindings might have
> such restrictions but can't we extend it ?
> 
> Anyways these are just my opinion.

Everyone's opinion has equal merit here :)

I believe that some of your hesitation came from the point that I have
made opp-hz optional. That isn't the case anymore with V6.

Can we please take the discussion to that thread now and see if you
can find similar problems there as well.

Thanks a lot.

-- 
viresh

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

#1633430

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

On Thu, Apr 27, 2017 at 10:42:49AM +0100, Sudeep Holla wrote:
> On 26/04/17 14:55, Mark Brown wrote:

> > As I'm getting fed up of saying: if the values you are setting are not
> > voltages and do not behave like voltages then the hardware should not be
> > represented as a voltage regulator since if they are represented as
> > voltage regulators things will expect to be able to control them as
> > voltage regulators.  This hardware is quite clearly providing OPPs
> > directly, I would expect this to be handled in the OPP code somehow.

> I agree with you that we need to be absolutely sure on what it actually
> represents.

> But as more and more platform are pushing such power controls to
> dedicated M3 or similar processors, we need abstraction. Though we are
> controlling hardware, we do so indirectly. Since there were discussions
> around device tree representing hardware vs platform, I tend to think,
> we are moving towards platform(something similar to ACPI).

I don't think there's a meaningful hardware/platform distinction here -
in terms of what DT is describing the platform bit is just what the
hardware (the microcontrollers) happen to do, DT doesn't much care about
that though.

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

#1634892

On 30/04/17 13:49, Mark Brown wrote:
> On Thu, Apr 27, 2017 at 10:42:49AM +0100, Sudeep Holla wrote:
>> On 26/04/17 14:55, Mark Brown wrote:
> 
>>> As I'm getting fed up of saying: if the values you are setting are not
>>> voltages and do not behave like voltages then the hardware should not be
>>> represented as a voltage regulator since if they are represented as
>>> voltage regulators things will expect to be able to control them as
>>> voltage regulators.  This hardware is quite clearly providing OPPs
>>> directly, I would expect this to be handled in the OPP code somehow.
> 
>> I agree with you that we need to be absolutely sure on what it actually
>> represents.
> 
>> But as more and more platform are pushing such power controls to
>> dedicated M3 or similar processors, we need abstraction. Though we are
>> controlling hardware, we do so indirectly. Since there were discussions
>> around device tree representing hardware vs platform, I tend to think,
>> we are moving towards platform(something similar to ACPI).
> 
> I don't think there's a meaningful hardware/platform distinction here -
> in terms of what DT is describing the platform bit is just what the
> hardware (the microcontrollers) happen to do, 
> 

Yes agreed. It's similar to PSCI or any other platform firmware IMO.

The question is how do we deal with such controls that needs to be done
via the firmware ? We generally plug-in to the existing framework in
Linux using the existing bindings. Most of the time, much simpler
bindings than the one that present complete hardware description.

> DT doesn't much care about that though.

No sure about that, may be doesn't care about the internals, but we need
to care about interface, no ?

-- 
Regards,
Sudeep

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web