| Message ID | 1438543386-7253-1-git-send-email-public_timo.s@silentcreek.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Timo, On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson <public_timo.s@silentcreek.de> 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,
Hi, On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby <julian.calaby@gmail.com> wrote: > Hi Timo, > > On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson > <public_timo.s@silentcreek.de> 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 <wens@csie.org> wrote: > Hi, > > On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby <julian.calaby@gmail.com> wrote: >> Hi Timo, >> >> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson >> <public_timo.s@silentcreek.de> 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,
On Mon, Aug 3, 2015 at 12:22 PM, Julian Calaby <julian.calaby@gmail.com> wrote: > Hi Chen-Yu, > > On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai <wens@csie.org> wrote: >> Hi, >> >> On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby <julian.calaby@gmail.com> wrote: >>> Hi Timo, >>> >>> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson >>> <public_timo.s@silentcreek.de> 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
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 > <public_timo.s@silentcreek.de> 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
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
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
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
Hi Maxime, On Mon, Aug 3, 2015 at 7:34 PM, Maxime Ripard <maxime.ripard@free-electrons.com> 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,
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
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>;
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 <public_timo.s@silentcreek.de> --- arch/arm/boot/dts/sun7i-a20.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)