UART RX wakeup from sleep not working
Hi Paul,
Thanks again for all of the help.
Quoted 5 lines
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 ;-)
Quoted 10 lines
Quoted 1 line
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.
Quoted 1 line
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
Quoted 2 lines
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
Hi Rick
Quoted 9 lines · Rick Bronson
Quoted 2 lines
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)
Quoted 3 lines
Quoted 1 line
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:
Quoted 1 line
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(-)
Quoted 7 lines
I'm still not getting an interrupt but I decided to shift my focus
and I found that this changehttp://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...
Quoted 1 line
Thanks again for the help.
You're welcome. Good luck,
- Paul