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@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@102 {
reg = <0x102>;
frequencies = <314 314 314 456 456 456 608 608
608 760 817 817 912 1000>;
};
frequency-table@002 {
reg = <0x002>;
frequencies = <598 598 750 750 893 893 1000>;
};
};
Thanks & Regards,
Prashant G
From: Rob Herring <hidden> Date: 2012-07-11 14:03:41
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@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.
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
From: Mark Brown <hidden> Date: 2012-07-11 14:44:50
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.
From: Mike Turquette <hidden> Date: 2012-07-11 20:04:02
On 20120711-15:44, Mark Brown wrote:
On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
quoted
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
On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
quoted
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@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.
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.
On Thursday 12 July 2012 01:34 AM, Mike Turquette wrote:
On 20120711-15:44, Mark Brown wrote:
quoted
On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
quoted
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?
On Wednesday 11 July 2012 08:14 PM, Mark Brown wrote:
On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
quoted
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?
From: Peter De Schrijver <hidden> Date: 2012-07-12 08:19:15
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:
quoted
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.
From: Peter De Schrijver <hidden> Date: 2012-07-12 14:10:01
On Wed, Jul 11, 2012 at 10:04:02PM +0200, Mike Turquette wrote:
On 20120711-15:44, Mark Brown wrote:
quoted
On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
quoted
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.
From: Mark Brown <hidden> Date: 2012-07-12 15:23:20
On Thu, Jul 12, 2012 at 09:47:42AM +0530, Prashant Gaikwad wrote:
On Wednesday 11 July 2012 08:14 PM, Mark Brown wrote:
quoted
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.
From: Mike Turquette <hidden> Date: 2012-07-12 17:01:51
On 20120712-09:47, Prashant Gaikwad wrote:
On Wednesday 11 July 2012 08:14 PM, Mark Brown wrote:
quoted
On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
quoted
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
From: Mike Turquette <hidden> Date: 2012-07-12 17:10:16
On 20120712-17:10, Peter De Schrijver wrote:
On Wed, Jul 11, 2012 at 10:04:02PM +0200, Mike Turquette wrote:
quoted
On 20120711-15:44, Mark Brown wrote:
quoted
On Wed, Jul 11, 2012 at 09:03:41AM -0500, Rob Herring wrote:
quoted
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
From: Mark Brown <hidden> Date: 2012-07-12 17:15:29
On Thu, Jul 12, 2012 at 10:10:16AM -0700, Mike Turquette wrote:
On 20120712-17:10, Peter De Schrijver wrote:
quoted
+ 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.
quoted
+ 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.
From: Peter De Schrijver <hidden> Date: 2012-07-13 10:34:08
Hi Mike,
Peter,
I agree with your observations in general, but I think some specificity
is needed:
quoted
+ 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?
quoted
+ 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.
quoted
+ 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.
From: Mike Turquette <hidden> Date: 2012-07-13 17:25:32
On 20120713-13:34, Peter De Schrijver wrote:
Hi Mike,
quoted
Peter,
I agree with your observations in general, but I think some specificity
is needed:
quoted
+ 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.
quoted
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
quoted
quoted
+ 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.
quoted
quoted
+ 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.
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.
From: Mark Brown <hidden> Date: 2012-07-15 21:40:34
On Sat, Jul 14, 2012 at 12:00:14AM +0530, Prashant Gaikwad wrote:
On Thursday 12 July 2012 09:38 AM, Prashant Gaikwad wrote:
quoted
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.
quoted
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.
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).
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.
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).
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
quoted
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.
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).
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@750000000 {
reg = <750000000>;
tolerance = <4>;
frequency-table@102 {
reg = <0x102>;
frequencies = <&osc 0 314000>, <&ref 1 500000>;
};
};
opp@800000000 {
reg = <800000000>;
tolerance = <4>;
frequency-table@102 {
reg = <0x102>;
frequencies = <&osc 0 456000>, <&ref 1 608000>;
};
frequency-table@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
quoted
Rob
quoted
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.
On Tuesday 17 July 2012 06:50 PM, Mark Brown wrote:
On Tue, Jul 17, 2012 at 06:07:23PM +0530, Prashant Gaikwad wrote:
quoted
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@750000000 {
frequency-table@102 {
frequencies = <&osc 0 314000>, <&ref 1 500000>;
};
};
};
dvfs-rail-2 {
reg_id = <&sm1>;
opp@800000000 {
frequency-table@102 {
frequencies = <&ref 1 5000000>;
};
};
};
quoted
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);
From: Mark Brown <hidden> Date: 2012-07-17 14:37:54
On Tue, Jul 17, 2012 at 07:52:12PM +0530, Prashant Gaikwad wrote:
quoted
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.
On Tuesday 17 July 2012 08:07 PM, Mark Brown wrote:
On Tue, Jul 17, 2012 at 07:52:12PM +0530, Prashant Gaikwad wrote:
quoted
quoted
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.
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
From: Mark Brown <hidden> Date: 2012-07-18 21:19:57
On Wed, Jul 18, 2012 at 06:16:22PM +0530, Prashant Gaikwad wrote:
On Tuesday 17 July 2012 08:07 PM, Mark Brown wrote:
quoted
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?