Frequency scaling for the Kobo AuraHD, Glo.

[fastrobot]

Hi!

I'm trying to understand how the frequency scaling works under linux for the KOBO processors, eg: freescale imx507/508.

I've figured out that there are two drivers, a CPUFREQ driver and a DVFS driver.
The cpufreq driver interface is located at /sys/devices/system/cpu/cpu0/cpufreq
And I was able to list the available frequencies by catting the stats/time_in_state file.

/sys/devices/system/cpu/cpu0/cpufreq # cat stats/time_in_state 
166666 5481223
500000 1594
1000000 3035

There are three read-writable files in the cpufreq directory; scaling_max_freq, scaling_min_freq, and scaling_setspeed.

I can change the processor speed to any of the three listed, 166.666MHz, 500MHz, and 1GHz ; eg: echo 500000 > scaling_setspeed ; but I found I can't change the minimum and maximum frequencies allowed.

#echo 100000 > scaling_min_freq
#cat scaling_min_freq
 166666

Is this a hardware limitation, or does any one know why changing those values are locked out?

Even the lowest predefined frequency of 166.666MHz kills the KOBO battery in a matter of hours.
So, either I need to get the Kobo to slow down, or I need to put it into suspend to ram state with an ability to wake up after a second or so. I know that the /dev/ntx_io driver can talk to the coprocessors (TI MSP430 microcontrollers), one of which does the frontlight, and the other which is a realtime clock capable of waking the ARM processor from suspend; but I'm not sure if that will continue to allow the touch screen to run or not --but supposedly (according to freescale) the ARM chip is capable of running at either a few kHz or 24MHz which is very, very low power while still running peripherals at full speed.

So, I'm wondering if it can be achieved through the DVFS interface:

If I enable DVFS, which is supposed to be able to slow the system down more -- that immediately disables the already tested CPUFREQ switching.

eg:

# cd /sys/devices/platform/mxc_dvfs_core.0/
# echo 1 > enable
# cat enable
DVFS is enabled

But, the documentation I'm reading; mx50_linux.book, shows no examples of how to change the frequency once DVFS is enabled, but references another document MCIMX50 multimedia Applications Processor Reference Manual (MCIMX50RM).

But when I search for the applications reference manual on freescale, I get only a consumer reference manual which does not appear to have any relevant information mentioned in the table of contents.

Does anyone know how to get DVFS operational ?

[Lucas Malor]

From this link:
http://cache.freescale.com/files/32b...ote/AN4509.pdf

it seems you have to disable DVFS if you want to manually set frequency.

Can I ask you why you want to do this? Kobo battery seems to last for a very long time.

[fastrobot]

Originally Posted by Lucas Malor

From this link:
http://cache.freescale.com/files/32b...ote/AN4509.pdf

it seems you have to disable DVFS if you want to manually set frequency.

Can I ask you why you want to do this? Kobo battery seems to last for a very long time.

Hi Lucas.

Yes, at least to manually set it with the frequency switching API I already referenced ; but there is supposed to be a separate way to do it with DVFS enabled. I don't care if it's automatic or not, but there is supposed to be some kind of table that can be set up describing the frequencies and voltages which the Kobo is allowed to run at. I found the references in freescale's documentation, but they didn't show an example of how it is done. Thanks for the link, I'll look it over.

I agree, The battery lasts a long time -- but that's with the e-reader, nickel, software running because the battery life is much longer when doing e-book reading -- than when running some of the linux apps. I have been using. They seem to kill the battery in under two days, best case. ( Part of the problem, though, might be that I didn't unload the USB device drivers and shut down the peripherals; so it might not be the clock which is the problem. ).

A big part of my motivation is simple curiosity -- but I'm also wanting to be able to extend the battery life to the maximum while running my own applications on the Kobo. For example, I might take a kobo on a trip in the outback where there's no electricity, and carrying things over long distances means I want to travel light; so I might not be able to charge it for 10 or 11 days at a time, but still want to use it for doing text editing, journaling, and programming for several hours a day (using it as a linux command line/terminal device, not as an e-reader).

According to freescale's glossies ... DVFS is supposed to be able to give a far better power savings than the CPUFREQ system allows. I know that when the core voltage of a cpu is lowered, the power drop is not just linear with frequency decrease; but is much better than that -- and DVFS can lower the core voltage substantially; so in theory, the Kobo's not utilizing the real power savings mode that Freescale built into it, and the Kobo's performance might be capable of being made much better. ( Maybe not, too... depending on how much power the touch-screen draws. It could all be a moot point. )

Some arm processors can apparently operate as low as a few 10's of kHz -- which should allow it to operate well over a month on a single battery charge even if operating continuously and never sleeping, especially if if Linux is recompiled to run tick-less and the processor can completely halt between keystrokes, or screen touches and only draw battery when touched or updating the screen.

A processor running 166MHz is way overkill for the kinds of tasks I'm doing. But that's what the Kobo is doing.

I used to do text editing on a 12MHz 80286 processor, quite happily. So, I know that if the kobo could run 10x slower, it would be plenty fast at 1/10th (with memory that's probably more like 1/3 the power... but in theory it could be 1/10th) the power draw and the battery life would extend accordingly -- eg: if it wasn't running a computation intensive GUI, but just a simple terminal based word processor. ( Even in the QT compile script I got from GitHub, it's interesting to note that KOBO's programmers chose to turn off the neon graphics coprocessor. I imagine that a slow e-paper display which cant update except once in a quarter second or so, doesn't really need a hardware accelerated GPU -- and maybe it was better to simply not use it and waste extra power ? )

As a final note: I just checked the data sheet, and I know the Freescale processor has a built in 24MHz clock, and that's still 6x slower than it's running now, and should extend the battery life significantly if it could be enabled.

So, just call it extreme curiosity. What are the limits of the kobo reader....

[fastrobot]

Hm...
That's actaully a different processor manual.
I finally found the actual reference manual for the iMX50 series (iMX50RM.pdf).
I couldn't get it to download until I left clicked it, but here's two links to it -- indirect and direct; hopefully others will find this useful for understainding their Kobo's processor...

http://www.freescale.com/webapp/sps/...umentation_Tab
http://cache.freescale.com/files/32b...n&fileExt=.pdf

I also found a program by google search, devregs, which allows the superuser to read the hardware registers on their processor and view the values. It's really handy for debugging device drivers.... or messing with the IO pins on the processor...

just compile devregs.cpp, it's a self contained file, and you too can probe the chip's registers:
https://github.com/boundarydevices/imx-utils

It wasn't written specificially for the iMX50, so it gives an error message on the kobo -- but it still works correctly. There are also two data register definition files in the repository for iMX51 and iMX53 chips which I think have the same addresses as the iMX50.

They unfortunately didn't seem to have the clock control module addresses, so I had to manually enter numbers; but at least those files are handy for looking at other registers.