On Wed, 16 Sep 2015, Viresh Kumar wrote:
> On 10-09-15, 09:31, Lee Jones wrote:
> > I think you answered your own question.
> >
> > No users == !ABI == Strip it out.
>
> Okay, as I have delayed things enough for you, didn't wanted to do
> that anymore. And so worked on it despite very tight sche
On 10-09-15, 09:31, Lee Jones wrote:
> I think you answered your own question.
>
> No users == !ABI == Strip it out.
Okay, as I have delayed things enough for you, didn't wanted to do
that anymore. And so worked on it despite very tight schedule :)
Below is the refreshed binding changes (I have
On Thu, 10 Sep 2015, Viresh Kumar wrote:
> On 09-09-15, 17:57, Stephen Boyd wrote:
> > I think it will work for qcom use cases.
>
> Thanks for the Rant Rob, it finally got me moving :)
>
> > We can collapse the
> > tables down to one node and have speed bin and version as the
> > opp-supported-h
On 09-09-15, 17:57, Stephen Boyd wrote:
> I think it will work for qcom use cases.
Thanks for the Rant Rob, it finally got me moving :)
> We can collapse the
> tables down to one node and have speed bin and version as the
> opp-supported-hw property. The opp-microvolt-names property would
I am p
On 09/09, Rob Herring wrote:
> On 09/09/2015 11:36 AM, Lee Jones wrote:
> >>> Or have I got the wrong end of the stick?
> >>>
> >>> NB: Note the suggested new property names.
> >>
> >> Yeah, all looks fine to me.
> >
> > I think these names are better:
> >
> > opp-supply-range-name => opp-micro
On 09/09/2015 11:36 AM, Lee Jones wrote:
>>> Or have I got the wrong end of the stick?
>>>
>>> NB: Note the suggested new property names.
>>
>> Yeah, all looks fine to me.
>
> I think these names are better:
>
> opp-supply-range-name => opp-microvolt-names
> opp-cuts => opp-suppo
> > Or have I got the wrong end of the stick?
> >
> > NB: Note the suggested new property names.
>
> Yeah, all looks fine to me.
I think these names are better:
opp-supply-range-name => opp-microvolt-names
opp-cuts => opp-supported-hw
Apart from that, the binding is starting t
On 09-09-15, 14:39, Lee Jones wrote:
> Okay, I see what you mean. Sound fine, although only allows up to 31
> versions. Not an issue for us I don't think, but could be for other
> vendors. Taking a recent example, the kernel recently went up to
> v2.6.39 and some of the stable releases have gone
On Wed, 09 Sep 2015, Viresh Kumar wrote:
> On 09-09-15, 08:59, Lee Jones wrote:
> > Thanks for doing this Viresh. I appreciate your efforts.
>
> I wanted to get this sorted out, before we meet face to face :)
>
> > > -8<-
> > > From: Viresh Kumar
On 09-09-15, 08:59, Lee Jones wrote:
> Thanks for doing this Viresh. I appreciate your efforts.
I wanted to get this sorted out, before we meet face to face :)
> > -8<-
> > From: Viresh Kumar
> > Date: Wed, 9 Sep 2015 11:47:37 +0530
> > Subject: [
On Wed, 09 Sep 2015, Viresh Kumar wrote:
> On 02-09-15, 13:58, Rob Herring wrote:
> > 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 t
On 02-09-15, 13:58, Rob Herring wrote:
> 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
On Wed, Sep 2, 2015 at 3:06 AM, Viresh Kumar 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 e
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 (
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
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 sugg
On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 11-08-15, 14:27, Lee Jones wrote:
> > Okay, so what you're saying is that you've already made the decision
> > to create a separate node for every OPP permutation,
>
> Absolutely not.
>
> > despite the fact
> > that I've told you this could lead to mo
On 11-08-15, 14:27, Lee Jones wrote:
> Okay, so what you're saying is that you've already made the decision
> to create a separate node for every OPP permutation,
Absolutely not.
> despite the fact
> that I've told you this could lead to more nodes than anyone would
> care to successfully write o
On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 11-08-15, 12:54, Lee Jones wrote:
> > The framework does not need to parse this information. It is used
> > solely by the platform driver, whose job it is to decide which OPPs
> > are appropriate for the running platform.
>
> The OPP layer needs to pa
On 11-08-15, 12:54, Lee Jones wrote:
> The framework does not need to parse this information. It is used
> solely by the platform driver, whose job it is to decide which OPPs
> are appropriate for the running platform.
The OPP layer needs to parse OPP nodes in DT. But for doing that it
needs to k
On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 11-08-15, 10:30, Lee Jones wrote:
> > On Tue, 11 Aug 2015, Viresh Kumar wrote:
> >
> > > On 10-08-15, 14:22, Lee Jones wrote:
> > > > > Optional properties:
> > > > > +- opp-cuts: One or more strings, describing the versions of hardware
> > > > > the
On 11-08-15, 10:30, Lee Jones wrote:
> On Tue, 11 Aug 2015, Viresh Kumar wrote:
>
> > On 10-08-15, 14:22, Lee Jones wrote:
> > > > Optional properties:
> > > > +- opp-cuts: One or more strings, describing the versions of hardware
> > > > the OPPs
> > > > + can support.
> > >
> > > This isn't v
On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 10-08-15, 14:22, Lee Jones wrote:
> > > Optional properties:
> > > +- opp-cuts: One or more strings, describing the versions of hardware the
> > > OPPs
> > > + can support.
> >
> > This isn't very generic.
> >
> > I'm guessing some vendors my have
On 10-08-15, 14:22, Lee Jones wrote:
> > Optional properties:
> > +- opp-cuts: One or more strings, describing the versions of hardware the
> > OPPs
> > + can support.
>
> This isn't very generic.
>
> I'm guessing some vendors my have quite a few ways to differentiate
> between board versions/
On Mon, 03 Aug 2015, Viresh Kumar wrote:
> On 31-07-15, 09:37, Stephen Boyd wrote:
> > For qcom platforms, the frequency is almost always constant.
> > There may be some tables where we have a couple higher
> > frequencies than others because the speed bin is different.
> > Otherwise the voltage/c
On 31-07-15, 09:37, Stephen Boyd wrote:
> For qcom platforms, the frequency is almost always constant.
> There may be some tables where we have a couple higher
> frequencies than others because the speed bin is different.
> Otherwise the voltage/current is changing based on the silicon
> characteri
On 31-07-15, 09:37, Stephen Boyd wrote:
> Do we need vendor specific properties for that though?
Sorry Lee :), but this is exactly why I wanted this thread to exist. We must and
should do this in a generic enough way.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On 07/30, Rob Herring wrote:
> On Thu, Jul 30, 2015 at 3:46 AM, Lee Jones wrote:
> >
> > There is nothing stopping us from representing the data in this way.
> > On the plus side, it would mean that we wouldn't need any vendor
> > specific properties. However, far outweighing the positives are th
On Thu, Jul 30, 2015 at 3:46 AM, Lee Jones wrote:
> On Wed, 29 Jul 2015, Stephen Boyd wrote:
>
>> On 07/29, Lee Jones wrote:
>> > On Tue, 28 Jul 2015, Stephen Boyd wrote:
>> >
>> > > On 07/28, Viresh Kumar wrote:
>> > > > Cc'ing few people (whom I cc'd last time as well :)).
>> > > >
>> > > > On 2
On Wed, 29 Jul 2015, Stephen Boyd wrote:
> On 07/29, Lee Jones wrote:
> > On Tue, 28 Jul 2015, Stephen Boyd wrote:
> >
> > > On 07/28, Viresh Kumar wrote:
> > > > Cc'ing few people (whom I cc'd last time as well :)).
> > > >
> > > > On 27-07-15, 16:20, Lee Jones wrote:
> > > > > + - opp-hz
On 07/29, Lee Jones wrote:
> On Tue, 28 Jul 2015, Stephen Boyd wrote:
>
> > On 07/28, Viresh Kumar wrote:
> > > Cc'ing few people (whom I cc'd last time as well :)).
> > >
> > > On 27-07-15, 16:20, Lee Jones wrote:
> > > > + - opp-hz : CPU frequency [Hz] for this OPP [See:
> > > > .
On Tue, 28 Jul 2015, Stephen Boyd wrote:
> On 07/28, Viresh Kumar wrote:
> > Cc'ing few people (whom I cc'd last time as well :)).
> >
> > On 27-07-15, 16:20, Lee Jones wrote:
> > > These OPPs are used in ST's CPUFreq implementation.
> > >
> > > Signed-off-by: Lee Jones
> > > ---
> > >
> > > C
On 07/28, Viresh Kumar wrote:
> Cc'ing few people (whom I cc'd last time as well :)).
>
> On 27-07-15, 16:20, Lee Jones wrote:
> > These OPPs are used in ST's CPUFreq implementation.
> >
> > Signed-off-by: Lee Jones
> > ---
> >
> > Changelog:
> > - None, new patch
> >
> > Documentation/devic
On Tue, 28 Jul 2015, Rob Herring wrote:
> On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones wrote:
> > On Tue, 28 Jul 2015, Rob Herring wrote:
> >
> >> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones wrote:
> >> > These OPPs are used in ST's CPUFreq implementation.
> >> >
> >> > Signed-off-by: Lee Jones
>
On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones wrote:
> On Tue, 28 Jul 2015, Rob Herring wrote:
>
>> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones wrote:
>> > These OPPs are used in ST's CPUFreq implementation.
>> >
>> > Signed-off-by: Lee Jones
>> > ---
>> >
>> > Changelog:
>> > - None, new patch
>>
On Tue, 28 Jul 2015, Rob Herring wrote:
> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones wrote:
> > These OPPs are used in ST's CPUFreq implementation.
> >
> > Signed-off-by: Lee Jones
> > ---
> >
> > Changelog:
> > - None, new patch
> >
> > Documentation/devicetree/bindings/power/opp-st.txt | 76
On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones wrote:
> These OPPs are used in ST's CPUFreq implementation.
>
> Signed-off-by: Lee Jones
> ---
>
> Changelog:
> - None, new patch
>
> Documentation/devicetree/bindings/power/opp-st.txt | 76
> ++
> 1 file changed, 76 insertions(+
On Tue, 28 Jul 2015, Viresh Kumar wrote:
> On 28-07-15, 08:34, Lee Jones wrote:
> > I disagree. For one, only 'opp-hz' is defined in ./opp.tx. Secondly
>
> There are other properties in op.txt like turbo, opp-suspend, latency,
> etc.. which can be useful for your platform to. Its not used for n
On 28-07-15, 08:34, Lee Jones wrote:
> I disagree. For one, only 'opp-hz' is defined in ./opp.tx. Secondly
There are other properties in op.txt like turbo, opp-suspend, latency,
etc.. which can be useful for your platform to. Its not used for now
is a different thing.
> it would be annoying to
On Tue, 28 Jul 2015, Viresh Kumar wrote:
> Cc'ing few people (whom I cc'd last time as well :)).
>
> On 27-07-15, 16:20, Lee Jones wrote:
> > These OPPs are used in ST's CPUFreq implementation.
> >
> > Signed-off-by: Lee Jones
> > ---
> >
> > Changelog:
> > - None, new patch
> >
> > Documen
Cc'ing few people (whom I cc'd last time as well :)).
On 27-07-15, 16:20, Lee Jones wrote:
> These OPPs are used in ST's CPUFreq implementation.
>
> Signed-off-by: Lee Jones
> ---
>
> Changelog:
> - None, new patch
>
> Documentation/devicetree/bindings/power/opp-st.txt | 76
> ++
These OPPs are used in ST's CPUFreq implementation.
Signed-off-by: Lee Jones
---
Changelog:
- None, new patch
Documentation/devicetree/bindings/power/opp-st.txt | 76 ++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt
42 matches
Mail list logo
