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

From	Rob Herring <robherring2@gmail.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
Date	2015-09-02 21:00 +0200
Message-ID	<q4lqi-5as-1@gated-at.bofh.it> (permalink)
References	(6 earlier) <pWiIW-7IE-31@gated-at.bofh.it> <pWjvj-su-1@gated-at.bofh.it> <pWC4V-2z5-11@gated-at.bofh.it> <q1HGG-5gu-21@gated-at.bofh.it> <q4bhg-7FS-19@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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/

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web