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
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
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 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
> >
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
> >
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
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 =>
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 =>
> > 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
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
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
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 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, 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
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
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, 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
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 =>
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
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 =>
> > 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
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
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 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, 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
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
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
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
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
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
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
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
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
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
> > > > >
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
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
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
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
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 very generic.
I'm
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 quite a few ways to
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 OPPs
+ can
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
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 parse OPP
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 or
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 more nodes
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
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/current
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
>
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
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
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
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
On 07/30, Rob Herring wrote:
On Thu, Jul 30, 2015 at 3:46 AM, Lee Jones lee.jo...@linaro.org 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
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
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 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: CPU frequency
On Thu, Jul 30, 2015 at 3:46 AM, Lee Jones lee.jo...@linaro.org 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 27-07-15,
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
> > > ---
> > >
> > >
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:
./opp.txt]
+ -
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 lee.jo...@linaro.org
---
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
> >
> >
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 |
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
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
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
> >
> >
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 lee.jo...@linaro.org
---
Changelog:
- None, new patch
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 now
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, Rob Herring wrote:
On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones lee.jo...@linaro.org wrote:
These OPPs are used in ST's CPUFreq implementation.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
Changelog:
- None, new patch
On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones lee.jo...@linaro.org wrote:
These OPPs are used in ST's CPUFreq implementation.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
Changelog:
- None, new patch
Documentation/devicetree/bindings/power/opp-st.txt | 76
++
1
On Tue, 28 Jul 2015, Rob Herring wrote:
On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones lee.jo...@linaro.org wrote:
On Tue, 28 Jul 2015, Rob Herring wrote:
On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones lee.jo...@linaro.org wrote:
These OPPs are used in ST's CPUFreq implementation.
On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones lee.jo...@linaro.org wrote:
On Tue, 28 Jul 2015, Rob Herring wrote:
On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones lee.jo...@linaro.org wrote:
These OPPs are used in ST's CPUFreq implementation.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
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 lee.jo...@linaro.org
---
Changelog:
- None, new patch
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
These OPPs are used in ST's CPUFreq implementation.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
Changelog:
- None, new patch
Documentation/devicetree/bindings/power/opp-st.txt | 76 ++
1 file changed, 76 insertions(+)
create mode 100644
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 lee.jo...@linaro.org
---
Changelog:
- None, new patch
Documentation/devicetree/bindings/power/opp-st.txt | 76
84 matches
Mail list logo