Re: at91sam9260 wakeup on serial port

[Haavard Skinnemoen]

On Tue, 29 Jan 2008 19:44:53 -0800
David Brownell <david-b@xxxxxxxxxxx> wrote:

> 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.

Yeah, although the nasty thing about UARTs is that you never know when
DMA really is idle.

> 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.

I think we can ignore "static". The power savings are minimal compared
to "stop", and you lose the RTC. Might as well power down the whole
chip and save even more power.

But yeah, I imagine we need to use some on-chip SRAM (or some locked
parts of the caches) when transitioning the SDRAM into and out of
self-refresh mode, and when changing timings.

> The closest analogue to the AT91 support would map /sys/power/state:
> 
> 	standby --> to AP7 "Frozen"
> 	mem --> to AP7 "Stop"

Yes, that looks reasonable. We can also do something in between by
stopping most peripherals and busses. For example, keep one peripheral
bus and one USART running from OSC0 with everything else stopped.

> 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).

Right. But we could do it in one of those "something in between" states.

With all the other stuff that needs to be done when switching power
modes (running suspend() hooks, etc.) I don't think we need to limit
ourselves to what the "sleep" instruction can do, although the
predefined power states may serve as a nice starting point.

> > 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.

I think we need some chip- or family-specific sleep code that knows how
to enter a given power state. But the specifics about how to wake the
system up must necessarily be board-specific (or even run-time
configurable.)

> > 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.

Right. I guess it's about time we got some proper power management
implemented on avr32...I'll see if I can get started on that soon, but
you're giving me a hard time about my DMA patches :-P

Haavard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/