[PATCH] 8xx_io/uart.c

[Joakim Tjernlund]

> [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Dan Malek
> Joakim Tjernlund wrote:
> > Please can you change TX_NUM_FIFO to 8 and TX_BUF_SIZE to 96,
> > since chars are lost when pasting text into the console otherwise.
>
> What makes 96 a big enough number?  If you want to do this locally,
> that's fine, but only flow control can guarantee you won't overflow
> a serial port of any fifo depth.

The fix I posted for drivers/char/n_tty.c is buggy w.r.t looking and
noone wants to play with the tty layer since it is a mess.

So I have been looking into what can be done in the uart.c.
opost_block(in n_tty.c) will never write more that 80 chars in
one go so it makes sense if we can match that size(TX_BUF_SIZE >= 80).
That should not be a problem since this memory is allocated with
m8xx_cpm_hostalloc()and the only user that function is uart.c

Increasing TX_NUM_FIFO to 8 is not big deal either IMHO.
Possibly one could let serial_console_setup allocate all the
BDs that is needed and make rs_8xx_init() reuse them. That
will save 24 bytes(3 BDs) from dp memory. This may be tricky though.

Another thing that will help is to make rs_8xx_put_char() build
a transmit queue and impl. rs_8xx_flush_chars() to actually write
them. I have tested this and it helps but it won't solve all cases.

What do you think?

> I don't want to arbitrarily make
> this fifo so large as there are other processing/latency/memory
> tradeoffs.  The SMC is not a high performance interface and it
> consumes lots of CPM cycles.

  I can't see the processing and latency implications.

   Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/