Phil Budne <budd@cs.bu.edu> writes:

  >> Ian Dall just sent me mail noting that once the ring buffer
  >> (or higher level structures in the line discipline) fill
  >> that information isn't passed down to the interrupt service
  >> routine to STOP removing characters from the FIFO

  > I realized this is a bad plan (TM); You don't want the ISR to fire
  > then do nothing, since the RxRDY is a wired OR of the signal for both
  > ports on a DUART, and the ICU is programmed for an edge sensitive
  > interrupt (you'll lose interrupts from the other port).  Instead you
  > need to force the chip to not assert the interrupt condition (if using
  > the regular interrupt line this could be done by removing the RxRDY
  > condition from the per channel interrupt mask).

Well, I have written some code, which is being compiled as I write.
The trick I have used to is use scnrxenable/scnrxdisable to stop
interupts from the fifo. These work by changing the control bits for
the op port whihc is used for the rx int. By doing it there instead
of at the ICU, you don't lose any interrupts. However, I have just realized
I have the converse problem. If one channel is blocked and another isn't
then the fifo of the blocked channel will be read anyway. That shouldn't
be too hard to fix.

I have added a scnhwiflow entry point. All it does to stop the flow up
is return 1. This causes a TS_TBLOCK flag to be set by the line
discipline. The software interrupt routine looks for this flag and
exits when/if it gets set. To restart the upward flow, scnhwiflow
schedules a softint if there is data in the ring buffer to be
processed (and returns 1 to cause the TS_BLOCK to be cleared). The
rxint routine checks to see if the ring buffer is more than 3/4 full
(only when RTS flow control is being used) and disables itself.  It
only checks once per unrolled loop. The software interrupt routine
does an rxenable if the ring buffer is leass than half full.

Undoubtedly there are bugs though!

Ian