ideas about idle loop and power management

ideas about idle loop and power management

[Ran Shalit]

Hello,

I have a system which is required to have 2 modes operation:
1. idle - in which devices in Soc and on board should be off.
2. active mode

Moving from idle to active on interrupt, and moving from active to
idle when there is inactivity.
After reading and re-reading about PM various mechanism, I got to
conculsion that the best and easiest way to achive this on omap
(omap3530) will be as following:
1. use cpuidle
2. find the exact place in cpuidle mechanism where we enter idle loop,
and where we exit idle loop.
3. on entering idle loop: turn off various devices on board, and
devices power domain
4. on exit idle loop: power again the devices.

I think that working such way on low machine registers will be easiest
and best instead of trying to do it using PM mechanism, which is quite
difficult to understand and do and also, I'm not sure even possible
using the existing mechanism.

I would appreciate your feedback.

Regards,
Ran

Re: ideas about idle loop and power management

[Tony Lindgren]

* Ran Shalit <ranshalit@gmail.com> [140923 12:24]:
> Hello,
> 
> I have a system which is required to have 2 modes operation:
> 1. idle - in which devices in Soc and on board should be off.
> 2. active mode

Hmm we do this already with the mainline kernel since v3.16-rc6
for device tree based systems too. Some devices will still block
deeper idle states idle like EHCI. I suggest you give v3.17-rc6
a try on a beagleboard xm (rev c preferrably)using omap2plus_defconfig.
Or omap 37xx evm. Or on n900. Or overo, but that's still pending
a .dts fix.
 
> Moving from idle to active on interrupt, and moving from active to
> idle when there is inactivity.
> After reading and re-reading about PM various mechanism, I got to
> conculsion that the best and easiest way to achive this on omap
> (omap3530) will be as following:
> 1. use cpuidle
> 2. find the exact place in cpuidle mechanism where we enter idle loop,
> and where we exit idle loop.
> 3. on entering idle loop: turn off various devices on board, and
> devices power domain

The devices are autoidle where possible with runtime PM. And then
the hardware enters deeper idle states when drivers are not
blocking.

> 4. on exit idle loop: power again the devices.
> 
> I think that working such way on low machine registers will be easiest
> and best instead of trying to do it using PM mechanism, which is quite
> difficult to understand and do and also, I'm not sure even possible
> using the existing mechanism.

Hmm but that's already working with the mainline tree :)
 
> I would appreciate your feedback.

Sounds like you just need to give it a try. I'm using the following
test script. You may need to also blank the LCD.

Regards,

Tony

#!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
        echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/ttyO*/power/ -type d 2>/dev/null)
for uart in $uarts; do
        echo enabled > $uart/wakeup 2>&1
        echo auto > $uart/control 2>&1
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode

Re: ideas about idle loop and power management

[Ran Shalit]

On Tue, Sep 23, 2014 at 11:37 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ran Shalit <ranshalit@gmail.com> [140923 12:24]:
>> Hello,
>>
>> I have a system which is required to have 2 modes operation:
>> 1. idle - in which devices in Soc and on board should be off.
>> 2. active mode
>
> Hmm we do this already with the mainline kernel since v3.16-rc6
> for device tree based systems too. Some devices will still block
> deeper idle states idle like EHCI. I suggest you give v3.17-rc6
> a try on a beagleboard xm (rev c preferrably)using omap2plus_defconfig.
> Or omap 37xx evm. Or on n900. Or overo, but that's still pending
> a .dts fix.
>
>> Moving from idle to active on interrupt, and moving from active to
>> idle when there is inactivity.
>> After reading and re-reading about PM various mechanism, I got to
>> conculsion that the best and easiest way to achive this on omap
>> (omap3530) will be as following:
>> 1. use cpuidle
>> 2. find the exact place in cpuidle mechanism where we enter idle loop,
>> and where we exit idle loop.
>> 3. on entering idle loop: turn off various devices on board, and
>> devices power domain
>
> The devices are autoidle where possible with runtime PM. And then
> the hardware enters deeper idle states when drivers are not
> blocking.
>
> Sounds like you just need to give it a try. I'm using the following
> test script. You may need to also blank the LCD.
>

Hi Tony,

I actually want something different than runtime PM.
I want that the whenever system enters idle loop it will force suspend
of the devices, and not that each device will decide on its own.
Aside from that, from delving into code it seems that tailoring new
device runtime suspend/resume by building registration of runtime_pm
callbacks is much more complex than simply disabling power domain of
all relevant devices whenever entering idle mode.

Thanks,
Ran