On Sat, 4 Feb 2012 00:23:09 +0000 "Woodruff, Richard" <r-woodruff2@xxxxxx> wrote: > > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of NeilBrown > > > > Not sure if it's the same problem but with 3530 on 3.2 with > > > sleep_timeout set, I usually get first char dropped (as expected) but > > > sometimes I get corrupted char instead too. Corrupt char seems to > > > almost always happen if I set cpufreq to powersave, on performace it's > > > almost always ok, so maybe it's some timing problem, > > > > I see that too - I'm glad someone else does :-) > > When you have aggressive PM working at the SOC level you many times lost a character on UART every since OMAP2. A strange but true statement is it is nice to see it losing a character on mainline as it as in indication that PM is likely working. > > If you just hook up simple RX and TX lines and not other flow control it is very likely especially with older OMAPs you can lose the 'wake' character on debug console. The UART operates on a derived clock from a 96MHz DPLL which was probably stopped. When the wakeup event hits the IO ring many internals may need to repower and its source DPLL needs to relock. This all can take a while and you can lose the start bit at high baud rate. If you use flow control you might be able to get ahead of it. So... if flow control is available, then when we idle the uart we should set the trigger so that RTS is de-asserted as soon as one character arrives. That would minimise the number of corrupt character we receive and ensure we resync as early as possible (I have seen 2 corrupt characters when CR,NL arrive back-to-back. Neither get through correctly). Actually ... could we make the off-mode setting of the RTS pin be "ready to send", but as soon as we wake up, it is reset to "don't send now" until everything is properly awake and configured? That should ensure only one byte is lost. > Outside of debug console, this loss has not been huge. Protocols like irda would retransmit their magic wake packets. You can move between DMA and interrupt modes with activity. So far there has been a work around per attached device. What about bluetooth? HCI/UART doesn't seem to have a lot of error handling. Maybe it has enough though. (I have bluetooth on UART1 ... of course we might not have the same problems on UART1 .. I haven't played with bluetooth much yet). Thanks for the insights, NeilBrown
Attachment:
signature.asc
Description: PGP signature
