On Tue, Sep 23, 2014 at 11:37 PM, Tony Lindgren <t...@atomide.com> wrote:
> * Ran Shalit <ransha...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to