On Tue, Sep 02, 2008 at 06:25:54PM +0100, Steven Clugston wrote:
> Hi
> 
> There is a problem/shortcoming of the MPC555 serial driver that I've
> discussed previously on the list that in its current implementation it
> cannot cope with continuous concurrent reception and transmission of
> characters as with the serial_echo.c test program. If a continuous
> stream of characters are sent from a PC with something like a 16x5x chip
> or superIO chip, then characters are almost immediately lost as the Rx
> DSR is not run in time. I have added a sort of software circular buffer
> between the ISR and DSR to allow a nominal number (say 256) of
> characters to be buffered. This fixes or reduces the problem for
> applications which require a serial packet of less than the buffer size
> to be received, provided there is a rest period between packets.
> 
> For a continuous data stream, this buffer will eventually overflow no
> matter how big it is made, so I have also separately implemented support
> for the hardware serial queue facility on the mpc555. Unfortunately this
> is only available on the first serial port (SCI1) on this chip (newer
> 5xx chips have it on both). It is available as a cdl option so that it
> can be disabled and the old behaviour is restored. There are two
> 16-character buffers or queues, one for Rx and one for Tx. There are
> half empty/full interrupts and full/empty interrupts as well as an Rx
> line idle interrupt to flush the buffer/queue when there is a gap or
> absence of incoming data.
> 
> I tried various methods for implementing this including separate DSRs
> for the interrupt sources, a combined DSR that deals with each interrupt
> source, but only reliable way I could get it to work is by using a
> combined DSR which doesn't care what the actual ISR source was. The
> trouble is that the status information is often lost by the time the DSR
> is reached as reading from certain registers clears the contents. Also
> DSRs seem to be run in the opposite order to which they are posted which
> makes it even harder to work out what part of the queue to read/write.
> The final implementation is perhaps the least elegant but nonetheless
> works. It just reads/writes whatever data is available at the time of
> the DSR running and subsequent DSR instances that have been posted just
> drop through if there is no data left to read by the time they run.
> 
> I've tested this extensively but perhaps not exhaustively (all of the
> type of parity/noise errors etc not fully tested as its perhaps
> difficult to contrive these).

This patch has been going back and forth for a while, and has now
reached the state it can be committed. Attached is what has been
committed.

        Andrew