All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.