Re: UART RX wakeup from sleep not working

Re: UART RX wakeup from sleep not working

[Rick Bronson]

Hi Paul,

  Thanks much for the help.

> If the OMAP is in full-chip retention, the UART's asynchronous wakeup
> mechanism won't work, which appears to be what you're trying to use.
> That will only work when PER is fully powered, as far as I know.  You'll
> need to use the IO chain wakeup feature instead.  My guess is that you
> need to make sure that your UART input pads have the WAKEUPENABLE bits set
> in the CONTROL_PADCONF registers.  I think that should do it.

  I put debug code in and the IO chain wakeup feature is enabled and
the WAKEUPENABLE bit is set on the pad in question.  With the IO chain
feature what's the wakeup mechanism?  Does it generate an interrupt?

  I've updated my assumptions:

Assumptions (using UART3)

1.  OMAP3730 is in sleep mode via
    echo 1 > /mnt/dbg/pm_debug/sleep_while_idle
2.  The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1.
3.  The UARTi.IER_REG[4] SLEEP_MODE bit to 1
4.  The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1
5.  The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1
6.  The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1
7.  The PRCM.PM_WKEN_WKUP EN_IO_CHAIN bit is set to 1 via omap3_enable_io_chain()
8.  The PRCM.PM_WKEN_WKUP[8] EN_IO bit is set to 1 via omap3_enable_io_chain()
9.  CONTROL_PADCONF_UART3_RTS_SD[14] WAKEUPENABLE0 is set to 1
10. CONTROL_PADCONF_UART3_RTS_SD INPUTENABLE is set to 1

  Thanks again,

 Rick

> Hello Rick,
> 
> On Wed, 1 Dec 2010, Rick Bronson wrote:
> 
> >   I'm having trouble getting the UART wakeup from sleep via activity
> > on the RX pin working.
> >
> > --------------------------------------------------------
> > Assumptions (using UART3)
> >
> > 1. Using Arago Linux 2.6.32
> > 2. OMAP3730 is in sleep mode via
> >    echo 1 > /mnt/dbg/pm_debug/sleep_while_idle
> > 3. The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1.
> > 4. The UARTi.IER_REG[4] SLEEP_MODE bit to 1
> > 5. The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1
> > 6. The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1
> > 7. The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1
> >
> > Expectations
> >
> >   When a character arrives on the RX pin of UART3 when in sleep mode,
> > the OMAP3730 exits sleep mode immediately via a RX_CTS_DSR_WAKE_UP
> > interrupt.
> >
> > Problem
> >
> >   The interrupt does happen but only after the UART clocks have been
> > enabled.  The OMAP3730 seems to exit sleep mode only when the UART
> > clocks are re-enabled via omap_uart_enable_clocks() in
> > arch/arm/mach-omap2/serial.c
> 

Re: UART RX wakeup from sleep not working

[Paul Walmsley]

Hi Rick

On Thu, 2 Dec 2010, Rick Bronson wrote:

> > If the OMAP is in full-chip retention, the UART's asynchronous wakeup
> > mechanism won't work, which appears to be what you're trying to use.
> > That will only work when PER is fully powered, as far as I know.  You'll
> > need to use the IO chain wakeup feature instead.  My guess is that you
> > need to make sure that your UART input pads have the WAKEUPENABLE bits set
> > in the CONTROL_PADCONF registers.  I think that should do it.
> 
>   I put debug code in and the IO chain wakeup feature is enabled and
> the WAKEUPENABLE bit is set on the pad in question.  With the IO chain
> feature what's the wakeup mechanism? 

It's described in the 34xx TRM sections 4.11.2 "Device Off-Mode 
Configuration" and 4.11.3 "CORE Power Domain Off-Mode Sequences".  All the 
references to off-mode just confuse things, since AFAIK, this wakeup 
mechanism also applies to the device in full-chip retention (see also the 
'NOTE:' portion of section 4.8.4 "Device Wake-Up Events").

 > Does it generate an interrupt?

An IO chain/ring wakeup event ultimately should generate a PRCM interrupt, 
which should wind up in mach-omap2/pm34xx.c:prcm_interrupt_handler().  
You might want to put some debugging in prcm_clear_mod_irqs(), first to 
see if that function is getting called, and second, to output the state of 
the WKST and GRPSEL registers.

>   I've updated my assumptions:
> 
> Assumptions (using UART3)
> 
> 1.  OMAP3730 is in sleep mode via
>     echo 1 > /mnt/dbg/pm_debug/sleep_while_idle
> 2.  The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1.
> 3.  The UARTi.IER_REG[4] SLEEP_MODE bit to 1
> 4.  The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1
> 5.  The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1
> 6.  The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1
> 7.  The PRCM.PM_WKEN_WKUP EN_IO_CHAIN bit is set to 1 via omap3_enable_io_chain()
> 8.  The PRCM.PM_WKEN_WKUP[8] EN_IO bit is set to 1 via omap3_enable_io_chain()
> 9.  CONTROL_PADCONF_UART3_RTS_SD[14] WAKEUPENABLE0 is set to 1
> 10. CONTROL_PADCONF_UART3_RTS_SD INPUTENABLE is set to 1

This may be a stupid question, but are you using serial flow control?  If 
not, enabling wakeup on the RTS line isn't going to help.

Just out of curiosity, which kernel are you using?


- Paul

Re: UART RX wakeup from sleep not working

[Paul Walmsley]

By the way, if you're using a really recent kernel, you may want to see if 
sending a few breaks down the line wakes it up:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39735.html
  
Based on your problem description, I doubt this will help, but it's worth 
a try.


- Paul

Re: UART RX wakeup from sleep not working

[Rick Bronson]

Hi Paul,

  Thanks again for all of the help.

> It's described in the 34xx TRM sections 4.11.2 "Device Off-Mode
> Configuration" and 4.11.3 "CORE Power Domain Off-Mode Sequences".  All the
> references to off-mode just confuse things, since AFAIK, this wakeup
> mechanism also applies to the device in full-chip retention (see also the
> 'NOTE:' portion of section 4.8.4 "Device Wake-Up Events").

  Yes, I had read that in sprugn4c.pdf, hopefully it's the same as the
34xx pdf.  My head is still spinning from trying to understand if I'll
get an interrupt or not ;-)

>  > Does it generate an interrupt?
> 
> An IO chain/ring wakeup event ultimately should generate a PRCM interrupt,
> which should wind up in mach-omap2/pm34xx.c:prcm_interrupt_handler().
> You might want to put some debugging in prcm_clear_mod_irqs(), first to
> see if that function is getting called, and second, to output the state of
> the WKST and GRPSEL registers.
> 
> This may be a stupid question, but are you using serial flow control?  If
> not, enabling wakeup on the RTS line isn't going to help.

  Not a stupid question at all.  We are very pin constrained so we
only have RX and TX, so no modem lines at all.  I was hoping to get
the wakeup mechanism to be fired off of in incoming "polling"
character on the RX line.  The first character gets lost but wakes us
up, then we respond to the next polling character to let the other
side know we're awake, then he sends the packet.

> Just out of curiosity, which kernel are you using?

  It's the Arago (we need the low power management stuff),
Linux omap 2.6.32 #32 Fri Dec 3 10:49:55 PST 2010 armv7l GNU/Linux

> By the way, if you're using a really recent kernel, you may want to see if
> sending a few breaks down the line wakes it up:

  Not very recent, see above.

  I'm still not getting an interrupt but I decided to shift my focus
and I found that this change

http://www.efn.org/~rick/pub/serial.patch

  seems to really improve the variablity in serial timeout when it's
taken low.  I found that when you take DEFAULT_TIMEOUT lower things
start acting very erratic.  We'd like to go back to sleep really
quickly after a packet is received, like 10ms would be nice, 1ms would
be better.

  Thanks again for the help.

  Rick

Re: UART RX wakeup from sleep not working

[Paul Walmsley]

Hi Rick

On Fri, 3 Dec 2010, Rick Bronson wrote:

> > This may be a stupid question, but are you using serial flow control?  If
> > not, enabling wakeup on the RTS line isn't going to help.
> 
>   Not a stupid question at all.  We are very pin constrained so we
> only have RX and TX, so no modem lines at all.  I was hoping to get
> the wakeup mechanism to be fired off of in incoming "polling"
> character on the RX line.  The first character gets lost but wakes us
> up, then we respond to the next polling character to let the other
> side know we're awake, then he sends the packet.

So then setting WAKEUPENABLE on the RTS line won't help, since you're not 
using that line as an input line.  (According to Figure 17-1 "UART Module" 
that's a transmit line anyway, so the appropriate flow control line would 
need to be CTS for incoming data, not RTS.  But you're not using flow 
control so that won't help either.)

You might want to try setting WAKEUPENABLE on the pad that is muxed to 
your RX line, which is where you're receiving bits.  Note that there are 
multiple mux pad targets for that signal, so you need to know which pad 
your board is actually using to figure out what register to write to.

(By the way, all the documentation references in this and the previous 
E-mails are to the 34xx public TRM rev ZJ, downloadable from the TI web 
site, should also apply to OMAP3730, maybe with some padconf differences)

> > Just out of curiosity, which kernel are you using?
> 
>   It's the Arago (we need the low power management stuff),

Am not familiar with the Arago kernel at all, but full chip retention-idle 
-- which appears to be what you're trying to use -- should work on 
mainline Linux 2.6.36.  I wouldn't try .37-rc yet, there seems to be 
something wrong with power management and the serial driver in those, at 
least on my BeagleBoard.

If you need to use the Arago kernel, you'll probably need to contact TI 
for support.  Might be worth suggesting to them that they patch the 
top-level Makefile to add an EXTRAVERSION of -arago1 or something like 
that, since this uname:

> Linux omap 2.6.32 #32 Fri Dec 3 10:49:55 PST 2010 armv7l GNU/Linux

... makes it look like it's just stock 2.6.32, when 'git diff 
v2.6.32..arago-omap3/master | diffstat' returns:

 7380 files changed, 762778 insertions(+), 406769 deletions(-)

>   I'm still not getting an interrupt but I decided to shift my focus
> and I found that this change
> 
> http://www.efn.org/~rick/pub/serial.patch
> 
>   seems to really improve the variablity in serial timeout when it's
> taken low.  

If SCR_REG.RX_CTS_WU_EN is not set, then that would indeed prevent the 
UART from waking up.  Hmm, wonder if we've got that same problem in 
mainline...

>   Thanks again for the help.

You're welcome.  Good luck,


- Paul

UART RX wakeup from sleep not working

[Rick Bronson]

Hi,

  I'm having trouble getting the UART wakeup from sleep via activity
on the RX pin working.

--------------------------------------------------------
Assumptions (using UART3)

1. Using Arago Linux 2.6.32
2. OMAP3730 is in sleep mode via
   echo 1 > /mnt/dbg/pm_debug/sleep_while_idle
3. The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1.
4. The UARTi.IER_REG[4] SLEEP_MODE bit to 1
5. The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1
6. The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1
7. The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1

Expectations

  When a character arrives on the RX pin of UART3 when in sleep mode,
the OMAP3730 exits sleep mode immediately via a RX_CTS_DSR_WAKE_UP
interrupt.

Problem

  The interrupt does happen but only after the UART clocks have been
enabled.  The OMAP3730 seems to exit sleep mode only when the UART
clocks are re-enabled via omap_uart_enable_clocks() in
arch/arm/mach-omap2/serial.c
--------------------------------------------------------

  Any help greatly appreciated.

  Rick

Re: UART RX wakeup from sleep not working

[Paul Walmsley]

Hello Rick,

On Wed, 1 Dec 2010, Rick Bronson wrote:

>   I'm having trouble getting the UART wakeup from sleep via activity
> on the RX pin working.
> 
> --------------------------------------------------------
> Assumptions (using UART3)
> 
> 1. Using Arago Linux 2.6.32
> 2. OMAP3730 is in sleep mode via
>    echo 1 > /mnt/dbg/pm_debug/sleep_while_idle
> 3. The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1.
> 4. The UARTi.IER_REG[4] SLEEP_MODE bit to 1
> 5. The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1
> 6. The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1
> 7. The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1
> 
> Expectations
> 
>   When a character arrives on the RX pin of UART3 when in sleep mode,
> the OMAP3730 exits sleep mode immediately via a RX_CTS_DSR_WAKE_UP
> interrupt.
>
> Problem
> 
>   The interrupt does happen but only after the UART clocks have been
> enabled.  The OMAP3730 seems to exit sleep mode only when the UART
> clocks are re-enabled via omap_uart_enable_clocks() in
> arch/arm/mach-omap2/serial.c

If the OMAP is in full-chip retention, the UART's asynchronous wakeup 
mechanism won't work, which appears to be what you're trying to use.  
That will only work when PER is fully powered, as far as I know.  You'll 
need to use the IO chain wakeup feature instead.  My guess is that you 
need to make sure that your UART input pads have the WAKEUPENABLE bits set 
in the CONTROL_PADCONF registers.  I think that should do it.


- Paul