Skip to contentSkip to conversation

Device tree binding for DVFS table

DISCUSSION Prashant Gaikwad 6 participants 26 messages Jul 11, 2012 – Jul 18, 2012 Framebuffer layer

lore
Share & tools
lore

Prashant Gaikwad

author
#0 lore raw

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

#1 lore raw
Quoted 31 lines · 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:

Quoted 8 lines

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.

Quoted 6 lines

}

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

cpu-dvfs-table : dvfs-table {

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

Quoted 6 lines
              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?

Quoted 8 lines

};

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.

Quoted 5 lines
             };
             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

Quoted 9 lines

};

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

#2 lore raw
Quoted 2 lines · Rob Herring

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.

#3 lore raw
Quoted 5 lines · Mark Brown
Quoted 2 lines · Rob Herring

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).

Quoted 8 lines

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

author
#4 lore raw
Quoted 10 lines · Mike Turquette
Quoted 9 lines · Mark Brown
Quoted 2 lines · Rob Herring

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.

Quoted 8 lines
Quoted 3 lines

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?

Quoted 2 lines

Regards,
Mike

#5 lore raw
In reply to Mike Turquette
Quoted 15 lines · Mike Turquette
Quoted 5 lines · Mark Brown
Quoted 2 lines · Rob Herring

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).

Quoted 8 lines

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.

Quoted 5 lines

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.

#6 lore raw
Quoted 16 lines · Peter De Schrijver
Quoted 15 lines · Mike Turquette
Quoted 13 lines · Mark Brown
Quoted 2 lines · Rob Herring

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.

Quoted 9 lines
Quoted 5 lines

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:

Quoted 1 line

+ 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.

Quoted 1 line

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

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

Quoted 2 lines

+ 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

Quoted 4 lines

Cheers,

Peter.

#7 lore raw
Quoted 6 lines · Mike Turquette
Quoted 1 line · Peter De Schrijver

+ 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 9 lines
Quoted 2 lines

+ 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>

#8 lore raw
In reply to Mike Turquette

Hi Mike,

Quoted 6 lines

Peter,

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

Quoted 8 lines
Quoted 1 line

+ 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.

Quoted 3 lines

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 5 lines
Quoted 1 line

+ 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 10 lines
Quoted 2 lines

+ 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.

Quoted 3 lines

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.

#9 lore raw
Quoted 10 lines · Peter De Schrijver

Hi Mike,

Quoted 8 lines

Peter,

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

Quoted 1 line

+ frequency/voltage relationships

Quoted 9 lines
Quoted 6 lines

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 7 lines
Quoted 3 lines

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 29 lines
Quoted 5 lines
Quoted 1 line

+ 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 10 lines
Quoted 2 lines

+ 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.

Quoted 3 lines

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.

author
#10 lore raw
In reply to Mark Brown
Quoted 8 lines · Mark Brown
Quoted 2 lines · Rob Herring

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?

Quoted 3 lines

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?

#11 lore raw
Quoted 7 lines · Prashant Gaikwad
Quoted 3 lines · Mark Brown

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>

#12 lore raw
In reply to Prashant Gaikwad
Quoted 12 lines · Prashant Gaikwad
Quoted 8 lines · Mark Brown
Quoted 2 lines · Rob Herring

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

#13 lore raw
In reply to Mark Brown
Quoted 10 lines · Mark Brown
Quoted 2 lines · Rob Herring

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.

author
#14 lore raw
In reply to Rob Herring
Quoted 36 lines · Rob Herring
Quoted 35 lines · 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

Quoted 8 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 6 lines

}

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

cpu-dvfs-table : dvfs-table {

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

With CAR node?

Quoted 7 lines
Quoted 6 lines
               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.

Quoted 14 lines
Quoted 8 lines

};

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.

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

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.

Quoted 12 lines

Rob

Quoted 9 lines

};

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

author
#15 lore raw

Hi,

Quoted 5 lines · Prashant Gaikwad
Quoted 4 lines · Rob Herring
Quoted 3 lines · Prashant Gaikwad

Hi,

I am working on DT binding for Tegra DVFS.

<snip>

Quoted 54 lines
Quoted 7 lines
Quoted 6 lines
               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.

Quoted 15 lines
Quoted 9 lines

};

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.

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

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.

Quoted 9 lines

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

Quoted 13 lines
Quoted 12 lines

Rob

Quoted 9 lines

};

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

#16 lore raw
Quoted 4 lines · Prashant Gaikwad
Quoted 2 lines · Prashant Gaikwad

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 3 lines
Quoted 1 line

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>

#17 lore raw
In reply to Prashant Gaikwad
Quoted 8 lines · Prashant Gaikwad
Quoted 5 lines · Rob Herring
Quoted 1 line · Prashant Gaikwad

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.

Quoted 33 lines
Quoted 8 lines
Quoted 7 lines
               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.

Quoted 14 lines
Quoted 8 lines

};

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.

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

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).

Quoted 8 lines

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

Quoted 35 lines

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.

Quoted 12 lines

Rob

Quoted 9 lines

};

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

#18 lore raw
Quoted 54 lines · Rob Herring
Quoted 8 lines · Prashant Gaikwad
Quoted 5 lines · Rob Herring
Quoted 1 line · Prashant Gaikwad

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.

Quoted 33 lines
Quoted 8 lines
Quoted 7 lines
               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.

Quoted 14 lines
Quoted 8 lines

};

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.

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

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).

Quoted 8 lines

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>;

Quoted 9 lines

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

Quoted 39 lines

Rob

Quoted 35 lines

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.

Quoted 12 lines

Rob

Quoted 9 lines

};

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

author
#19 lore raw
Quoted 51 lines · Mike
Quoted 50 lines · Rob Herring
Quoted 6 lines · Prashant Gaikwad
Quoted 4 lines · Rob Herring
Quoted 1 line · Prashant Gaikwad

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.

Quoted 30 lines
Quoted 7 lines
Quoted 6 lines
                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.

Quoted 14 lines
Quoted 8 lines

};

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.

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

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).

Quoted 8 lines

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):

Quoted 7 lines
Quoted 6 lines

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?

Quoted 39 lines

Regards,
Mike

Quoted 35 lines

Rob

Quoted 32 lines

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.

Quoted 11 lines

Rob

Quoted 9 lines

};

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

#20 lore raw
Quoted 3 lines · Prashant Gaikwad

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?

Quoted 3 lines

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?

author
#21 lore raw
Quoted 4 lines · Mark Brown
Quoted 2 lines · Prashant Gaikwad

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>;
             };
     };
};
Quoted 4 lines
Quoted 3 lines

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);

#22 lore raw
Quoted 5 lines · Prashant Gaikwad
Quoted 1 line

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.

author
#23 lore raw
Quoted 9 lines · Mark Brown
Quoted 4 lines · Prashant Gaikwad
Quoted 1 line

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.

#24 lore raw
Quoted 8 lines · Prashant Gaikwad
Quoted 3 lines · Mark Brown

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?

#25 lore raw
In reply to Prashant Gaikwad
Quoted 4 lines · Prashant Gaikwad

Hi,

I am working on DT binding for Tegra DVFS.

Quoted 9 lines

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

Signature · 2 lines
Regards,
Shawn