Device tree binding for DVFS table

Device tree binding for DVFS table

[함명주]

> Hi,
>
> I am working on DT binding for Tegra DVFS.
>
> For Tegra, DVFS node mainly consists of frequency and voltage pairs. 
> Frequency in the pair may change for different process. E.g. for process 
> 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could 
> be 1GHz at 1V.
> Tegra uses vendor specific ids to identify the correct frequency table.

Hello,

It seems that in the example, the values in "voltage-array" and
"frequencies" are switched.

Anyway, what about SoCs that reads information from IEM (or any other module)
 to measure gate delays or some other value to set the appriorate voltage values
 for every possible frequency? I remember some of Exynos SoCs have been doing
 it; dynamically measure the characteristics at boot-up time and apply voltages
 accordingly; they couldn't identify it based on the chip-id or simply by reading
 a single register.


Cheers!
MyungJoo.

> 
> Following is the proposed binding for voltage and frequency tables used 
> in DVFS. Looking for comments/suggestions to make it generic.

Device tree binding for DVFS table

[Peter De Schrijver]

On Wed, Jul 11, 2012 at 03:08:14PM +0200, ??? wrote:
> > Hi,
> >
> > I am working on DT binding for Tegra DVFS.
> >
> > For Tegra, DVFS node mainly consists of frequency and voltage pairs. 
> > Frequency in the pair may change for different process. E.g. for process 
> > 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could 
> > be 1GHz at 1V.
> > Tegra uses vendor specific ids to identify the correct frequency table.
> 
> Hello,
> 
> It seems that in the example, the values in "voltage-array" and
> "frequencies" are switched.
> 
> Anyway, what about SoCs that reads information from IEM (or any other module)
>  to measure gate delays or some other value to set the appriorate voltage values
>  for every possible frequency? I remember some of Exynos SoCs have been doing
>  it; dynamically measure the characteristics at boot-up time and apply voltages
>  accordingly; they couldn't identify it based on the chip-id or simply by reading
>  a single register.

But in that case you would have a nominal voltage for each OPP which gets
adjusted at boottime or runtime depending on the exact silicon characteristics?
I would say the DT binding should then specify 1 table with the nominal values
and leave the dynamics to the driver.

Cheers,

Peter.

Device tree binding for DVFS table

[Peter De Schrijver]

On Wed, Jul 11, 2012 at 03:08:14PM +0200, ??? wrote:
> > Hi,
> >
> > I am working on DT binding for Tegra DVFS.
> >
> > For Tegra, DVFS node mainly consists of frequency and voltage pairs. 
> > Frequency in the pair may change for different process. E.g. for process 
> > 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could 
> > be 1GHz at 1V.
> > Tegra uses vendor specific ids to identify the correct frequency table.
> 
> Hello,
> 
> It seems that in the example, the values in "voltage-array" and
> "frequencies" are switched.
> 
> Anyway, what about SoCs that reads information from IEM (or any other module)
>  to measure gate delays or some other value to set the appriorate voltage values
>  for every possible frequency? I remember some of Exynos SoCs have been doing
>  it; dynamically measure the characteristics at boot-up time and apply voltages
>  accordingly; they couldn't identify it based on the chip-id or simply by reading
>  a single register.
> 


But in that case you would have a nominal voltage for each OPP which gets
adjusted at boottime or runtime depending on the exact silicon characteristics?
I would say the DT binding should then specify 1 table with the nominal values
and leave the dynamics to the driver.

Cheers,

Peter.

Device tree binding for DVFS table

[Prashant Gaikwad]

On Wednesday 11 July 2012 07:19 PM, Peter De Schrijver wrote:
> On Wed, Jul 11, 2012 at 03:08:14PM +0200, ??? wrote:
>>> Hi,
>>>
>>> I am working on DT binding for Tegra DVFS.
>>>
>>> For Tegra, DVFS node mainly consists of frequency and voltage pairs.
>>> Frequency in the pair may change for different process. E.g. for process
>>> 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could
>>> be 1GHz at 1V.
>>> Tegra uses vendor specific ids to identify the correct frequency table.
>> Hello,
>>
>> It seems that in the example, the values in "voltage-array" and
>> "frequencies" are switched.
>>
>> Anyway, what about SoCs that reads information from IEM (or any other module)
>>   to measure gate delays or some other value to set the appriorate voltage values
>>   for every possible frequency? I remember some of Exynos SoCs have been doing
>>   it; dynamically measure the characteristics at boot-up time and apply voltages
>>   accordingly; they couldn't identify it based on the chip-id or simply by reading
>>   a single register.
>>
>
> But in that case you would have a nominal voltage for each OPP which gets
> adjusted at boottime or runtime depending on the exact silicon characteristics?
> I would say the DT binding should then specify 1 table with the nominal values
> and leave the dynamics to the driver.

It makes sense or is it different than this?

> Cheers,
>
> Peter.
>

Device tree binding for DVFS table

[Prashant Gaikwad]

Hi,

I am working on DT binding for Tegra DVFS.

For Tegra, DVFS node mainly consists of frequency and voltage pairs. 
Frequency in the pair may change for different process. E.g. for process 
1 CPU clock frequency could be 900MHz at 1V while for process 2 it could 
be 1GHz at 1V.
Tegra uses vendor specific ids to identify the correct frequency table.

Following is the proposed binding for voltage and frequency tables used 
in DVFS. Looking for comments/suggestions to make it generic.

=======DVFS table node===================
This node defines the voltage configuration for the DVFS which includes 
the regulator and voltage array.

Required properties:

reg_id : <regulator phandle>;
voltage-table : <voltage array, values in mV>;

#address-cells and #size-cells : To identify correct frequency table 
using process id (or some other vendor specific way).

========Frequency table node===============

This node defines frequency configuration for the device DVFS.

Required properties:

In device node need a reference to the DVFS table node.

dvfs : the phandle for the DVFS table node

frequency-table at n
        reg = <n>; dependent on address-cells and size-cells in DVFS 
table node.
        frequencies = <frequency array, values in MHz>;
}

Example:
-------------------------------------------------------------------------

cpu-dvfs-table : dvfs-table {
               compatible = "nvidia,tegra30-dvfs-table";
               reg_id = <&sm0>;
               #address-cells = <1>;
               #size-cells = <0>;
               voltage-array = <750 775 800 825 850 875 900 925 950 975 
1000 1025 1050 1100 1125>;
};

device {
              dvfs = <&cpu-dvfs-table>;
              frequency-table at 102 {
                       reg = <0x102>;
                       frequencies = <314 314 314 456 456 456 608 608 
608 760 817 817 912 1000>;
              };
              frequency-table at 002 {
                       reg = <0x002>;
                       frequencies = <598 598 750 750 893 893 1000>;
              };
};

Thanks & Regards,
Prashant G

Device tree binding for DVFS table

[Rob Herring]

On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
> Hi,
> 
> I am working on DT binding for Tegra DVFS.
> 
> For Tegra, DVFS node mainly consists of frequency and voltage pairs.
> Frequency in the pair may change for different process. E.g. for process
> 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could
> be 1GHz at 1V.
> Tegra uses vendor specific ids to identify the correct frequency table.
> 
> Following is the proposed binding for voltage and frequency tables used
> in DVFS. Looking for comments/suggestions to make it generic.
> 
> =======DVFS table node===================
> This node defines the voltage configuration for the DVFS which includes
> the regulator and voltage array.
> 
> Required properties:
> 
> reg_id : <regulator phandle>;
> voltage-table : <voltage array, values in mV>;
> 
> #address-cells and #size-cells : To identify correct frequency table
> using process id (or some other vendor specific way).
> 
> ========Frequency table node===============
> 
> This node defines frequency configuration for the device DVFS.
> 
> Required properties:
> 
> In device node need a reference to the DVFS table node.
> 
> dvfs : the phandle for the DVFS table node
> 
> frequency-table at n
>        reg = <n>; dependent on address-cells and size-cells in DVFS
> table node.
>        frequencies = <frequency array, values in MHz>;

You are storing u32 values, why limit the resolution to MHz.

Put the unit in the property names.

> }
> 
> Example:
> -------------------------------------------------------------------------
> 
> cpu-dvfs-table : dvfs-table {

This should be located with the node that the frequencies correspond to.

>               compatible = "nvidia,tegra30-dvfs-table";
>               reg_id = <&sm0>;
>               #address-cells = <1>;
>               #size-cells = <0>;
>               voltage-array = <750 775 800 825 850 875 900 925 950 975
> 1000 1025 1050 1100 1125>;

The SOC is really characterized at all these voltages?

> };
> 
> device {
>              dvfs = <&cpu-dvfs-table>;
>              frequency-table at 102 {
>                       reg = <0x102>;
>                       frequencies = <314 314 314 456 456 456 608 608 608
> 760 817 817 912 1000>;

I don't see the point of repeating frequencies.

>              };
>              frequency-table at 002 {
>                       reg = <0x002>;
>                       frequencies = <598 598 750 750 893 893 1000>;
>              };

How do you determine the voltage for a frequency on table 2?

I'd expect a single property with freq/volt pairs or 2 properties for
freq and voltage where there is a 1:1 relationship (freq N uses voltage N).

Rob

> };
> 
> Thanks & Regards,
> Prashant G
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Device tree binding for DVFS table

[Mark Brown]

On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:

> I'd expect a single property with freq/volt pairs or 2 properties for
> freq and voltage where there is a 1:1 relationship (freq N uses voltage N).

I strongly agree - the current proposal is very hard to read due to the
separation between the voltage and frequency values.  Some devices do
also need to scale multiple rails together, especially when this gets
used for I/O devices.

I'd also expect to see a range of voltages for each frequency rather
than a specific voltage; usually things are at least characterised with
a specified tolerance.

Device tree binding for DVFS table

[Mike Turquette]

On 20120711-15:44, Mark Brown wrote:
> On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
> 
> > I'd expect a single property with freq/volt pairs or 2 properties for
> > freq and voltage where there is a 1:1 relationship (freq N uses voltage N).
> 
> I strongly agree - the current proposal is very hard to read due to the
> separation between the voltage and frequency values.  Some devices do
> also need to scale multiple rails together, especially when this gets
> used for I/O devices.
> 
> I'd also expect to see a range of voltages for each frequency rather
> than a specific voltage; usually things are at least characterised with
> a specified tolerance.

Not only should we support multiple voltage rails but also multiple
clocks.  For some devices a DVFS transition is composed of scaling
multiple clock rates together.  So some sort of clock identifier
(phandle?) is needed as well.  (forgive my ignorance on the phandle
part, as I am a DT noob)

Regards,
Mike

Device tree binding for DVFS table

[Prashant Gaikwad]

On Thursday 12 July 2012 01:34 AM, Mike Turquette wrote:
> On 20120711-15:44, Mark Brown wrote:
>> On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
>>
>>> I'd expect a single property with freq/volt pairs or 2 properties for
>>> freq and voltage where there is a 1:1 relationship (freq N uses voltage N).
>> I strongly agree - the current proposal is very hard to read due to the
>> separation between the voltage and frequency values.  Some devices do
>> also need to scale multiple rails together, especially when this gets
>> used for I/O devices.
>>
>> I'd also expect to see a range of voltages for each frequency rather
>> than a specific voltage; usually things are at least characterised with
>> a specified tolerance.
> Not only should we support multiple voltage rails but also multiple
> clocks.  For some devices a DVFS transition is composed of scaling
> multiple clock rates together.  So some sort of clock identifier
> (phandle?) is needed as well.  (forgive my ignorance on the phandle
> part, as I am a DT noob)

How about adding phandle of clock consumer node to frequency table?

> Regards,
> Mike

Device tree binding for DVFS table

[Peter De Schrijver]

On Wed, Jul 11, 2012 at 10:04:02PM +0200, Mike Turquette wrote:
> On 20120711-15:44, Mark Brown wrote:
> > On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
> > 
> > > I'd expect a single property with freq/volt pairs or 2 properties for
> > > freq and voltage where there is a 1:1 relationship (freq N uses voltage N).
> > 
> > I strongly agree - the current proposal is very hard to read due to the
> > separation between the voltage and frequency values.  Some devices do
> > also need to scale multiple rails together, especially when this gets
> > used for I/O devices.
> > 
> > I'd also expect to see a range of voltages for each frequency rather
> > than a specific voltage; usually things are at least characterised with
> > a specified tolerance.
> 
> Not only should we support multiple voltage rails but also multiple
> clocks.  For some devices a DVFS transition is composed of scaling
> multiple clock rates together.  So some sort of clock identifier
> (phandle?) is needed as well.  (forgive my ignorance on the phandle
> part, as I am a DT noob)

I would say this constraint should be expressed in a seperate DT node. In
short I think we have 3 things to model:

+ frequency/voltage relationships
+ power rail constraints (eg voltage difference limit between 2 rails)
+ clock constraints (eg. clock x frequency must be a fixed ratio of clock y
  frequency)

Cheers,

Peter.

Device tree binding for DVFS table

[Mike Turquette]

On 20120712-17:10, Peter De Schrijver wrote:
> On Wed, Jul 11, 2012 at 10:04:02PM +0200, Mike Turquette wrote:
> > On 20120711-15:44, Mark Brown wrote:
> > > On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
> > > 
> > > > I'd expect a single property with freq/volt pairs or 2 properties for
> > > > freq and voltage where there is a 1:1 relationship (freq N uses voltage N).
> > > 
> > > I strongly agree - the current proposal is very hard to read due to the
> > > separation between the voltage and frequency values.  Some devices do
> > > also need to scale multiple rails together, especially when this gets
> > > used for I/O devices.
> > > 
> > > I'd also expect to see a range of voltages for each frequency rather
> > > than a specific voltage; usually things are at least characterised with
> > > a specified tolerance.
> > 
> > Not only should we support multiple voltage rails but also multiple
> > clocks.  For some devices a DVFS transition is composed of scaling
> > multiple clock rates together.  So some sort of clock identifier
> > (phandle?) is needed as well.  (forgive my ignorance on the phandle
> > part, as I am a DT noob)
> 
> I would say this constraint should be expressed in a seperate DT node. In
> short I think we have 3 things to model:
> 

Peter,

I agree with your observations in general, but I think some specificity
is needed:

> + frequency/voltage relationships

We should be clear that the voltage does NOT belong to the clock, but to
the device/module/IP block that consumes that clock.  This is an
important detail since it means that a clock does not have a
corresponding table of voltages (e.g. one table per clock), but instead
a device has a table of voltages corresponding to each clock.

This is very necessary when a single clock drives multiple devices which
are driven by separate voltage rails.

> + power rail constraints (eg voltage difference limit between 2 rails)

This should come from regulator DT data and not anything DVFS-specific,
correct?

> + clock constraints (eg. clock x frequency must be a fixed ratio of clock y
>   frequency)

Yeah, after sending my email above yesterday I instantly regretted it.
It is true that *functional* clock dependencies are really the purview
of the device driver.  E.g. for Device X to operate at FAST_SPEED, scale
functional_clk up to 200MHz and l3_ddr_clk up to 100MHz.  On OMAP our
display subsystem block also has clock ratio rules that must be honored,
but it just open-coded.

It is possible to model those in DT if we really want, but shouldn't be
a priority for these dvfs-specific bindings.

Regards,
Mike

> 
> Cheers,
> 
> Peter.

Device tree binding for DVFS table

[Mark Brown]

On Thu, Jul 12, 2012 at 10:10:16AM -0700, Mike Turquette wrote:
> On 20120712-17:10, Peter De Schrijver wrote:

> > + power rail constraints (eg voltage difference limit between 2 rails)

> This should come from regulator DT data and not anything DVFS-specific,
> correct?

Currently the regulator API will only constrain individual rails (and
shortly likely parent/child relationships).  It will not do anything to
constrain between different rails, this has been left to the consumers.
For this stuff it may still make sense to do that if we've got a set of
operating points defined which apply over multiple inputs (like clock
and frequency) - we'll naturally impose these constraints by virtue of
selecting the operating point.

> > + clock constraints (eg. clock x frequency must be a fixed ratio of clock y
> >   frequency)

> Yeah, after sending my email above yesterday I instantly regretted it.
> It is true that *functional* clock dependencies are really the purview
> of the device driver.  E.g. for Device X to operate at FAST_SPEED, scale
> functional_clk up to 200MHz and l3_ddr_clk up to 100MHz.  On OMAP our
> display subsystem block also has clock ratio rules that must be honored,
> but it just open-coded.

This is similar to the regulator thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120712/161e4acc/attachment.sig>

Device tree binding for DVFS table

[Peter De Schrijver]

Hi Mike,

> 
> Peter,
> 
> I agree with your observations in general, but I think some specificity
> is needed:
> 
> > + frequency/voltage relationships
> 
> We should be clear that the voltage does NOT belong to the clock, but to
> the device/module/IP block that consumes that clock.  This is an
> important detail since it means that a clock does not have a
> corresponding table of voltages (e.g. one table per clock), but instead
> a device has a table of voltages corresponding to each clock.
> 

Or the other way around, a table of clock frequencies, 1 for each voltage.

> This is very necessary when a single clock drives multiple devices which
> are driven by separate voltage rails.
> 

Ah ok. How does this work in practice? A device can only run at a given clock
rate if all the rails are at a certain voltage?

> > + power rail constraints (eg voltage difference limit between 2 rails)
> 
> This should come from regulator DT data and not anything DVFS-specific,
> correct?
> 

That's true. I think it can even be open-coded as this is a SoC internal
thing. All boards using this SoC will have the same limits, so I see little
reason to move this info to DT.

> > + clock constraints (eg. clock x frequency must be a fixed ratio of clock y
> >   frequency)
> 
> Yeah, after sending my email above yesterday I instantly regretted it.
> It is true that *functional* clock dependencies are really the purview
> of the device driver.  E.g. for Device X to operate at FAST_SPEED, scale
> functional_clk up to 200MHz and l3_ddr_clk up to 100MHz.  On OMAP our
> display subsystem block also has clock ratio rules that must be honored,
> but it just open-coded.
> 
> It is possible to model those in DT if we really want, but shouldn't be
> a priority for these dvfs-specific bindings.
> 

Agreed.

Cheers,

Peter.

Device tree binding for DVFS table

[Mike Turquette]

On 20120713-13:34, Peter De Schrijver wrote:
> Hi Mike,
> 
> > 
> > Peter,
> > 
> > I agree with your observations in general, but I think some specificity
> > is needed:
> > 
> > > + frequency/voltage relationships
> > 
> > We should be clear that the voltage does NOT belong to the clock, but to
> > the device/module/IP block that consumes that clock.  This is an
> > important detail since it means that a clock does not have a
> > corresponding table of voltages (e.g. one table per clock), but instead
> > a device has a table of voltages corresponding to each clock.
> > 
> 
> Or the other way around, a table of clock frequencies, 1 for each voltage.
> 

ACK

You said what I meant to say.  Some previous iterations of an
omap-specific dvfs api tried to use voltage as the unique key for
accessing frequency/voltage tables, and that can get really ugly for a
variety of reasons.  Plus device drivers typically request performance
in Hertz (e.g. clk_set_rate), so exposing a voltage-centric interface to
them is generally useless.

The OPP library does some of this right (drivers/base/power/opp.c).  It
keeps a list of tables on a per-device bases, which is a big step in the
right direction.  Unfortunately it is lacking in other areas, such as
not specifying which clock corresponds to the to table.  Thus a device
can only have one table and that table does not encode any information
about which clock to use (which is important for devices that use a mux
to change rate).  The dvfs DT bindings should not repeat those mistakes.

> > This is very necessary when a single clock drives multiple devices which
> > are driven by separate voltage rails.
> > 
> 
> Ah ok. How does this work in practice? A device can only run at a given clock
> rate if all the rails are at a certain voltage?
> 

More like an adjustable rate clock higher up the tree affects the rate
of multiple devices downstream, and those devices happen to be on
separate rails.  Either way I think that the design should account for
this possibility.

Regards,
Mike

> > > + power rail constraints (eg voltage difference limit between 2 rails)
> > 
> > This should come from regulator DT data and not anything DVFS-specific,
> > correct?
> > 
> 
> That's true. I think it can even be open-coded as this is a SoC internal
> thing. All boards using this SoC will have the same limits, so I see little
> reason to move this info to DT.
> 
> > > + clock constraints (eg. clock x frequency must be a fixed ratio of clock y
> > >   frequency)
> > 
> > Yeah, after sending my email above yesterday I instantly regretted it.
> > It is true that *functional* clock dependencies are really the purview
> > of the device driver.  E.g. for Device X to operate at FAST_SPEED, scale
> > functional_clk up to 200MHz and l3_ddr_clk up to 100MHz.  On OMAP our
> > display subsystem block also has clock ratio rules that must be honored,
> > but it just open-coded.
> > 
> > It is possible to model those in DT if we really want, but shouldn't be
> > a priority for these dvfs-specific bindings.
> > 
> 
> Agreed.
> 
> Cheers,
> 
> Peter.

Device tree binding for DVFS table

[Prashant Gaikwad]

On Wednesday 11 July 2012 08:14 PM, Mark Brown wrote:
> On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
>
>> I'd expect a single property with freq/volt pairs or 2 properties for
>> freq and voltage where there is a 1:1 relationship (freq N uses voltage N).
> I strongly agree - the current proposal is very hard to read due to the
> separation between the voltage and frequency values.  Some devices do
> also need to scale multiple rails together, especially when this gets
> used for I/O devices.

Multiple rails for single clock or would it be multiple clocks?

> I'd also expect to see a range of voltages for each frequency rather
> than a specific voltage; usually things are at least characterised with
> a specified tolerance.

But then how will you determine the operating voltage for a frequency?

Device tree binding for DVFS table

[Mark Brown]

On Thu, Jul 12, 2012 at 09:47:42AM +0530, Prashant Gaikwad wrote:
> On Wednesday 11 July 2012 08:14 PM, Mark Brown wrote:

> >I'd also expect to see a range of voltages for each frequency rather
> >than a specific voltage; usually things are at least characterised with
> >a specified tolerance.

> But then how will you determine the operating voltage for a frequency?

By passing the range into the regulator API - the regulator API always
takes a voltage range anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120712/cf8d306e/attachment.sig>

Device tree binding for DVFS table

[Mike Turquette]

On 20120712-09:47, Prashant Gaikwad wrote:
> On Wednesday 11 July 2012 08:14 PM, Mark Brown wrote:
> >On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
> >
> >>I'd expect a single property with freq/volt pairs or 2 properties for
> >>freq and voltage where there is a 1:1 relationship (freq N uses voltage N).
> >I strongly agree - the current proposal is very hard to read due to the
> >separation between the voltage and frequency values.  Some devices do
> >also need to scale multiple rails together, especially when this gets
> >used for I/O devices.
> 
> Multiple rails for single clock or would it be multiple clocks?
> 

Voltage rails do not correspond to clocks.  They correspond to the IP
block in question (e.g. the "module" or "device" that consumes clocks
and voltage).

Regards,
Mike

Device tree binding for DVFS table

[Peter De Schrijver]

On Wed, Jul 11, 2012 at 04:44:50PM +0200, Mark Brown wrote:
> On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
> 
> > I'd expect a single property with freq/volt pairs or 2 properties for
> > freq and voltage where there is a 1:1 relationship (freq N uses voltage N).
> 
> I strongly agree - the current proposal is very hard to read due to the
> separation between the voltage and frequency values.  Some devices do
> also need to scale multiple rails together, especially when this gets
> used for I/O devices.
> 

I don't think dependencies between rails should be modelled in the same DT
nodes. We have those too in Tegra30, but as this is SoC internal, I am not
sure if it needs to be modelled in DT at all, or if we can leave it in SoC
specific code. While our current dependency is of the form 'voltage difference
between rail x and rail y must be smaller then z mV', I have been told these
dependencies might become more complicated in the future. Hence they might
need to be expressed in code anyway.
Anyway, I think voltage dependencies between rails is a related but seperate
topic from DVFS.

Cheers,

Peter.

Device tree binding for DVFS table

[Prashant Gaikwad]

On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>> Hi,
>>
>> I am working on DT binding for Tegra DVFS.
>>
>> For Tegra, DVFS node mainly consists of frequency and voltage pairs.
>> Frequency in the pair may change for different process. E.g. for process
>> 1 CPU clock frequency could be 900MHz at 1V while for process 2 it could
>> be 1GHz at 1V.
>> Tegra uses vendor specific ids to identify the correct frequency table.
>>
>> Following is the proposed binding for voltage and frequency tables used
>> in DVFS. Looking for comments/suggestions to make it generic.
>>
>> =======DVFS table node===================
>> This node defines the voltage configuration for the DVFS which includes
>> the regulator and voltage array.
>>
>> Required properties:
>>
>> reg_id :<regulator phandle>;
>> voltage-table :<voltage array, values in mV>;
>>
>> #address-cells and #size-cells : To identify correct frequency table
>> using process id (or some other vendor specific way).
>>
>> ========Frequency table node===============
>>
>> This node defines frequency configuration for the device DVFS.
>>
>> Required properties:
>>
>> In device node need a reference to the DVFS table node.
>>
>> dvfs : the phandle for the DVFS table node
>>
>> frequency-table at n
>>         reg =<n>; dependent on address-cells and size-cells in DVFS
>> table node.
>>         frequencies =<frequency array, values in MHz>;
> You are storing u32 values, why limit the resolution to MHz.
>
> Put the unit in the property names.
>

Unit can be changed, will do it.

>> }
>>
>> Example:
>> -------------------------------------------------------------------------
>>
>> cpu-dvfs-table : dvfs-table {
> This should be located with the node that the frequencies correspond to.
>

With CAR node?

>>                compatible = "nvidia,tegra30-dvfs-table";
>>                reg_id =<&sm0>;
>>                #address-cells =<1>;
>>                #size-cells =<0>;
>>                voltage-array =<750 775 800 825 850 875 900 925 950 975
>> 1000 1025 1050 1100 1125>;
> The SOC is really characterized at all these voltages?

Not really, but different processes of single SoC are characterized for 
different voltages and this array covers all those voltages.

>> };
>>
>> device {
>>               dvfs =<&cpu-dvfs-table>;
>>               frequency-table at 102 {
>>                        reg =<0x102>;
>>                        frequencies =<314 314 314 456 456 456 608 608 608
>> 760 817 817 912 1000>;
> I don't see the point of repeating frequencies.
>>               };
>>               frequency-table at 002 {
>>                        reg =<0x002>;
>>                        frequencies =<598 598 750 750 893 893 1000>;
>>               };
> How do you determine the voltage for a frequency on table 2?
>
> I'd expect a single property with freq/volt pairs or 2 properties for
> freq and voltage where there is a 1:1 relationship (freq N uses voltage N).


How this will work:

voltage-array =<750 775 800 825 850 875 900  925 950 975 1000 1025 1050 1100 1125>
frequencies-1 =<314 314 314 456 456 456 608  608 608 760 817  817  912  1000>;
frequencies-2 =<598 598 750 750 893 893 1000>;


Freq and voltage has 1:1 relationship but as single voltage table is 
used for different processes we have more entries in voltage table than 
freq table.
Frequency table 1 is mapped till 1100mV while frequency table 2 is 
mapped till 900mV only, it maintains 1:1 relationship.

About repeating frequencies, operating voltage for a frequency would be 
the highest one mapped in the table.
For example, in frequency table 2 operating voltage for 750MHz would be 
825mV while for 893MHz it would be 875mV. Unmapped entries could be 
replaced with 0 to make reading better.

Advantage it provides is single voltage table used for multiple 
frequency tables, as can be observed from above tables, operating 
voltage for 314MHz in freq table 1 is 800mV while there is no frequency 
in table 2 at that voltage.

I know this makes reading difficult but it provides flexibility,

I hope it explains the implementation.

> Rob
>
>> };
>>
>> Thanks&  Regards,
>> Prashant G
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Device tree binding for DVFS table

[Prashant Gaikwad]

Hi,

On Thursday 12 July 2012 09:38 AM, Prashant Gaikwad wrote:
> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>>> Hi,
>>>
>>> I am working on DT binding for Tegra DVFS.

<snip>

>>>                compatible = "nvidia,tegra30-dvfs-table";
>>>                reg_id =<&sm0>;
>>>                #address-cells =<1>;
>>>                #size-cells =<0>;
>>>                voltage-array =<750 775 800 825 850 875 900 925 950 975
>>> 1000 1025 1050 1100 1125>;
>> The SOC is really characterized at all these voltages?
>
> Not really, but different processes of single SoC are characterized 
> for different voltages and this array covers all those voltages.
>
>>> };
>>>
>>> device {
>>>               dvfs =<&cpu-dvfs-table>;
>>>               frequency-table at 102 {
>>>                        reg =<0x102>;
>>>                        frequencies =<314 314 314 456 456 456 608 608 
>>> 608
>>> 760 817 817 912 1000>;
>> I don't see the point of repeating frequencies.
>>>               };
>>>               frequency-table at 002 {
>>>                        reg =<0x002>;
>>>                        frequencies =<598 598 750 750 893 893 1000>;
>>>               };
>> How do you determine the voltage for a frequency on table 2?
>>
>> I'd expect a single property with freq/volt pairs or 2 properties for
>> freq and voltage where there is a 1:1 relationship (freq N uses 
>> voltage N).
>
>
> How this will work:
>
> voltage-array =<750 775 800 825 850 875 900  925 950 975 1000 1025 
> 1050 1100 1125>
> frequencies-1 =<314 314 314 456 456 456 608  608 608 760 817  817  
> 912  1000>;
> frequencies-2 =<598 598 750 750 893 893 1000>;
>
>
> Freq and voltage has 1:1 relationship but as single voltage table is 
> used for different processes we have more entries in voltage table 
> than freq table.
> Frequency table 1 is mapped till 1100mV while frequency table 2 is 
> mapped till 900mV only, it maintains 1:1 relationship.
>
> About repeating frequencies, operating voltage for a frequency would 
> be the highest one mapped in the table.
> For example, in frequency table 2 operating voltage for 750MHz would 
> be 825mV while for 893MHz it would be 875mV. Unmapped entries could be 
> replaced with 0 to make reading better.
>
> Advantage it provides is single voltage table used for multiple 
> frequency tables, as can be observed from above tables, operating 
> voltage for 314MHz in freq table 1 is 800mV while there is no 
> frequency in table 2 at that voltage.
>
> I know this makes reading difficult but it provides flexibility,
>
> I hope it explains the implementation.
>

Does this explanation help?

Regards,
Prashant G

>> Rob
>>
>>> };
>>>
>>> Thanks&  Regards,
>>> Prashant G
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>

Device tree binding for DVFS table

[Mark Brown]

On Sat, Jul 14, 2012 at 12:00:14AM +0530, Prashant Gaikwad wrote:
> On Thursday 12 July 2012 09:38 AM, Prashant Gaikwad wrote:

> >About repeating frequencies, operating voltage for a frequency
> >would be the highest one mapped in the table.

This sounds very surprising...  that would generally just result in
higher power consumption.

> >I know this makes reading difficult but it provides flexibility,

> Does this explanation help?

The loss of comprehensibility seems like a really major disadvantage for
very little practical gain here.  Big arrays in DT are already hard
enough to read without adding extra complexity on top of that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120715/d6dbc57c/attachment.sig>

Device tree binding for DVFS table

[Rob Herring]

On 07/11/2012 11:08 PM, Prashant Gaikwad wrote:
> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:

>>> cpu-dvfs-table : dvfs-table {
>> This should be located with the node that the frequencies correspond to.
>>
> 
> With CAR node?

With the power domain it corresponds to or the cpu nodes.

> 
>>>                compatible = "nvidia,tegra30-dvfs-table";
>>>                reg_id =<&sm0>;
>>>                #address-cells =<1>;
>>>                #size-cells =<0>;
>>>                voltage-array =<750 775 800 825 850 875 900 925 950 975
>>> 1000 1025 1050 1100 1125>;
>> The SOC is really characterized at all these voltages?
> 
> Not really, but different processes of single SoC are characterized for
> different voltages and this array covers all those voltages.
> 
>>> };
>>>
>>> device {
>>>               dvfs =<&cpu-dvfs-table>;
>>>               frequency-table at 102 {
>>>                        reg =<0x102>;
>>>                        frequencies =<314 314 314 456 456 456 608 608 608
>>> 760 817 817 912 1000>;
>> I don't see the point of repeating frequencies.
>>>               };
>>>               frequency-table at 002 {
>>>                        reg =<0x002>;
>>>                        frequencies =<598 598 750 750 893 893 1000>;
>>>               };
>> How do you determine the voltage for a frequency on table 2?
>>
>> I'd expect a single property with freq/volt pairs or 2 properties for
>> freq and voltage where there is a 1:1 relationship (freq N uses
>> voltage N).
> 
> 
> How this will work:
> 
> voltage-array =<750 775 800 825 850 875 900  925 950 975 1000 1025 1050
> 1100 1125>
> frequencies-1 =<314 314 314 456 456 456 608  608 608 760 817  817  912 
> 1000>;
> frequencies-2 =<598 598 750 750 893 893 1000>;
>

I don't see the point trying to share a voltage range. Not sharing it is
fewer array elements (22 vs 36):

voltage-array-1 =<750 825 900 975 1000 1050 1100>;
frequencies-1   =<314 456 608 760  817  912 1000>;

voltage-array-2 =<750 800 850  900>
frequencies-2   =<598 750 893 1000>;

Rob

> 
> Freq and voltage has 1:1 relationship but as single voltage table is
> used for different processes we have more entries in voltage table than
> freq table.
> Frequency table 1 is mapped till 1100mV while frequency table 2 is
> mapped till 900mV only, it maintains 1:1 relationship.
> 
> About repeating frequencies, operating voltage for a frequency would be
> the highest one mapped in the table.
> For example, in frequency table 2 operating voltage for 750MHz would be
> 825mV while for 893MHz it would be 875mV. Unmapped entries could be
> replaced with 0 to make reading better.
> 
> Advantage it provides is single voltage table used for multiple
> frequency tables, as can be observed from above tables, operating
> voltage for 314MHz in freq table 1 is 800mV while there is no frequency
> in table 2 at that voltage.
> 
> I know this makes reading difficult but it provides flexibility,
> 
> I hope it explains the implementation.
> 
>> Rob
>>
>>> };
>>>
>>> Thanks&  Regards,
>>> Prashant G
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> 

Device tree binding for DVFS table

[Turquette, Mike]

On Sun, Jul 15, 2012 at 4:42 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 07/11/2012 11:08 PM, Prashant Gaikwad wrote:
>> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>
>>>> cpu-dvfs-table : dvfs-table {
>>> This should be located with the node that the frequencies correspond to.
>>>
>>
>> With CAR node?
>
> With the power domain it corresponds to or the cpu nodes.
>
>>
>>>>                compatible = "nvidia,tegra30-dvfs-table";
>>>>                reg_id =<&sm0>;
>>>>                #address-cells =<1>;
>>>>                #size-cells =<0>;
>>>>                voltage-array =<750 775 800 825 850 875 900 925 950 975
>>>> 1000 1025 1050 1100 1125>;
>>> The SOC is really characterized at all these voltages?
>>
>> Not really, but different processes of single SoC are characterized for
>> different voltages and this array covers all those voltages.
>>
>>>> };
>>>>
>>>> device {
>>>>               dvfs =<&cpu-dvfs-table>;
>>>>               frequency-table at 102 {
>>>>                        reg =<0x102>;
>>>>                        frequencies =<314 314 314 456 456 456 608 608 608
>>>> 760 817 817 912 1000>;
>>> I don't see the point of repeating frequencies.
>>>>               };
>>>>               frequency-table at 002 {
>>>>                        reg =<0x002>;
>>>>                        frequencies =<598 598 750 750 893 893 1000>;
>>>>               };
>>> How do you determine the voltage for a frequency on table 2?
>>>
>>> I'd expect a single property with freq/volt pairs or 2 properties for
>>> freq and voltage where there is a 1:1 relationship (freq N uses
>>> voltage N).
>>
>>
>> How this will work:
>>
>> voltage-array =<750 775 800 825 850 875 900  925 950 975 1000 1025 1050
>> 1100 1125>
>> frequencies-1 =<314 314 314 456 456 456 608  608 608 760 817  817  912
>> 1000>;
>> frequencies-2 =<598 598 750 750 893 893 1000>;
>>
>
> I don't see the point trying to share a voltage range. Not sharing it is
> fewer array elements (22 vs 36):
>
> voltage-array-1 =<750 825 900 975 1000 1050 1100>;
> frequencies-1   =<314 456 608 760  817  912 1000>;
>
> voltage-array-2 =<750 800 850  900>
> frequencies-2   =<598 750 893 1000>;
>

This is significantly more readable.

Regards,
Mike

> Rob
>
>>
>> Freq and voltage has 1:1 relationship but as single voltage table is
>> used for different processes we have more entries in voltage table than
>> freq table.
>> Frequency table 1 is mapped till 1100mV while frequency table 2 is
>> mapped till 900mV only, it maintains 1:1 relationship.
>>
>> About repeating frequencies, operating voltage for a frequency would be
>> the highest one mapped in the table.
>> For example, in frequency table 2 operating voltage for 750MHz would be
>> 825mV while for 893MHz it would be 875mV. Unmapped entries could be
>> replaced with 0 to make reading better.
>>
>> Advantage it provides is single voltage table used for multiple
>> frequency tables, as can be observed from above tables, operating
>> voltage for 314MHz in freq table 1 is 800mV while there is no frequency
>> in table 2 at that voltage.
>>
>> I know this makes reading difficult but it provides flexibility,
>>
>> I hope it explains the implementation.
>>
>>> Rob
>>>
>>>> };
>>>>
>>>> Thanks&  Regards,
>>>> Prashant G
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>
>

Device tree binding for DVFS table

[Prashant Gaikwad]

On Tuesday 17 July 2012 12:06 AM, Turquette, Mike wrote:
> On Sun, Jul 15, 2012 at 4:42 PM, Rob Herring<robherring2@gmail.com>  wrote:
>> On 07/11/2012 11:08 PM, Prashant Gaikwad wrote:
>>> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>>>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>>>>> cpu-dvfs-table : dvfs-table {
>>>> This should be located with the node that the frequencies correspond to.
>>>>
>>> With CAR node?
>> With the power domain it corresponds to or the cpu nodes.
>>
>>>>>                 compatible = "nvidia,tegra30-dvfs-table";
>>>>>                 reg_id =<&sm0>;
>>>>>                 #address-cells =<1>;
>>>>>                 #size-cells =<0>;
>>>>>                 voltage-array =<750 775 800 825 850 875 900 925 950 975
>>>>> 1000 1025 1050 1100 1125>;
>>>> The SOC is really characterized at all these voltages?
>>> Not really, but different processes of single SoC are characterized for
>>> different voltages and this array covers all those voltages.
>>>
>>>>> };
>>>>>
>>>>> device {
>>>>>                dvfs =<&cpu-dvfs-table>;
>>>>>                frequency-table at 102 {
>>>>>                         reg =<0x102>;
>>>>>                         frequencies =<314 314 314 456 456 456 608 608 608
>>>>> 760 817 817 912 1000>;
>>>> I don't see the point of repeating frequencies.
>>>>>                };
>>>>>                frequency-table at 002 {
>>>>>                         reg =<0x002>;
>>>>>                         frequencies =<598 598 750 750 893 893 1000>;
>>>>>                };
>>>> How do you determine the voltage for a frequency on table 2?
>>>>
>>>> I'd expect a single property with freq/volt pairs or 2 properties for
>>>> freq and voltage where there is a 1:1 relationship (freq N uses
>>>> voltage N).
>>>
>>> How this will work:
>>>
>>> voltage-array =<750 775 800 825 850 875 900  925 950 975 1000 1025 1050
>>> 1100 1125>
>>> frequencies-1 =<314 314 314 456 456 456 608  608 608 760 817  817  912
>>> 1000>;
>>> frequencies-2 =<598 598 750 750 893 893 1000>;
>>>
>> I don't see the point trying to share a voltage range. Not sharing it is
>> fewer array elements (22 vs 36):
>>
>> voltage-array-1 =<750 825 900 975 1000 1050 1100>;
>> frequencies-1   =<314 456 608 760  817  912 1000>;
>>
>> voltage-array-2 =<750 800 850  900>
>> frequencies-2   =<598 750 893 1000>;
>>
> This is significantly more readable.

Instead of voltage array, I was thinking of following approach to 
represent operating points for DVFS

reg : operating voltage in microvolt
tolerance : can be used to calculate required voltage. (optional, can be 
replaced by other relevant parameter to calculate required voltage)
frequencies : Array of phandle, clock specifier and frequency for all 
the clocks related to this rail.

opp at 750000000 {
     reg = <750000000>;
     tolerance = <4>;
     frequency-table at 102 {
            reg = <0x102>;
            frequencies = <&osc 0 314000>, <&ref 1 500000>;
     };
};

opp at 800000000 {
     reg = <800000000>;
     tolerance = <4>;
     frequency-table at 102 {
            reg = <0x102>;
            frequencies = <&osc 0 456000>, <&ref 1 608000>;
     };
     frequency-table at 002 {
            reg = <0x002>;
            frequencies = <&osc 0 400000>, <&ref 1 560000>;
     };
};

It represents:
         - 1:1 mapping for voltage/frequency pair.
         - Voltage can be represented as range.
         - relationships between clock domain and rail.

Only issue I see is, if there are large number of operating points it 
will increase data in DT.

Any suggestions?

>
> Regards,
> Mike
>
>> Rob
>>
>>> Freq and voltage has 1:1 relationship but as single voltage table is
>>> used for different processes we have more entries in voltage table than
>>> freq table.
>>> Frequency table 1 is mapped till 1100mV while frequency table 2 is
>>> mapped till 900mV only, it maintains 1:1 relationship.
>>>
>>> About repeating frequencies, operating voltage for a frequency would be
>>> the highest one mapped in the table.
>>> For example, in frequency table 2 operating voltage for 750MHz would be
>>> 825mV while for 893MHz it would be 875mV. Unmapped entries could be
>>> replaced with 0 to make reading better.
>>>
>>> Advantage it provides is single voltage table used for multiple
>>> frequency tables, as can be observed from above tables, operating
>>> voltage for 314MHz in freq table 1 is 800mV while there is no frequency
>>> in table 2 at that voltage.
>>>
>>> I know this makes reading difficult but it provides flexibility,
>>>
>>> I hope it explains the implementation.
>>>
>>>> Rob
>>>>
>>>>> };
>>>>>
>>>>> Thanks&   Regards,
>>>>> Prashant G
>>>>>
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>

Device tree binding for DVFS table

[Mark Brown]

On Tue, Jul 17, 2012 at 06:07:23PM +0530, Prashant Gaikwad wrote:
> On Tuesday 17 July 2012 12:06 AM, Turquette, Mike wrote:

> reg : operating voltage in microvolt

What happens if there's more than one supply that needs to be varied?

> tolerance : can be used to calculate required voltage. (optional,
> can be replaced by other relevant parameter to calculate required
> voltage)

What are the semantics of this field?

Device tree binding for DVFS table

[Prashant Gaikwad]

On Tuesday 17 July 2012 06:50 PM, Mark Brown wrote:
> On Tue, Jul 17, 2012 at 06:07:23PM +0530, Prashant Gaikwad wrote:
>> On Tuesday 17 July 2012 12:06 AM, Turquette, Mike wrote:
>> reg : operating voltage in microvolt
> What happens if there's more than one supply that needs to be varied?

Each rail's dvfs-table will have OPP nodes defined for different 
voltages and each OPP node contains frequency for all clocks affecting 
that rail.

Just for presentation:

In following example when <&ref 1> clock rate is set to 500000, sm0 need 
to operate at 750000000 micrvolt and sm1 at 800000000.

dvfs-rail-1 {
      reg_id = <&sm0>;
      opp at 750000000 {
              frequency-table at 102 {
                      frequencies = <&osc 0 314000>, <&ref 1 500000>;
              };
      };
};

dvfs-rail-2 {
     reg_id = <&sm1>;
     opp at 800000000 {
             frequency-table at 102 {
                       frequencies = <&ref 1 5000000>;
             };
     };
};

>> tolerance : can be used to calculate required voltage. (optional,
>> can be replaced by other relevant parameter to calculate required
>> voltage)
> What are the semantics of this field?

I used "tolerance" just for example to derive the range of voltage.
May be as done for OMAP,
regulator_set_voltage(mpu_reg, volt - tol, volt + tol);

Device tree binding for DVFS table

[Mark Brown]

On Tue, Jul 17, 2012 at 07:52:12PM +0530, Prashant Gaikwad wrote:

> >What happens if there's more than one supply that needs to be varied?

> Each rail's dvfs-table will have OPP nodes defined for different
> voltages and each OPP node contains frequency for all clocks
> affecting that rail.

Right, but some systems have operating points which cover a combination
of voltages and frequencies in one operating point.  Your binding seems
to define operating points per supply with no tie in between supplies.

Device tree binding for DVFS table

[Prashant Gaikwad]

On Tuesday 17 July 2012 08:07 PM, Mark Brown wrote:
> On Tue, Jul 17, 2012 at 07:52:12PM +0530, Prashant Gaikwad wrote:
>
>>> What happens if there's more than one supply that needs to be varied?
>> Each rail's dvfs-table will have OPP nodes defined for different
>> voltages and each OPP node contains frequency for all clocks
>> affecting that rail.
> Right, but some systems have operating points which cover a combination
> of voltages and frequencies in one operating point.  Your binding seems
> to define operating points per supply with no tie in between supplies.

We had discussed this in previous replies and thought that it can be 
expressed in separate DT nodes, may be regulator.

Device tree binding for DVFS table

[Mark Brown]

On Wed, Jul 18, 2012 at 06:16:22PM +0530, Prashant Gaikwad wrote:
> On Tuesday 17 July 2012 08:07 PM, Mark Brown wrote:

> >Right, but some systems have operating points which cover a combination
> >of voltages and frequencies in one operating point.  Your binding seems
> >to define operating points per supply with no tie in between supplies.

> We had discussed this in previous replies and thought that it can be
> expressed in separate DT nodes, may be regulator.

So how are these intended to be tied together?  Is the kernel supposed
to infer the set of possible operating points by looking for overlaps or
does it have a list to work with?

Device tree binding for DVFS table

[Shawn Guo]

On Wed, Jul 11, 2012 at 06:26:30PM +0530, Prashant Gaikwad wrote:
> Hi,
> 
> I am working on DT binding for Tegra DVFS.
> 
> For Tegra, DVFS node mainly consists of frequency and voltage pairs.
> Frequency in the pair may change for different process. E.g. for
> process 1 CPU clock frequency could be 900MHz at 1V while for
> process 2 it could be 1GHz at 1V.
> Tegra uses vendor specific ids to identify the correct frequency table.
> 
> Following is the proposed binding for voltage and frequency tables
> used in DVFS. Looking for comments/suggestions to make it generic.
> 
It seems we are trying to approach a generic binding for DVFS operating
points.  In that case, we will need a generic library helper function
to parse it.  But since we already have such a library - OPP
(drivers/base/power/opp.c) in place, I would approach the same goal
in other way around, adding device tree binding for OPP.  Please see
the patch I just sent out below and comment.

[PATCH] PM / OPP: Initialize OPP table from device tree

-- 
Regards,
Shawn