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

Groups > linux.kernel > #1213773 > unrolled thread

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

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 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones <lee.jones@linaro.org> - 2015-08-26 14:10 +0200
    Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Viresh Kumar <viresh.kumar@linaro.org> - 2015-09-02 10:10 +0200
      Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Rob Herring <robherring2@gmail.com> - 2015-09-02 21:00 +0200

#1213773 — Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

On Wed, 12 Aug 2015, Viresh Kumar wrote:

> On 11-08-15, 16:17, Lee Jones wrote:
> > This would work if we only had a single variable to contend with, but
> > what I showed you in my previous example is that we have 3 variables
> > to consider; cut (version), pcode and substrate.
> > 
> > Using the two (simple) examples I provided, how would your suggestion
> > look in our case?
> 
> So the solution I gave is for picking the microvolt based on pcode.
> The other two (cut, substrate) aren't about picking microvolt, but if
> the OPP is available or not. Right?

'pcode', 'cut' and 'substrate' all determine whether a given set of
OPPs an be used on the running platform.  I do not believe that you
can differentiate between them. 

> If these terms are generic enough, then we can add something similar
> to what you have added..

If it makes it easier, you can treat them as version numbers 2.2.1
<pcode.cut.substrate>, but I don't see how this can help.  Obviously
this becomes more difficult when you add wild cards to the OPPs, where
a particular OPP would be suitable for all cuts for example.

If you still think you can come up with a generic method to lay out
CPUFreq OPP nodes that will satisfy all vendors and not be a mass of
10's of separate nodes, then great.  Again, I'm struggling to see how
that might be possible.

What I believe we shouldn't do, is have this blocked forever for the
sake of adding a couple of vendor properties however.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] | [next] | [standalone]

#1217400

On 26-08-15, 13:06, Lee Jones wrote:
> On Wed, 12 Aug 2015, Viresh Kumar wrote:
> 
> > On 11-08-15, 16:17, Lee Jones wrote:
> > > This would work if we only had a single variable to contend with, but
> > > what I showed you in my previous example is that we have 3 variables
> > > to consider; cut (version), pcode and substrate.
> > > 
> > > Using the two (simple) examples I provided, how would your suggestion
> > > look in our case?
> > 
> > So the solution I gave is for picking the microvolt based on pcode.
> > The other two (cut, substrate) aren't about picking microvolt, but if
> > the OPP is available or not. Right?
> 
> 'pcode', 'cut' and 'substrate' all determine whether a given set of
> OPPs an be used on the running platform.  I do not believe that you
> can differentiate between them. 
> 
> > If these terms are generic enough, then we can add something similar
> > to what you have added..
> 
> If it makes it easier, you can treat them as version numbers 2.2.1
> <pcode.cut.substrate>, but I don't see how this can help.  Obviously
> this becomes more difficult when you add wild cards to the OPPs, where
> a particular OPP would be suitable for all cuts for example.
> 
> If you still think you can come up with a generic method to lay out
> CPUFreq OPP nodes that will satisfy all vendors and not be a mass of
> 10's of separate nodes, then great.  Again, I'm struggling to see how
> that might be possible.
> 
> What I believe we shouldn't do, is have this blocked forever for the
> sake of adding a couple of vendor properties however.

I agree and can understand the pain you are feeling..

@Rob/Stephen: Please close this thread soon and let Lee get his work
done :)

-- 
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]

#1217805

On Wed, Sep 2, 2015 at 3:06 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 26-08-15, 13:06, Lee Jones wrote:
>> On Wed, 12 Aug 2015, Viresh Kumar wrote:
>>
>> > On 11-08-15, 16:17, Lee Jones wrote:
>> > > This would work if we only had a single variable to contend with, but
>> > > what I showed you in my previous example is that we have 3 variables
>> > > to consider; cut (version), pcode and substrate.
>> > >
>> > > Using the two (simple) examples I provided, how would your suggestion
>> > > look in our case?
>> >
>> > So the solution I gave is for picking the microvolt based on pcode.
>> > The other two (cut, substrate) aren't about picking microvolt, but if
>> > the OPP is available or not. Right?
>>
>> 'pcode', 'cut' and 'substrate' all determine whether a given set of
>> OPPs an be used on the running platform.  I do not believe that you
>> can differentiate between them.
>>
>> > If these terms are generic enough, then we can add something similar
>> > to what you have added..
>>
>> If it makes it easier, you can treat them as version numbers 2.2.1
>> <pcode.cut.substrate>, but I don't see how this can help.  Obviously
>> this becomes more difficult when you add wild cards to the OPPs, where
>> a particular OPP would be suitable for all cuts for example.
>>
>> If you still think you can come up with a generic method to lay out
>> CPUFreq OPP nodes that will satisfy all vendors and not be a mass of
>> 10's of separate nodes, then great.  Again, I'm struggling to see how
>> that might be possible.
>>
>> What I believe we shouldn't do, is have this blocked forever for the
>> sake of adding a couple of vendor properties however.
>
> I agree and can understand the pain you are feeling..
>
> @Rob/Stephen: Please close this thread soon and let Lee get his work
> done :)

What do you expect here? It is your job to close it. Ultimately, this
will be your problem to deal with. If you have 10 different vendors
doing selection of OPPs in 10 different ways you will not be able to
change that easily later. Maybe if you can't come up with something
common, then this should just not go into DT. You can always look at
how to do this in a common way and move from the kernel to DT later.

Rob
--
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