On 5 January 2014 23:00, Siarhei Siamashka <[email protected]> wrote: > On Wed, 1 Jan 2014 20:03:35 -0800 (PST) > Patrick Wood <[email protected]> wrote: > >> On Wednesday, January 1, 2014 5:54:20 PM UTC-5, Siarhei Siamashka wrote: >> > I myself still see no good reason for using any governor other than >> > "performance" when running with a wall connected power plug. Poor >> > default cpufreq behaviour is a major performance pitfall for >> > inexperienced users and it totally kills desktop responsiveness. >> > >> > We may introduce a new customized cpufreq governor and set it by >> > default. The users can always change the cpufreq settings to whatever >> > they want. >> > >> > Moreover, as a temporary solution, I would probably even advocate >> > setting the "performance" cpufreq governor for linux-sunxi kernels >> > by default (for the linux defconfigs). Do we have many tablet users, >> > who are running linux instead of android and also need good battery >> > life (have no usb ports or chargers nearby for providing power)? >> >> I believe that a minimum setting of 408MHZ with the "interactive" governor >> works quite well. This governor raises the CPU clock much faster than >> ondemand, and 408MHz seems to be a spot where the SoC will power down a lot >> of blocks when idle. > > Is this just a speculation? Or some kind of research has been done? > > What we know for sure is that the current cpufreq defaults ("ondemand" > for sun4i and "fantasy" for sun7i) are responsible for really poor > performance. Note that sun4i and sun7i are defaulting to different > governors for some unknown reason. > > And there is one more source of inconsistency. The range of allowed CPU > frequencies and their voltages can be configured in fex files for > each device/board individually. For example, compare cubieboard2 and > cubietruck fex files: > > https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubieboard2.fex#L957 > > https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubietruck.fex#L944 > The minimum CPU clock frequency for the cubieboard2 is set to 400MHz. > And for cubietruck the lowest limit is 60MHz. This means that the > "fantasy" governor on cubieboard2 will run the idle system at 384MHz, > but on cubietruck that would be supposedly 60MHz. Funny, isn't it? > > This is a big freaking mess. > >> Also, perhaps the minimum setting should be 1GHz at boot time and not >> dropped until the UI is up and running, since this affects the overall boot >> speed by quite a bit, and that's the first impression any user gets of a >> distro -- how long it takes to get my login prompt or splash screen. > > Does it mean that currently the "ondemand" / "fantasy" / "interactive" > governors are also responsible poor boot time? That's one more reason > to do something about this. > > I tried to look into this stuff and run some tests on cubieboard2 and > cubietruck using the current stage/linux-sunxi-3.4 branch. > > As Michal Suchanek mentioned earlier in this thread, we have AXP209 > power management chip. And it has some interesting registers (REG 00H > and REG 01H): > http://linux-sunxi.org/AXP209#REG_00H:_Power_input_status > The values of these registers are exposed to the userspace via > /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs > AXP209 also has IRQs for the notifications about plugging/removing > different power sources: ACIN (power plug), VBUS (miniusb) and LiPo > battery. So looks like the hardware mostly provides all that we need. > > Now the results of some tests are below. They were done with screen > blanked because this saves ~20 mA of current. I also have a LiPo > battery, earlier bought from OLIMEX: > https://www.olimex.com/Products/Power/BATTERY-LIPO6600mAh/ > The connector of this LiPo battery is mechanically incompatible > with cubietruck, but I still got it temporarily connected just > for the sake of this experiment using jumper wires. Now the results: > > === 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. The way to go is probably to use performance governor and STR when battery powered. It should work on sun7i iirc. I wonder if there is some way to power down one of the cores and what savings that could give. Thanks Michal -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
