Re: cpuidle status in mainline for Beagleboard xM

[Kevin Hilman <khilman@ti.com>]

javier Martin <javier.martin@vista-silicon.com> writes:

> On 2 September 2011 19:14, Kevin Hilman <khilman@ti.com> wrote:
>> javier Martin <javier.martin@vista-silicon.com> writes:
>>
>>> On 2 September 2011 08:05, Jarkko Nikula <jarkko.nikula@bitmer.com> wrote:
>>>> Other usual things to check that display is off (echo 1 >
>>>> /sys/class/graphics/fb0/blank) and no cable to musb/otg port.
>>>>
>>>> Haven't tried myself with recent kernel but does EHCI and hub on XM let to
>>>> idle cpu at all? At least on one board having on-board hub I had to disable
>>>> or unload ehci module in order to hit the retention.
>>>>
>>>
>>> I've checked that too and I've even disabled USB support in the kernel
>>> just to be sure. But still nothing:
>>>
>>> root@beagleboard:~# powertop -d -t 100
>>> PowerTOP 1.12   (C) 2007, 2008 Intel Corporation
>>>
>>> Collecting data for 100 seconds
>>>
>>>
>>> Cn                Avg residency
>>> C0 (cpu running)        ( 0.0%)
>>> C0               58.5ms (100.0%)
>>> 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%)
>>>
>>> Even when CPU has been idle 100% of the time it doesn't hit any state
>>> deeper than C0.
>>
>> Did you allow the UARTs to idle:
>
> Yes I did:
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>
> [   65.853820] omap_device: omap_uart.3: new worst case activate
> latency 0: 30517
> [   65.944366] omap_device: omap_uart.2: new worst case deactivate
> latency 0: 30517
>
>
>> # 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
>>
>> I just tested this using today's linux-omap master branch (+ merged
>> v3.1-rc4 which includes a fix for a bootup problem.)
>>
>> I booted my Beagle XM with a busybox rootfs on MMC and it worked fine
>> for me.
>>
>> I don't have powertop on the rootfs, but I manually dumped the sysfs
>> files that powertop reads, so I can see the state times.
>>
>> After allowing the UARTs to idle, I see:
>>
>> # cd /sys/devices/system/cpu/cpu0
>> /sys/devices/system/cpu/cpu0/cpuidle # cat state?/time
>> 43531831
>> 8997
>> 157215
>> 0
>> 3467925
>> 0
>> 0
>
> OK, I've just tried with the same kernel as you did (linux-omap master
> +  v3.1-rc4 merge) and I can't get any other state than 0:

> Just one question. Do you access the shell through UART?

Yes.

> What I do is waiting for 20 seconds to allow the UART to suspend and
> then see state reports.

Then I suspect your userspace is keeping the system active.

Can you try to just boot a minimal userspace (e.g. append init=/bin/sh
to your kernel command line, or use a basic busybox rootfs.)

Keivn
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html