On Wed, 30 Jan 2008 10:56:12 -0800 David Brownell <[EMAIL PROTECTED]> wrote: > On Wednesday 30 January 2008, Haavard Skinnemoen wrote: > > 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.)
True, but can a closed or suspended UART wake the system? I guess it could if it's really a GPIO interrupt that triggers the wakeup :-) > > > 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. Yes, indeed. I was just pointing out that "Frozen" doesn't necessarily mean what the datasheet says -- we can disable a lot of clocks manually. > > 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. Right. I'm not all that familiar with the power management mechanisms in the kernel yet, but this thread has made a few things much clearer. Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/