3 extra driver need to develop for GTA03

Alan Cox alan at lxorguk.ukuu.org.uk
Thu May 29 13:14:23 CEST 2008

> options that user-space needs to wade through, and presumably the drivers need 
> to support in some form or another.  Many of these options date back to the days 

No. Please go and read SuS on the subject. A user space application
passes the desired terminal options. The driver passes back the resulting
set which need not be all the user requested.

> of mechanical terminals and devices such as the ASR33 and the almost-as-old 
> Decwriters (things like inter-character delays, etc).  I think compatibility is 

We don't support inter character delays and nobody has requested them. We
do see pretty much all the other stuff being used including arbitary baud
rate support and mark/space parity.

> What overhead, you ask? The overhead of handling everything a character at a 

Actually I don't ask because I've actually read the code. Nor do we
handle everything one character at a time. In fact our default behaviour
on legacy "byte at a time" uart chips is to batch them.

> of high-speed devices moving lots of data serially in high-latency environments, 
> using modern UARTs capable of DMA.  Leave the console on the existing driver; 
> but have an alternate that makes the best use of the hardware to move large 
> amounts of data with the smallest CPU and lowest clock speeds possible.

We already support block transfers. You can do DMA but most vendors no
longer bother as DMA isn't actually a performance win on a cached CPU.
Instead they normally use big FIFO buffers and a PIO block transfer which
means you don't get the cache flush/invalidate/refill overheads you would
otherwise get.

> No bugs are necessary to file; the current serial driver works for what it was 
> intended to do; I'm suggesting a driver for things that the current serial 
> driver was *not* intended to do.

Like make coffee or climb the Eiffel Tower perhaps ?

The current tty driver is optimised for the current normal uses of tty
devices. That happens to include

- Bulk transfer between virtual machines
- Virtual terminals
- And "traditional" serial devices

Generally speaking a modern block transfer capable UART behaviour is

	interrupt (if supported - big multiport cards poll)
	grab a single buffer
	block pio all the data into the buffer (and cache)
	immediate call to the ppp async code (with cache live data)
	release buffer


More information about the openmoko-kernel mailing list