javier Martin <javier.martin@xxxxxxxxxxxxxxxxx> writes: > I am trying to enable cpuidle and cpufreq support in latest stable > kernel (3.0.4) in the Beagleboard xM. OMAP CPUfreq driver is still not in mailine. I plan to rectify that (finally) for v3.2. In the mean time, feel free to try the pm-wip/cpufreq branch from my linux-omap-pm tree[1] (currently based on v3.0-rc3) > The default governor I've selected in the kernel menu is "powersave". > However, when I execute powertop 1.12 (downloaded from Angstrom 2010.x > repository through opkg) I get the following: > > > Cn Avg residency P-states (frequencies) > C0 (cpu running) ( 0.4%) > C0 16.7ms (99.6%) > C1 0.0ms ( 0.0%) > C2 0.0ms ( 0.0%) > C3 0.0ms ( 0.0%) > C4 0.0ms ( 0.0%) > C5 0.0ms ( 0.0%) > C6 0.0ms ( 0.0%) > > So, the CPU always stays in C0 status and P-states are not shown. P-states are not shown because there is no CPUfreq driver, so no P-states available, and of course the choice of CPUfreq governor doesn't matter. CPU is staying in C0 probably because UARTs are not being idled, so SoC cannot hit deeper idle states. Try the following at the command line to to enable UART idle timeouts, so the SoC can attempt idle after the timeout period # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout After 5 seconds of inactivity on the UARTs, you should see the SoC hitting deeper C-states. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
