On Wed, May 03, 2017 at 12:21:54PM +0100, Sudeep Holla wrote:
> On 30/04/17 13:49, Mark Brown wrote:
> > 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 ?
Well, we need to at least describe what's th
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
>
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
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
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).
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 level
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 ...
>
>>>
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.
>
>> + Mar
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
> 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 lo
Viresh Kumar writes:
> On 20-04-17, 10:43, Sudeep Holla wrote:
>> Just that the term performance is closely related to frequency, it needs
>> to be explicit on what *exactly* it means. As it stands now,
>> it can be used for OPP as I explain which controls both but as you
>> clarify that's not wh
On 20-04-17, 10:43, Sudeep Holla wrote:
> Just that the term performance is closely related to frequency, it needs
> to be explicit on what *exactly* it means. As it stands now,
> it can be used for OPP as I explain which controls both but as you
> clarify that's not what it's designed for.
We are
On 20/04/17 09:23, Ulf Hansson wrote:
> Viresh, Sudeep,
>
> Sorry for jumping in late.
>
> [...]
>
>>> On the contrary(playing devil's advocate here), we can treat all
>>> existing regulators alone as OPP then if you strip the voltages and
>>> treat it as abstract number.
>>
>> But then we are
On 20/04/17 06:25, Viresh Kumar wrote:
> On 19-04-17, 14:58, Sudeep Holla wrote:
>> On 19/04/17 12:47, Viresh Kumar wrote:
>>> On 18-04-17, 17:01, Sudeep Holla wrote:
[...]
>>
>> Yes, I completely agree. I am not saying the direction is wrong. I
>> am saying it's confusing and binding needs to
On 20-04-17, 10:23, Ulf Hansson wrote:
> Viresh, Sudeep,
>
> Sorry for jumping in late.
>
> [...]
>
> >> On the contrary(playing devil's advocate here), we can treat all
> >> existing regulators alone as OPP then if you strip the voltages and
> >> treat it as abstract number.
> >
> > But then we
Viresh, Sudeep,
Sorry for jumping in late.
[...]
>> On the contrary(playing devil's advocate here), we can treat all
>> existing regulators alone as OPP then if you strip the voltages and
>> treat it as abstract number.
>
> But then we are going to have lots of platform specific code which
> wil
On 19-04-17, 14:58, Sudeep Holla wrote:
> On 19/04/17 12:47, Viresh Kumar wrote:
> > On 18-04-17, 17:01, Sudeep Holla wrote:
> >> Understood. I would incline towards reusing regulators we that's what is
> >
> > It can be just a regulator, but it can be anything else as well. That
> > entity may ha
On 19/04/17 12:47, Viresh Kumar wrote:
> On 18-04-17, 17:01, Sudeep Holla wrote:
>> Understood. I would incline towards reusing regulators we that's what is
>
> It can be just a regulator, but it can be anything else as well. That
> entity may have its own clock/volt/current tunables, etc.
>
A
On 18-04-17, 17:01, Sudeep Holla wrote:
> Understood. I would incline towards reusing regulators we that's what is
It can be just a regulator, but it can be anything else as well. That
entity may have its own clock/volt/current tunables, etc.
> changed behind the scene. Calling this operating per
On 18-04-17, 17:03, Sudeep Holla wrote:
> Was it posted externally ? Was there any objections for that approach ?
> IMO that's better approach but if I am late to the party, I would like
> to read through the discussions that happened on it(if any)
Maybe Stephen can tell more about it. AFAIK, ther
On 18-04-17, 17:01, Sudeep Holla wrote:
> 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.
Ahh, I got you now. Will tak
On 17/04/17 06:33, Viresh Kumar wrote:
> On 13-04-17, 14:43, Sudeep Holla wrote:
>> Interesting. My understand of power domain and in particular power
>> domain performance was that it would control both. The abstract number
>> you introduce would hide clocks and regulators.
>>
>> But if the conc
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
On 13-04-17, 14:43, Sudeep Holla wrote:
> Interesting. My understand of power domain and in particular power
> domain performance was that it would control both. The abstract number
> you introduce would hide clocks and regulators.
>
> But if the concept treats it just as yet another regulator, we
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
On 13/04/17 06:50, Viresh Kumar wrote:
> On 12-04-17, 18:05, Sudeep Holla wrote:
>>
>>
>> On 20/03/17 09:32, Viresh Kumar wrote:
[...]
>>
>> Thinking more about this above example, I think you need more
>> explanation. So in the above case you have cpu with clock controller,
>> power-domain and
On 13/04/17 06:37, Viresh Kumar wrote:
> On 12-04-17, 17:49, Sudeep Holla wrote:
>> On 20/03/17 09:32, Viresh Kumar wrote:
>>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt
>>> b/Documentation/devicetree/bindings/opp/opp.txt
>>> index 63725498bd20..d0b95c9e1011 100644
>>> --- a/Docu
On 12-04-17, 18:05, Sudeep Holla wrote:
>
>
> On 20/03/17 09:32, Viresh Kumar wrote:
> [...]
>
> > +
> > +Example 7: domain-Performance-state:
> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require
> > state 2)
> > +
> > +/ {
> > + domain_opp_table: opp_table0 {
> > +
On 12-04-17, 17:49, Sudeep Holla wrote:
> On 20/03/17 09:32, Viresh Kumar wrote:
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt
> > b/Documentation/devicetree/bindings/opp/opp.txt
> > index 63725498bd20..d0b95c9e1011 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
>
On 20/03/17 09:32, Viresh Kumar wrote:
[...]
> +
> +Example 7: domain-Performance-state:
> +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require
> state 2)
> +
> +/ {
> + domain_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> +
On 20/03/17 09:32, Viresh Kumar wrote:
> Power-domains need to express their active states in DT and what's
> better than OPP table for that.
>
> This patch allows power-domains to reuse OPP tables to express their
> active states. The "opp-hz" property isn't a required property anymore
> as pow
Fixing Kevin's email id :(
On 10-04-17, 14:55, Viresh Kumar wrote:
> On 24-03-17, 10:44, Rob Herring wrote:
> > On Mon, Mar 20, 2017 at 03:02:13PM +0530, Viresh Kumar wrote:
> > > Power-domains need to express their active states in DT and what's
> > > better than OPP table for that.
> > >
> > >
On 24-03-17, 10:44, Rob Herring wrote:
> On Mon, Mar 20, 2017 at 03:02:13PM +0530, Viresh Kumar wrote:
> > Power-domains need to express their active states in DT and what's
> > better than OPP table for that.
> >
> > This patch allows power-domains to reuse OPP tables to express their
> > active
On Mon, Mar 20, 2017 at 03:02:13PM +0530, Viresh Kumar wrote:
> Power-domains need to express their active states in DT and what's
> better than OPP table for that.
>
> This patch allows power-domains to reuse OPP tables to express their
> active states. The "opp-hz" property isn't a required prop
Power-domains need to express their active states in DT and what's
better than OPP table for that.
This patch allows power-domains to reuse OPP tables to express their
active states. The "opp-hz" property isn't a required property anymore
as power-domains may not always use them.
Add a new proper
35 matches
Mail list logo
