LKML Archive on
help / color / mirror / Atom feed
From: David Brownell <>
To: Haavard Skinnemoen <>
Cc: michael <>,, Andrew Victor <>
Subject: Re: at91sam9260 wakeup on serial port
Date: Tue, 29 Jan 2008 19:44:53 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Monday 28 January 2008, Haavard Skinnemoen wrote:
> > What will AVR32 (AP7) need to do, when it supports system sleep states?
> Not sure. The PIOs seem to require a clock in order to detect a pin
> change, so I don't think we can enter very deep sleep states if we want
> to be woken up by the USART.

Right; if no DMA is pending, then the HSB matrix clock can be idled, DRAM put
into self-refresh, and most peripherals can issue wakeups ... AP7 "Frozen"
state, very analagous to AT91 "standby" on Linux.  UARTs and GPIOs can wake.

Deeper sleep states -- "standby" with clocks running, "stop" with all
except 32K (and RTC) off, "static" with no clocks at all -- can only
wake from WAKE_N and external interrupts; and RTC except in "static".
I suspect "stop" and "static" might want to use the on-chip SRAMs so
they don't need to change DRAM timings while they fiddle with clocks.

The closest analogue to the AT91 support would map /sys/power/state:

	standby --> to AP7 "Frozen"
	mem --> to AP7 "Stop"

Except that there could be no GPIO wakeups from "mem" ... so the $SUBJECT
patch wouldn't be useful on AVR32 (just AT91), unless USARTn.RXD is wired
up to one of those special wake-capable pins (extremely board-specific).

> There's a separate WAKE_N pin that is completely asynchronous, so with
> some external logic, we can probably wake up the CPU all the way from
> Static mode if a given input state is present. But that's definitely
> "board specific" territory, and starting the oscillators take a _long_
> time on the AP7000 (especially the 32 kHz, but then again, it barely
> consumes any power, so we might as well keep it running and keep the
> RTC going as well.)

I'd think the support of any "deeper" state for "mem" sleep would not
be entirely board specific ... when the RTC alarm is set, any board
should be able to use states other than "static".  But otherwise, no
board could enter those states unless WAKE_N or an external IRQ are
doing something useful (like being hooked up to a button).

Matching those few "deep wake" events to a given device would imply
board-specific glue code.

> So on AP7000, I think we'll just need to keep clocking the USART and
> let it generate the interrupt that wakes up the rest of the system.

For "standby" sleep state, yes -- map to at most AVR32 "Frozen" state.
That'd be a good first step for PM support.

- Dave

  parent reply	other threads:[~2008-01-30  3:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28 11:15 michael
2008-01-28 13:56 ` Haavard Skinnemoen
2008-01-28 18:21   ` David Brownell
2008-01-28 18:44     ` trimarchi
2008-01-28 18:51     ` Haavard Skinnemoen
2008-01-30  0:37       ` michael
2008-01-30  3:44       ` David Brownell [this message]
2008-01-30 11:47         ` Haavard Skinnemoen
2008-01-30 18:56           ` David Brownell
2008-01-30 20:34             ` Haavard Skinnemoen

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: at91sam9260 wakeup on serial port' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).