omap-serial RX DMA polling?

omap-serial RX DMA polling?

[Paul Walmsley]

Hello Govindraj

while trying to track down some of the serial-related PM issues in 
v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond 
polling timer when DMA is enabled (uart_dma.rx_timer) (!)  This seems 
quite broken from both the DMA and PM points of view.

>From a DMA point of view, the DMA transfer should automatically start 
when there is data to transfer, and stop when there is no data left, based 
on the DMA request lines.  So timer-driven polling should not be needed at 
all.

>From a PM point of view, this short timer will effectively prevent the MPU 
from going into a low-power state whenever there is data in the FIFO.  
This will more than erase any energy consumption or CPU efficiency 
benefits of doing DMA.  Interrupt-driven PIO should be much more efficient 
than this, since at least the MPU can enter a low-power state while 
waiting for the FIFO to fill.

So basically, the broken timeout calculations used in the interrupt-driven 
PIO mode (which set a 1 microsecond PM QoS constraint), plus the 1 
microsecond polling timer used in DMA mode, mean that this driver is 
pretty bad from a PM perspective.

I sent some patches to fix the interrupt-driven PIO receive part of the 
problem, which you've probably seen.  But I'm hoping that you can describe 
further why the driver needs this RX DMA polling timer?  Shouldn't it be 
unnecessary?  If it's truly unavoidable, then we should presumably not 
even bother with RX DMA at all.



 - Paul

Re: omap-serial RX DMA polling?

[Govindraj]

On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Hello Govindraj
>
> while trying to track down some of the serial-related PM issues in
> v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
> polling timer when DMA is enabled (uart_dma.rx_timer) (!)  This seems
> quite broken from both the DMA and PM points of view.
>

Poll rate is used for doing tty_insert_flip_string for pushing data to
user space
to keep faster response to any client device over uart, some Bt chips
expect faster
response when data on uart arrives and packet should be pushed out immediately.


> From a DMA point of view, the DMA transfer should automatically start
> when there is data to transfer, and stop when there is no data left, based
> on the DMA request lines.  So timer-driven polling should not be needed at
> all.
>

its for tty_insert pushing data to tty stack.


> From a PM point of view, this short timer will effectively prevent the MPU
> from going into a low-power state whenever there is data in the FIFO.
> This will more than erase any energy consumption or CPU efficiency
> benefits of doing DMA.  Interrupt-driven PIO should be much more efficient
> than this, since at least the MPU can enter a low-power state while
> waiting for the FIFO to fill.
>

yes we maintain 3 secs timeout period and keep uart active in DMA case.
since rx is asynchronous we cant afford to stop and start dma every time after
x bytes after every rx data completion call back.


> So basically, the broken timeout calculations used in the interrupt-driven
> PIO mode (which set a 1 microsecond PM QoS constraint), plus the 1
> microsecond polling timer used in DMA mode, mean that this driver is
> pretty bad from a PM perspective.
>
> I sent some patches to fix the interrupt-driven PIO receive part of the
> problem, which you've probably seen.  But I'm hoping that you can describe
> further why the driver needs this RX DMA polling timer?  Shouldn't it be
> unnecessary?  If it's truly unavoidable, then we should presumably not
> even bother with RX DMA at all.
>
>
>
>  - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap-serial RX DMA polling?

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1490 bytes --]

On Mon, 23 Jan 2012, Govindraj wrote:

> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > while trying to track down some of the serial-related PM issues in
> > v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
> > polling timer when DMA is enabled (uart_dma.rx_timer) (!)  This seems
> > quite broken from both the DMA and PM points of view.
> 
> Poll rate is used for doing tty_insert_flip_string for pushing data to 
> user space to keep faster response to any client device over uart, some 
> Bt chips expect faster response when data on uart arrives and packet 
> should be pushed out immediately.

Hmm.  Let's say that the BT transceiver uses the fastest transmission rate 
supported by the OMAP UARTs -- 3,686,400 bits per second, according to 
Table 17-1 in the 34xx TRM vZR.  So the RX poll timer would go off about 
~2.7 times per input character[1].  That seems like overkill...

For minimum receive latency, how about calling tty_insert_flip_string() 
from the RX DMA callback, and using a smaller transfer count?  Or even 
better, use PIO for the receive path and set the RX FIFO threshold to 1?

No poll timer should be needed in either case.


- Paul

1. At 10 line bits per character (start + byte + stop), each character 
should take about 2.7 microseconds to transfer (the reciprocal of (3 686 
400 line bits per second / 10 line bits per character / 1 000 000 
microseconds per second)).

Re: omap-serial RX DMA polling?

[Govindraj]

On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
> On Mon, 23 Jan 2012, Govindraj wrote:
>
>> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> >
>> > while trying to track down some of the serial-related PM issues in
>> > v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
>> > polling timer when DMA is enabled (uart_dma.rx_timer) (!)  This seems
>> > quite broken from both the DMA and PM points of view.
>>
>> Poll rate is used for doing tty_insert_flip_string for pushing data to
>> user space to keep faster response to any client device over uart, some
>> Bt chips expect faster response when data on uart arrives and packet
>> should be pushed out immediately.
>
> Hmm.  Let's say that the BT transceiver uses the fastest transmission rate
> supported by the OMAP UARTs -- 3,686,400 bits per second, according to
> Table 17-1 in the 34xx TRM vZR.  So the RX poll timer would go off about
> ~2.7 times per input character[1].  That seems like overkill...
>

Yes correct, Looks like the poll rate is to aggressive
it should be calculated based on baud rate provided from user apace
in termios function.

I had a patch to do the same in termios but,
if you have something similar you can post out as I am currently busy with
some other activities and may take more time.


> For minimum receive latency, how about calling tty_insert_flip_string()
> from the RX DMA callback, and using a smaller transfer count?  Or even
> better, use PIO for the receive path and set the RX FIFO threshold to 1?
>
> No poll timer should be needed in either case.

I remember doing similar excercise with BT + uart on zoom board
but performance numbers where impacted.

I made buffer size as 1 byte and removed polling function and got rx_callback
for every byte completion and pushed same to tty layer.

BT FTP throughput got impacted a lot.

--
Thanks,
Govindraj.R

note: I little busy currently and replies might be delayed.
         sorry for any inconvenience.


>
>
> - Paul
>
> 1. At 10 line bits per character (start + byte + stop), each character
> should take about 2.7 microseconds to transfer (the reciprocal of (3 686
> 400 line bits per second / 10 line bits per character / 1 000 000
> microseconds per second)).
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap-serial RX DMA polling?

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2568 bytes --]

On Mon, 23 Jan 2012, Govindraj wrote:

> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Mon, 23 Jan 2012, Govindraj wrote:
> >
> >> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >> >
> >> > while trying to track down some of the serial-related PM issues in
> >> > v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
> >> > polling timer when DMA is enabled (uart_dma.rx_timer) (!)  This seems
> >> > quite broken from both the DMA and PM points of view.
> >>
> >> Poll rate is used for doing tty_insert_flip_string for pushing data to
> >> user space to keep faster response to any client device over uart, some
> >> Bt chips expect faster response when data on uart arrives and packet
> >> should be pushed out immediately.
> >
> > Hmm.  Let's say that the BT transceiver uses the fastest transmission rate
> > supported by the OMAP UARTs -- 3,686,400 bits per second, according to
> > Table 17-1 in the 34xx TRM vZR.  So the RX poll timer would go off about
> > ~2.7 times per input character[1].  That seems like overkill...
> 
> Yes correct, Looks like the poll rate is to aggressive
> it should be calculated based on baud rate provided from user apace
> in termios function.
> 
> I had a patch to do the same in termios but,
> if you have something similar you can post out as I am currently busy with
> some other activities and may take more time.
> 
> > For minimum receive latency, how about calling tty_insert_flip_string()
> > from the RX DMA callback, and using a smaller transfer count?  Or even
> > better, use PIO for the receive path and set the RX FIFO threshold to 1?
> >
> > No poll timer should be needed in either case.
> 
> I remember doing similar excercise with BT + uart on zoom board
> but performance numbers where impacted.
> 
> I made buffer size as 1 byte and removed polling function and got rx_callback
> for every byte completion and pushed same to tty layer.
> 
> BT FTP throughput got impacted a lot.

The point is that if you want tty_insert_flip_string() to be called after 
every character is received, there seems little point in using RX DMA.  
It should be less efficient than PIO.  And the current way that it is used 
is pointless from a power management point of view.

In general, RX DMA would seem to be inappropriate for a latency-sensitive 
application, unless the application can somehow communicate how many bytes 
it's expecting so the driver can adjust its DMA transfer size.


- Paul

Re: omap-serial RX DMA polling?

[Govindraj]

On Tue, Jan 24, 2012 at 1:18 AM, Paul Walmsley <paul@pwsan.com> wrote:
> On Mon, 23 Jan 2012, Govindraj wrote:
>
>> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Mon, 23 Jan 2012, Govindraj wrote:
>> >
>> >> On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> >> >
>> >> > while trying to track down some of the serial-related PM issues in
>> >> > v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
>> >> > polling timer when DMA is enabled (uart_dma.rx_timer) (!)  This seems
>> >> > quite broken from both the DMA and PM points of view.
>> >>
>> >> Poll rate is used for doing tty_insert_flip_string for pushing data to
>> >> user space to keep faster response to any client device over uart, some
>> >> Bt chips expect faster response when data on uart arrives and packet
>> >> should be pushed out immediately.
>> >
>> > Hmm.  Let's say that the BT transceiver uses the fastest transmission rate
>> > supported by the OMAP UARTs -- 3,686,400 bits per second, according to
>> > Table 17-1 in the 34xx TRM vZR.  So the RX poll timer would go off about
>> > ~2.7 times per input character[1].  That seems like overkill...
>>
>> Yes correct, Looks like the poll rate is to aggressive
>> it should be calculated based on baud rate provided from user apace
>> in termios function.
>>
>> I had a patch to do the same in termios but,
>> if you have something similar you can post out as I am currently busy with
>> some other activities and may take more time.
>>
>> > For minimum receive latency, how about calling tty_insert_flip_string()
>> > from the RX DMA callback, and using a smaller transfer count?  Or even
>> > better, use PIO for the receive path and set the RX FIFO threshold to 1?
>> >
>> > No poll timer should be needed in either case.
>>
>> I remember doing similar excercise with BT + uart on zoom board
>> but performance numbers where impacted.
>>
>> I made buffer size as 1 byte and removed polling function and got rx_callback
>> for every byte completion and pushed same to tty layer.
>>
>> BT FTP throughput got impacted a lot.
>
> The point is that if you want tty_insert_flip_string() to be called after
> every character is received, there seems little point in using RX DMA.
> It should be less efficient than PIO.  And the current way that it is used
> is pointless from a power management point of view.
>

Yes, Its between power and performance, current way gives a better
response for most devices. (specially while downloading the firmware for
external chip initialization and other use cases)

> In general, RX DMA would seem to be inappropriate for a latency-sensitive
> application, unless the application can somehow communicate how many bytes
> it's expecting so the driver can adjust its DMA transfer size.
>

Yes I had done that long time back, gives a little edge for
throughput(probably even PM
but haven't checked though) but many users of driver are hesitant to
modify their user space
apps to pass buffer size (modify the bt stack or the gps stack) and
sometimes even those
stacks are unaware of incoming sizes.

Many expect to work as is when hooked up to the user space stack without
any changes.

--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap-serial RX DMA polling?

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2622 bytes --]

On Tue, 24 Jan 2012, Govindraj wrote:

> On Tue, Jan 24, 2012 at 1:18 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Mon, 23 Jan 2012, Govindraj wrote:
> >> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > The point is that if you want tty_insert_flip_string() to be called after
> > every character is received, there seems little point in using RX DMA.
> > It should be less efficient than PIO.  And the current way that it is used
> > is pointless from a power management point of view.
> 
> Yes, Its between power and performance, current way gives a better
> response for most devices

That seems rather unlikely.  And I don't agree that there is a balance to 
be struck in this case.  Compared to a correctly-working RX PIO path, the 
RX DMA in the current driver is likely to be much worse in energy 
consumption, and to be equal at best in receive latency.

In a correctly-working RX PIO path, the driver is going to receive an 
interrupt the moment the data is ready to be transferred from the FIFO.  
The driver doesn't have to wait for a polling timer to fire and execute.  
Nor does the ISR have to compete with a 1 microsecond polling timer for 
the CPU.

And I doubt that an accurate comparison could have been made between the 
PIO and DMA RX paths.  In the current driver, the PIO RX FIFO threshold 
was set to 16 bytes, while the DMA RX FIFO threshold in the DMA path was 
set to 1 byte.  So I'm hardly surprised that the RX DMA path looked good 
under those circumstances.  The current driver is sufficiently broken that 
any benchmarks based on it are suspect.  And in many cases, the way that 
the driver works around its problems is by effectively disabling system 
power management.

> (specially while downloading the firmware for external chip 
> initialization and other use cases)

Downloading firmware to an external chip uses the transmit path, not the 
receive path.  So that is an orthogonal case.

In terms of transmit, it's hardly surprising that the TX DMA path would 
outperform the driver's current TX PIO path.  For one thing, the FIFO 
handling in the current TX PIO path is broken.  The driver doesn't even 
use 75% of the TX FIFO.  Also, the transmission of a large block of data 
is not sensitive to MPU wakeup latency the same way that RX DMA is.  A 
large block of data can be queued to be transmitted, and the MPU doesn't 
need to wake up again until the SDMA has finished handing off that data to 
the UART FIFO.  At that point the kernel has plenty of time to prepare the 
next buffer.


- Paul

Re: omap-serial RX DMA polling?

[Russell King - ARM Linux]

On Tue, Jan 24, 2012 at 12:58:57AM -0700, Paul Walmsley wrote:
> On Tue, 24 Jan 2012, Govindraj wrote:
> 
> > On Tue, Jan 24, 2012 at 1:18 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > > On Mon, 23 Jan 2012, Govindraj wrote:
> > >> On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > >
> > > The point is that if you want tty_insert_flip_string() to be called after
> > > every character is received, there seems little point in using RX DMA.
> > > It should be less efficient than PIO.  And the current way that it is used
> > > is pointless from a power management point of view.
> > 
> > Yes, Its between power and performance, current way gives a better
> > response for most devices
> 
> That seems rather unlikely.  And I don't agree that there is a balance to 
> be struck in this case.  Compared to a correctly-working RX PIO path, the 
> RX DMA in the current driver is likely to be much worse in energy 
> consumption, and to be equal at best in receive latency.
> 
> In a correctly-working RX PIO path, the driver is going to receive an 
> interrupt the moment the data is ready to be transferred from the FIFO.  

That's hellishly inefficient.  In a correctly working RX PIO path with
FIFO, this is how most hardware is designed to work:

- The UART receives a character.  It places it into its FIFO, and it starts
  a timer based on the bit rate.
- If another character is being received, this will be received and placed
  into the FIFO.  The timer is restarted.  This continues until the FIFO
  hits the watermark level which raises the receive interrupt.
- If no character is received, the timer eventually expires and a
  receive timeout interrupt is raised instead.

Generally, what you want for transmit is to wait for the TX FIFO to
drain to maybe half full, and then reload it until it is completely
full.

For the RX FIFO, you want to set the watermark such that you get a
decent number of bytes in there before the receive interrupt is
raised, but not soo many that an overrun is likely.

One of the point of having FIFOs is that they batch up the transmit and
receive activity to make it more efficient at servicing the UART.

Setting the FIFO levels to one character virtually negates the point
of having FIFOs - there is no point setting the TX FIFO to raise an
interrupt when there's one character space left.  As has already been
reported, this just puts the interrupt rate up, and means you waste a
lot more CPU (or bus) time servicing the transmit path.

As for RX DMA vs RX PIO, that depends on the UART (I don't know how
OMAPs UARTs behave.)  To sanely use RX DMA, you need the UART to raise
the RX timeout interrupt after characters have been offloaded by the
RX DMA.  Lets saying that RX FIFO is 32 bytes deep, and it's set to
raise the RX DMA request at 16 bytes full.  If you program the DMA
controller to burst 16 bytes off the RX FIFO, you'll empty it and
it'll never raise the RX timeout interrupt.  So you'll need to know
how many characters you're expecting.

If on the other hand you burst 8 bytes off the RX FIFO, you'll leave
8 bytes in the FIFO.  If the UART works properly, it will raise an
RX timeout interrupt after N bit periods where the RX line is inactive.

What that means is that during a burst of RX activity, your DMA takes
the strain of receiving characters, and you process those characters
when either the RX buffer becomes full or when there's a pause in
reception.  This gives good efficiency during bursts while maintaining
interactivity - to the same levels as that expected by RX PIO using
the FIFO.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap-serial RX DMA polling?

[Paul Walmsley]

On Tue, 24 Jan 2012, Russell King - ARM Linux wrote:

> On Tue, Jan 24, 2012 at 12:58:57AM -0700, Paul Walmsley wrote:
> 
> > In a correctly-working RX PIO path, the driver is going to receive an 
> > interrupt the moment the data is ready to be transferred from the FIFO.  
> 
> That's hellishly inefficient.  

If the point is to minimize the receive latency, as Govindraj described 
earlier, then setting an RX FIFO threshold to one byte is the way to go.  
It certainly seems preferable to the use of a DMA RX path with a 1 
microsecond polling timer.  Ideally this would be something that the 
serial user could tune.

> Generally, what you want for transmit is to wait for the TX FIFO to
> drain to maybe half full, and then reload it until it is completely
> full.

Interesting rule of thumb.  For OMAP there are also power management 
considerations.  For example, if we can estimate the maximum amount of 
time it will take for the CPU to refill the transmit FIFO, then the TX 
FIFO threshold can be adjusted down to reduce the number of 
wakeups/interrupts needed to transmit a buffer.

In fact from a narrow PM perspective, the ideal TX FIFO threshold would 
basically be zero: to allow the entire FIFO to drain before waking the CPU 
back up to refill it.  There's no data loss restriction as there is with 
the RX FIFO.  Of course, many serial users couldn't tolerate such an 
setting and still work acceptably.  It would be nice if the driver could 
allow serial users to override the estimate that it generates.

> For the RX FIFO, you want to set the watermark such that you get a
> decent number of bytes in there before the receive interrupt is
> raised, but not soo many that an overrun is likely.

One other constraint.  If the RX FIFO threshold is set too high, then the 
CPU is effectively prevented from entering a deep sleep state, since the 
CPU has to be able to wake up in time to prevent an RX overrun.  The lower 
the RX FIFO threshold, the more time the CPU has to wake up, and the 
deeper the sleep state the CPU can enter.

> One of the point of having FIFOs is that they batch up the transmit and
> receive activity to make it more efficient at servicing the UART.

Yep.  Also, another point is to allow the servicer to enter a low power 
state while the FIFOs fill or drain.

> Setting the FIFO levels to one character virtually negates the point of 
> having FIFOs - there is no point setting the TX FIFO to raise an 
> interrupt when there's one character space left.  As has already been 
> reported, this just puts the interrupt rate up, and means you waste a 
> lot more CPU (or bus) time servicing the transmit path.

In the case of this particular patchset, there was indeed a point to 
setting the TX FIFO to 1; it was to work around a hardware bug.  As the 
patch description stated, it's a pretty nasty penalty that is worth 
avoiding if at all possible[*].  I'm not endorsing that as an appropriate 
setting outside of a bug workaround.

> As for RX DMA vs RX PIO, that depends on the UART (I don't know how
> OMAPs UARTs behave.)  To sanely use RX DMA, you need the UART to raise
> the RX timeout interrupt after characters have been offloaded by the
> RX DMA.  Lets saying that RX FIFO is 32 bytes deep, and it's set to
> raise the RX DMA request at 16 bytes full.  If you program the DMA
> controller to burst 16 bytes off the RX FIFO, you'll empty it and
> it'll never raise the RX timeout interrupt.  So you'll need to know
> how many characters you're expecting.
>
> If on the other hand you burst 8 bytes off the RX FIFO, you'll leave
> 8 bytes in the FIFO.  If the UART works properly, it will raise an
> RX timeout interrupt after N bit periods where the RX line is inactive.
> 
> What that means is that during a burst of RX activity, your DMA takes
> the strain of receiving characters, and you process those characters
> when either the RX buffer becomes full or when there's a pause in
> reception.  This gives good efficiency during bursts while maintaining
> interactivity - to the same levels as that expected by RX PIO using
> the FIFO.

Well, Govindraj has some low-latency requirement, and no way to specify 
how many bytes he's expecting.  So if RX DMA is going to be used, the 
driver will still need some kind of timer to flush any bytes that could be 
stuck in the middle of a DMA transfer.  This still seems like a case where 
RX PIO would do a better job; no need for a timer, and immediate 
notification when a character arrives, if the threshold is set that way.

As far as the RX timeout goes, those don't seem to be delivered properly 
when the CPU is in a low-power state.  This is probably due to the 
previously-mentioned hardware bug, although it could be due to a driver 
bug.  So we may be out of luck there.  We (meaning the people working on 
OMAP) also need to figure out here what the OMAP UART RX timeout would 
theoretically be, since it doesn't appear to be documented.

Thanks for the comments.


- Paul

* There is another workaround for this bug under development here that
  shouldn't require changing the TX FIFO.  If it passes testing here, then 
  the TX FIFO of 1 shouldn't be needed.

Re: omap-serial RX DMA polling?

[Paul Walmsley]

On Tue, 24 Jan 2012, Paul Walmsley wrote:

> We (meaning the people working on OMAP) also need to figure out here 
> what the OMAP UART RX timeout would theoretically be, since it doesn't 
> appear to be documented.

Correction.  The UART RX timeout is documented in section 17.4.4.1.3.7.1 
"Time-out Counter" of the 34xx TRM vZT.  The counter starts when the RX 
line is high, sampled in the middle of the bit, and continues for "4x 
programmed word length + 12 bits".  So at 115200 8n1 this looks like
382 microseconds, counted from the center of the stop bit.

Since a wakeup for this event isn't delivered when the UART is in a 
low-power idle state, we should probably consider keeping the UART out of 
idle in the RX path until we get a RX timeout interrupt.  This interrupt 
is only delivered when the RX FIFO has data in it, so we'd have to avoid 
draining the RX FIFO completely if we wanted to use this.


- Paul