On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
quoted text
> On Tue, 29 Jan 2008 19:44:53 -0800
> David Brownell <david-b@pacbell.net> 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.

If the UART isn't open, its DMA should be inactive.  :)

Also, after suspend() it should normally be inactive.
(That latter is somewhat platform-specific.)


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

Wouldn't that just be a variant of "Frozen"?  The clock API should
be fully capable of disabling unused clocks, PLLs, and oscillators
when the platform supports it.  It's common for lots of clocks to be
disable even in non-suspended system states.


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

The sysfs wakeup attributes are the runtiime config mechanism for all
events associated with a single device.

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