From: Tony Lindgren <tony@atomide.com>
To: Ran Shalit <ranshalit@gmail.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: ideas about idle loop and power management
Date: Tue, 23 Sep 2014 13:37:23 -0700 [thread overview]
Message-ID: <20140923203722.GB3122@atomide.com> (raw)
In-Reply-To: <CAJ2oMhKRSo76NEppiR6oqJXeuwrN=Um2azKCNGgP3PbuH_T3PA@mail.gmail.com>
* 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
next prev parent reply other threads:[~2014-09-23 20:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 19:23 ideas about idle loop and power management Ran Shalit
2014-09-23 20:37 ` Tony Lindgren [this message]
2014-09-24 5:19 ` Ran Shalit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140923203722.GB3122@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap@vger.kernel.org \
--cc=ranshalit@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox