sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
(or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
voltage for the lowest operating point to 1.0V so all boards can actually use
it.
Signed-off-by: Timo Sigurdsson <[email protected]>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 6a63f30..f5f384c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -107,7 +107,7 @@
720000 1200000
528000 1100000
312000 1000000
- 144000 900000
+ 144000 1000000
>;
#cooling-cells = <2>;
cooling-min-level = <0>;
--
2.1.4
Hi Timo,
On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
<[email protected]> wrote:
> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
> voltage for the lowest operating point to 1.0V so all boards can actually use
> it.
Surely it wouldn't be added here if some could supply 0.9v.
Is the code that uses this smart enough to sensibly switch between two
operating points with the same frequency and different voltages? If
so, maybe just add a 144MHz @ 1.0v operating point?
(Alternatively, would it make sense to modify the code that uses this
to use frequencies with voltages specified that are lower than can be
supplied with the lowest voltage it can?)
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
Hi,
On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby <[email protected]> wrote:
> Hi Timo,
>
> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
> <[email protected]> wrote:
>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
>> voltage for the lowest operating point to 1.0V so all boards can actually use
>> it.
>
> Surely it wouldn't be added here if some could supply 0.9v.
On the side, the original OPPs in the FEX files are actually
frequency/voltage ranges, and not just points. Mainlines OPPv2
will support these, along with turbo frequencies.
Furthermore, the FEX files also have fields that limit the
minimum and maximum frequencies.
> Is the code that uses this smart enough to sensibly switch between two
> operating points with the same frequency and different voltages? If
> so, maybe just add a 144MHz @ 1.0v operating point?
You could try. Though I really don't see much to gain here.
> (Alternatively, would it make sense to modify the code that uses this
> to use frequencies with voltages specified that are lower than can be
> supplied with the lowest voltage it can?)
I think that's a bit harder to get accepted.
ChenYu
Hi Chen-Yu,
On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai <[email protected]> wrote:
> Hi,
>
> On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby <[email protected]> wrote:
>> Hi Timo,
>>
>> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
>> <[email protected]> wrote:
>>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
>>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
>>> voltage for the lowest operating point to 1.0V so all boards can actually use
>>> it.
>>
>> Surely it wouldn't be added here if some could supply 0.9v.
>
> On the side, the original OPPs in the FEX files are actually
> frequency/voltage ranges, and not just points. Mainlines OPPv2
> will support these, along with turbo frequencies.
Ah, that makes sense.
> Furthermore, the FEX files also have fields that limit the
> minimum and maximum frequencies.
Is this going to be supported by OPPv2 too?
>> Is the code that uses this smart enough to sensibly switch between two
>> operating points with the same frequency and different voltages? If
>> so, maybe just add a 144MHz @ 1.0v operating point?
>
> You could try. Though I really don't see much to gain here.
>From what I recall, lower frequency = less power usage, though my
experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing
a lot of details. This is the sort of thing that requires thorough
testing on a dev board.
>> (Alternatively, would it make sense to modify the code that uses this
>> to use frequencies with voltages specified that are lower than can be
>> supplied with the lowest voltage it can?)
>
> I think that's a bit harder to get accepted.
Oh, definitely. It kinda makes sense, but at the same time it'll
require some seriously thorough testing on a lot of different boards.
My only real objection here is are there boards that can go down to
0.9v and if so, won't this change make them less power efficient in
the almost-idle case? And are those power savings enough to justify
not accepting this patch?
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
On Mon, Aug 3, 2015 at 12:22 PM, Julian Calaby <[email protected]> wrote:
> Hi Chen-Yu,
>
> On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai <[email protected]> wrote:
>> Hi,
>>
>> On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby <[email protected]> wrote:
>>> Hi Timo,
>>>
>>> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
>>> <[email protected]> wrote:
>>>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
>>>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
>>>> voltage for the lowest operating point to 1.0V so all boards can actually use
>>>> it.
>>>
>>> Surely it wouldn't be added here if some could supply 0.9v.
>>
>> On the side, the original OPPs in the FEX files are actually
>> frequency/voltage ranges, and not just points. Mainlines OPPv2
>> will support these, along with turbo frequencies.
>
> Ah, that makes sense.
>
>> Furthermore, the FEX files also have fields that limit the
>> minimum and maximum frequencies.
>
> Is this going to be supported by OPPv2 too?
IIRC yes, OPPv2 moves to a range profile. OPPv2 is not merged yet.
>>> Is the code that uses this smart enough to sensibly switch between two
>>> operating points with the same frequency and different voltages? If
>>> so, maybe just add a 144MHz @ 1.0v operating point?
>>
>> You could try. Though I really don't see much to gain here.
>
> From what I recall, lower frequency = less power usage, though my
> experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing
> a lot of details. This is the sort of thing that requires thorough
> testing on a dev board.
I agree, though my limited experiences tell me that the major savings
come from lowering the core voltage.
>>> (Alternatively, would it make sense to modify the code that uses this
>>> to use frequencies with voltages specified that are lower than can be
>>> supplied with the lowest voltage it can?)
>>
>> I think that's a bit harder to get accepted.
>
> Oh, definitely. It kinda makes sense, but at the same time it'll
> require some seriously thorough testing on a lot of different boards.
>
> My only real objection here is are there boards that can go down to
> 0.9v and if so, won't this change make them less power efficient in
> the almost-idle case? And are those power savings enough to justify
> not accepting this patch?
This will require most testing as well. (sigh) Alas, my boards aren't
stable enough at 0.9V, so I can't say much about it.
ChenYu
Hi Julian,
Julian Calaby schrieb am 03.08.2015 01:35:
>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20
>> boards
>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
>> voltage for the lowest operating point to 1.0V so all boards can actually use
>> it.
>
> Surely it wouldn't be added here if some could supply 0.9v.
Maybe. I just know some boards don't (e.g. Cubieboard 2, Cubietruck, BananaPi)
and don't know of any that does. But that's not my point. I think that a common
minimum operating point, defined on the SOC level, should be defined in a way
that works on all boards.
>
> Is the code that uses this smart enough to sensibly switch between two
> operating points with the same frequency and different voltages? If
> so, maybe just add a 144MHz @ 1.0v operating point?
I never tried and I probably won't have time to test that before the weekend.
The current behaviour is this, though: On boards that set their minimum CPU
voltage to 1.0V, the lowest operating point will simply not be available to
the user.
> (Alternatively, would it make sense to modify the code that uses this
> to use frequencies with voltages specified that are lower than can be
> supplied with the lowest voltage it can?)
Considering OPPv2 is in the works, maybe not?
Thanks,
Timo
Hi again,
Julian Calaby schrieb am 03.08.2015 06:22:
> My only real objection here is are there boards that can go down to
> 0.9v and if so, won't this change make them less power efficient in
> the almost-idle case? And are those power savings enough to justify
> not accepting this patch?
It will probably make those boards less power efficient, yes. On the
other hand, boards that have their CPU regulator set to min. 1.0V might
also draw more power because the lowest frequency is not available,
even though the savings due to frequency are likely to be lower than
the savings due to voltage.
However, Stefan Monnier (added to CC) mentioned in an earlier
discussion that the savings for the lowest opp are rather small and
thus the benefit of the 144MHz opp would be questionable.
Unfortunately, I don't have measurement equipment precise enough to
test this myself and haven't found a way to read power consumption
internally via the PMU in mainline yet.
Thanks,
Timo
On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote:
> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
> voltage for the lowest operating point to 1.0V so all boards can actually use
> it.
This is not a property of a board, but is the actual limit documented
by Allwinner for the A20. Some individual SoCs might have wider
tolerances, but that's not a property of a board, it's really a
property of a single SoC, and we cannot make any assumption on the
board.
(and please make sure to run checkpatch before sending your patches)
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Mon, Aug 03, 2015 at 09:35:51AM +1000, Julian Calaby wrote:
> Hi Timo,
>
> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
> <[email protected]> wrote:
> > sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
> > (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
> > voltage for the lowest operating point to 1.0V so all boards can actually use
> > it.
>
> Surely it wouldn't be added here if some could supply 0.9v.
>
> Is the code that uses this smart enough to sensibly switch between two
> operating points with the same frequency and different voltages? If
> so, maybe just add a 144MHz @ 1.0v operating point?
And how would it choose between the two exactly ? Switch to the 144MHz
@ 0.9V and see if it works ? If it doesn't you might have screwed your
system already, and might not be able to recover from it at all.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Mon, Aug 03, 2015 at 10:37:51AM +0200, Timo Sigurdsson wrote:
> Hi Julian,
>
> Julian Calaby schrieb am 03.08.2015 01:35:
> >> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20
> >> boards
> >> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
> >> voltage for the lowest operating point to 1.0V so all boards can actually use
> >> it.
> >
> > Surely it wouldn't be added here if some could supply 0.9v.
>
> Maybe. I just know some boards don't (e.g. Cubieboard 2, Cubietruck, BananaPi)
> and don't know of any that does. But that's not my point. I think that a common
> minimum operating point, defined on the SOC level, should be defined in a way
> that works on all boards.
All of them can supply it. The DCDC2 regulator they use for the CPU
can go as low as 0.7V. The question is whether the CPU itself can work
at such a low voltage. And the operating limits for the CPU is
documented to be 1V - 1.4V. Anything else is either over or
underclocking, which might or might not work on individual SoCs. So
it's not something that we're going to support.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Mon, Aug 03, 2015 at 02:22:13PM +1000, Julian Calaby wrote:
> >> Is the code that uses this smart enough to sensibly switch between two
> >> operating points with the same frequency and different voltages? If
> >> so, maybe just add a 144MHz @ 1.0v operating point?
> >
> > You could try. Though I really don't see much to gain here.
>
> From what I recall, lower frequency = less power usage, though my
> experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing
> a lot of details. This is the sort of thing that requires thorough
> testing on a dev board.
Not on *a* dev board. On virtually all the A20 SoCs ever produced. If
you have a setting that works better for *your* SoC, fine, patch your
DT, but that's not going to be a default if it's outside of the SoC
operating range.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote:
> Hi again,
>
> Julian Calaby schrieb am 03.08.2015 06:22:
> > My only real objection here is are there boards that can go down to
> > 0.9v and if so, won't this change make them less power efficient in
> > the almost-idle case? And are those power savings enough to justify
> > not accepting this patch?
>
> It will probably make those boards less power efficient, yes. On the
> other hand, boards that have their CPU regulator set to min. 1.0V might
> also draw more power because the lowest frequency is not available,
> even though the savings due to frequency are likely to be lower than
> the savings due to voltage.
Guys, isn't this whole discussion a bit moot? We're not doing any kind
of power management but cpufreq, so maybe there's a lot more to do
before we actually can have these kind of arguments?
Plus this OPP has never been used anyway, so this patch is not going
to increase the power consumption either.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Hi Maxime,
On Mon, Aug 3, 2015 at 7:34 PM, Maxime Ripard
<[email protected]> wrote:
> On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote:
>> Hi again,
>>
>> Julian Calaby schrieb am 03.08.2015 06:22:
>> > My only real objection here is are there boards that can go down to
>> > 0.9v and if so, won't this change make them less power efficient in
>> > the almost-idle case? And are those power savings enough to justify
>> > not accepting this patch?
>>
>> It will probably make those boards less power efficient, yes. On the
>> other hand, boards that have their CPU regulator set to min. 1.0V might
>> also draw more power because the lowest frequency is not available,
>> even though the savings due to frequency are likely to be lower than
>> the savings due to voltage.
>
> Guys, isn't this whole discussion a bit moot? We're not doing any kind
> of power management but cpufreq, so maybe there's a lot more to do
> before we actually can have these kind of arguments?
>
> Plus this OPP has never been used anyway, so this patch is not going
> to increase the power consumption either.
Oh, I didn't know that. Therefore I withdraw my objections, patch away!
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
Hi Maxime,
Maxime Ripard schrieb am 03.08.2015 11:13:
> On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote:
>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20
>> boards
>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
>> voltage for the lowest operating point to 1.0V so all boards can actually use
>> it.
>
> This is not a property of a board, but is the actual limit documented
> by Allwinner for the A20. Some individual SoCs might have wider
> tolerances, but that's not a property of a board, it's really a
> property of a single SoC, and we cannot make any assumption on the
> board.
Thanks for the clarification. That was a misunderstanding on my side. I can
update the commit message in a second version of the patch, but the actual
code change can be kept as is then, I guess.
> (and please make sure to run checkpatch before sending your patches)
Sorry about that. Will do when I post a second version of the patch.
Thanks,
Timo
Hi Maxime,
Maxime Ripard schrieb am 03.08.2015 11:34:
> On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote:
>> Julian Calaby schrieb am 03.08.2015 06:22:
>> > My only real objection here is are there boards that can go down to
>> > 0.9v and if so, won't this change make them less power efficient in
>> > the almost-idle case? And are those power savings enough to justify
>> > not accepting this patch?
>>
>> It will probably make those boards less power efficient, yes. On the
>> other hand, boards that have their CPU regulator set to min. 1.0V might
>> also draw more power because the lowest frequency is not available,
>> even though the savings due to frequency are likely to be lower than
>> the savings due to voltage.
>
> Guys, isn't this whole discussion a bit moot? We're not doing any kind
> of power management but cpufreq, so maybe there's a lot more to do
> before we actually can have these kind of arguments?
>
> Plus this OPP has never been used anyway, so this patch is not going
> to increase the power consumption either.
You are right. When I wrote that, I was under the impression that the
Olinuxino Lime 2 board at least used this setting since it has has a cpu
regulator defined to go as low as 0.7V. But now I checked again and see
the regulator is not referenced in the cpu node, so I guess cpufreq
doesn't use it. So, this discussion was really hypothetical and more
importantly, as you mentioned, it's an out-of-spec opp that shouldn't
be supported anyway.
Thanks,
Timo