Hi,
I implement a little patch (ndr just for a try) for the atmel serial
driver atmel_serial.c to wakeup the system when it is in suspend-ram state.
I reconfigure the RXD pin as a gpio in suspend function and restore it
in the resume function. It is the correct way?
Regards Michael
On Mon, 28 Jan 2008 12:15:00 +0100
michael <[email protected]> wrote:
> Hi,
> I implement a little patch (ndr just for a try) for the atmel serial
> driver atmel_serial.c to wakeup the system when it is in suspend-ram state.
> I reconfigure the RXD pin as a gpio in suspend function and restore it
> in the resume function. It is the correct way?
I'm not sure...this is rather platform-specific, so I don't think it
really belongs in the atmel_serial() driver. One solution might be to
add a function pointer to struct atmel_uart_data that the driver can
call from ->suspend() in order to let the platform code handle this as
appropriate.
Cc'ing Andrew Victor and David Brownell since they know the AT91
platform code better than me.
Haavard
On Monday 28 January 2008, Haavard Skinnemoen wrote:
> On Mon, 28 Jan 2008 12:15:00 +0100
> michael <[email protected]> wrote:
>
> > Hi,
> > I implement a little patch (ndr just for a try) for the atmel serial
> > driver atmel_serial.c to wakeup the system when it is in suspend-ram state.
> > I reconfigure the RXD pin as a gpio in suspend function and restore it
> > in the resume function. It is the correct way?
>
> I'm not sure...this is rather platform-specific, so I don't think it
> really belongs in the atmel_serial() driver. One solution might be to
> add a function pointer to struct atmel_uart_data that the driver can
> call from ->suspend() in order to let the platform code handle this as
> appropriate.
The core issue is that the system clock driving the baud rate generator
is no longer running fast enough to let the UART run. (In "standby" the
clock is still driven by the PLL, so this issue doesn't come up.) The
GPIO logic can catch the START bit though ... this technique is used on
some OMAP boards too.
Agreed that knowing exactly which pin(s) should be remuxed (UARTn.RX to
GPIO in suspend then enabling it as a wakeup irq, then reversing that
on resume; maybe UARTn.DCD should work too..), and how (as A-peripheral?
or B?) is chip-specific knowledge. Such a function pointer could work.
What will AVR32 (AP7) need to do, when it supports system sleep states?
- Dave
On Mon, 28 Jan 2008 10:21:57 -0800
David Brownell <[email protected]> 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.
But I suppose we can still disable the HSB (system) bus, all the
peripherals we don't care about, switch the remaining ones over to an
oscillator and keep that oscillator running. In order to be able to
actually respond to something happening on the serial line, we need to
keep a relatively-high-speed oscillator or PLL running anyway (32 kHz
won't do.)
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.)
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.
With the rest of the system effectively stopped, I don't think this is
very expensive power-wise, but it remains to be seen.
Haavard
Hi,
> On Monday 28 January 2008, Haavard Skinnemoen wrote:
>> On Mon, 28 Jan 2008 12:15:00 +0100
>> michael <[email protected]> wrote:
>>
>> > Hi,
>> > I implement a little patch (ndr just for a try) for the atmel serial
>> > driver atmel_serial.c to wakeup the system when it is in suspend-ram
>> state.
>> > I reconfigure the RXD pin as a gpio in suspend function and restore it
>> > in the resume function. It is the correct way?
>>
>> I'm not sure...this is rather platform-specific, so I don't think it
>> really belongs in the atmel_serial() driver. One solution might be to
>> add a function pointer to struct atmel_uart_data that the driver can
>> call from ->suspend() in order to let the platform code handle this as
>> appropriate.
>
> The core issue is that the system clock driving the baud rate generator
> is no longer running fast enough to let the UART run. (In "standby" the
> clock is still driven by the PLL, so this issue doesn't come up.) The
> GPIO logic can catch the START bit though ... this technique is used on
> some OMAP boards too.
>
> Agreed that knowing exactly which pin(s) should be remuxed (UARTn.RX to
> GPIO in suspend then enabling it as a wakeup irq, then reversing that
> on resume; maybe UARTn.DCD should work too..), and how (as A-peripheral?
> or B?) is chip-specific knowledge. Such a function pointer could work.
>
> What will AVR32 (AP7) need to do, when it supports system sleep states?
>
> - Dave
>
My code just works and I can try to implement a clean patches and submit to
the mailing list.
Michael
Hi,
> On Mon, 28 Jan 2008 10:21:57 -0800
> David Brownell <[email protected]> wrote:
>
> 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.)
>
Maybe is possible to create a generic device based on the gpio to provide
wakeup solutions on suspend-ram state to the peripherals
that registered to him
serial->register_gpio_wakeup x_driver->register_gpio_wakeup
serial->suspend x_driver
| |
| |
\------> gpio_power->suspend <-----------/
serial->resume x_driver
| |
| |
\------> gpio_power->resume <------------/
|----request_irq n1
gpio_power-----|----request_irq n2
|----request_irq n3
Create an attribute on the sysfs to add a wakeup reason to the user space.
Regards Michael
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
On Tue, 29 Jan 2008 19:44:53 -0800
David Brownell <[email protected]> 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
On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> On Tue, 29 Jan 2008 19:44:53 -0800
> David Brownell <[email protected]> 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.)
> > 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.
> 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
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