at91sam9260 wakeup on serial port - Kernel

This is a discussion on at91sam9260 wakeup on serial port - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: at91sam9260 wakeup on serial port

  1. at91sam9260 wakeup on serial port

    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

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

  2. Re: at91sam9260 wakeup on serial port

    On Mon, 28 Jan 2008 12:15:00 +0100
    michael 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
    --
    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/

  3. Re: at91sam9260 wakeup on serial port

    On Monday 28 January 2008, Haavard Skinnemoen wrote:
    > On Mon, 28 Jan 2008 12:15:00 +0100
    > michael 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
    --
    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/

  4. Re: at91sam9260 wakeup on serial port

    On Mon, 28 Jan 2008 10:21:57 -0800
    David Brownell 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
    --
    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/

  5. Re: at91sam9260 wakeup on serial port

    Hi,
    > On Monday 28 January 2008, Haavard Skinnemoen wrote:
    >> On Mon, 28 Jan 2008 12:15:00 +0100
    >> michael 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

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

  6. Re: at91sam9260 wakeup on serial port

    Hi,
    > On Mon, 28 Jan 2008 10:21:57 -0800
    > David Brownell 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

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

  7. Re: at91sam9260 wakeup on serial port

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

  8. Re: at91sam9260 wakeup on serial port

    On Tue, 29 Jan 2008 19:44:53 -0800
    David Brownell 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: at91sam9260 wakeup on serial port

    On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
    > On Tue, 29 Jan 2008 19:44:53 -0800
    > David Brownell 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
    --
    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/

  10. Re: at91sam9260 wakeup on serial port

    On Wed, 30 Jan 2008 10:56:12 -0800
    David Brownell 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 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/

+ Reply to Thread