On Sun, 5 Jan 2014 23:25:29 +0100
Michal Suchanek <hramr...@gmail.com> wrote:
> On 5 January 2014 23:00, Siarhei Siamashka <siarhei.siamas...@gmail.com>
> wrote:
> > === cubietruck ===
> >
> > # echo 1 > /sys/devices/platform/disp/graphics/fb0/blank
> >
> > # cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
> > only power adapter : REG[0x0]=0xc1,REG[0x1]=0x10
> > power adapter + miniusb : REG[0x0]=0xf9,REG[0x1]=0x10
> > only miniusb : REG[0x0]=0x3d,REG[0x1]=0x70
> > miniusb + lipo battery : REG[0x0]=0x3d,REG[0x1]=0x70
> > power adapter + lipo battery : REG[0x0]=0xc5,REG[0x1]=0x70
> > only lipo battery : REG[0x0]=0x1,REG[0x1]=0x30
> >
> > Note: "only miniusb" and "miniusb + lipo battery" really have the
> > same AXP20 register values, that's not a typo.
> >
> > Power consumption measurements with a multimeter on the 5V barrel
> > power plug:
> >
> > idle at 60MHz : ~271 mA
> > idle at 912MHz : ~287 mA
> >
> > Note: while cpufreq reports 60MHz clock frequency, the CPU really
> > runs faster than this and the benchmarks indicate that it
> > is more likely to be something around ~240MHz.
> >
> > === cubieboard2 ===
> >
> > # echo 1 > /sys/devices/platform/disp/graphics/fb0/blank
> > # echo 60000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
> > # echo 60000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
> >
> > # cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
> > REG[0x0]=0xc1,REG[0x1]=0x10
> >
> > Note: The values of AXP20 registers are always the same (no matter
> > whether only a miniusb cable is plugged, or a barrel power plug,
> > or both of them).
> >
> > Power consumption measurements with a multimeter on the 5V barrel
> > power plug:
> >
> > idle at 60MHz : ~219 mA
> > idle at 912MHz : ~238 mA
> >
> > Note: the 60MHz CPU clock speed is fake here too (just like for
> > the cubietruck).
>
> Given these stunning power savings I guess playing with cpufreq is
> really quite pointless on A20.
I'm more worried that there seems to be a bug in sun7i cpufreq. It
thinks that the CPU clock frequency is 60MHz, but in fact the
multipliers are likely wrong because the actual performance of
the CPU is higher (~240MHz). Still the voltages are taken from
the table and applied.
One experiment was to force the use of the cpufreq table hardcoded
in the kernel sources instead of taking it from fex by changing
'use_default_table' variable:
https://github.com/linux-sunxi/linux-sunxi/blob/77a43694fca9db61/arch/arm/mach-sun7i/cpu-freq/cpu-freq.c#L84
If I do this, the voltage for 60MHz clock speed would be 0.9V
instead of 1.05V as hardcoded in the cubietruck fex:
https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubietruck.fex#L961
And after this change, any attempt to use 0.9V with the clock
frequency which happens to be actually used instead of 60MHz
results in a deadlock. The 0.9V is apparently not enough.
I'm also wonder whether 1.05V used by cubietruck when it attempts
to reduce the clock frequency to 60MHz (and uses something else
instead) is still safe. It might be a potential reliability issue.
It would be interesting to test some other kernels (from android?),
because this might be a bug only affecting sunxi-3.4.
> The way to go is probably to use performance governor and STR when
> battery powered.
STR as Suspend-to-RAM? That would be very interesting indeed.
> It should work on sun7i iirc.
With AR100 chip? Or also without it?
> I wonder if there is some way to power down one of the cores and what
> savings that could give.
Yes, an interesting idea indeed.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
