On 27-12-17, 15:36, Rob Herring wrote:
> On Tue, Dec 26, 2017 at 10:45 PM, Viresh Kumar
> wrote:
> > On 26-12-17, 14:23, Rob Herring wrote:
> >> > cpu_opp_table: cpu_opp_table {
> >> > compatible = "operating-points-v2";
> >> > opp-shared;
> >> >
> >> >
On Tue, Dec 26, 2017 at 10:45 PM, Viresh Kumar wrote:
> On 26-12-17, 14:23, Rob Herring wrote:
>> > cpu_opp_table: cpu_opp_table {
>> > compatible = "operating-points-v2";
>> > opp-shared;
>> >
>> > opp00 {
>> > opp-hz
On 26-12-17, 14:23, Rob Herring wrote:
> > cpu_opp_table: cpu_opp_table {
> > compatible = "operating-points-v2";
> > opp-shared;
> >
> > opp00 {
> > opp-hz = /bits/ 64 <20800>;
> > clock-lat
On Thu, Nov 30, 2017 at 12:59 AM, Viresh Kumar wrote:
> On 29-11-17, 16:50, Stephen Boyd wrote:
>> Sorry it still makes zero sense to me. It seems that we're trying
>> to make the OPP table parsing generic just for the sake of code
>> brevity.
>
> Not just the code but bindings as well to make sur
On 30-11-17, 12:29, Viresh Kumar wrote:
> On 29-11-17, 16:50, Stephen Boyd wrote:
> > Sorry it still makes zero sense to me. It seems that we're trying
> > to make the OPP table parsing generic just for the sake of code
> > brevity.
>
> Not just the code but bindings as well to make sure we don't
On 29-11-17, 16:50, Stephen Boyd wrote:
> Sorry it still makes zero sense to me. It seems that we're trying
> to make the OPP table parsing generic just for the sake of code
> brevity.
Not just the code but bindings as well to make sure we don't add a new
property (similar to earlier ones) for eve
On 11/28, Ulf Hansson wrote:
> On 2 November 2017 at 10:00, Viresh Kumar wrote:
> > On 02-11-17, 00:15, Stephen Boyd wrote:
> >> Sorry I'm not following. We're going to need to have platform
> >> specific code that understands platform specific bindings that
> >> aren't shoved into the generic OPP
On 2 November 2017 at 10:00, Viresh Kumar wrote:
> On 02-11-17, 00:15, Stephen Boyd wrote:
>> Sorry I'm not following. We're going to need to have platform
>> specific code that understands platform specific bindings that
>> aren't shoved into the generic OPP bindings.
>
> At least I am not target
On 31 October 2017 at 13:47, Viresh Kumar wrote:
> On some platforms the exact frequency or voltage may be hidden from the
> OS by the firmware. Allow such configurations to pass magic values in
> the "opp-hz" or the "opp-microvolt" properties, which should be
> interpreted in a platform dependent
On 02-11-17, 00:15, Stephen Boyd wrote:
> Sorry I'm not following. We're going to need to have platform
> specific code that understands platform specific bindings that
> aren't shoved into the generic OPP bindings.
At least I am not targeting any platform specific binding right now.
The way I see
On 11/02, Viresh Kumar wrote:
> On 01-11-17, 14:43, Stephen Boyd wrote:
> > On 11/01, Rob Herring wrote:
> > > On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar
> > > wrote:
> > > > On 31 October 2017 at 16:02, Rob Herring wrote:
> > > >> Why not a new property for magic values? opp-magic? Don't we
On 01-11-17, 14:43, Stephen Boyd wrote:
> On 11/01, Rob Herring wrote:
> > On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar
> > wrote:
> > > On 31 October 2017 at 16:02, Rob Herring wrote:
> > >> Why not a new property for magic values? opp-magic? Don't we want to
> > >> know when we have magic val
On 01-11-17, 15:39, Rob Herring wrote:
> On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar wrote:
> > On 31 October 2017 at 16:02, Rob Herring wrote:
> >> Why not a new property for magic values? opp-magic? Don't we want to
> >> know when we have magic values?
> >
> > I have kept a separate property
On 11/01, Rob Herring wrote:
> On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar wrote:
> > On 31 October 2017 at 16:02, Rob Herring wrote:
> >> Why not a new property for magic values? opp-magic? Don't we want to
> >> know when we have magic values?
> >
> > I have kept a separate property since begi
On Tue, Oct 31, 2017 at 9:17 PM, Viresh Kumar wrote:
> On 31 October 2017 at 16:02, Rob Herring wrote:
>> Why not a new property for magic values? opp-magic? Don't we want to
>> know when we have magic values?
>
> I have kept a separate property since beginning (domain-performance-state)
> and mo
On 31 October 2017 at 16:02, Rob Herring wrote:
> Why not a new property for magic values? opp-magic? Don't we want to
> know when we have magic values?
I have kept a separate property since beginning (domain-performance-state)
and moved to using these magic values in the existing field because o
On Tue, Oct 31, 2017 at 7:47 AM, Viresh Kumar wrote:
> On some platforms the exact frequency or voltage may be hidden from the
> OS by the firmware. Allow such configurations to pass magic values in
> the "opp-hz" or the "opp-microvolt" properties, which should be
> interpreted in a platform depen
On some platforms the exact frequency or voltage may be hidden from the
OS by the firmware. Allow such configurations to pass magic values in
the "opp-hz" or the "opp-microvolt" properties, which should be
interpreted in a platform dependent way.
Signed-off-by: Viresh Kumar
---
Documentation/dev
18 matches
Mail list logo
