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
- HSDPA
- 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
Alan
More information about the openmoko-kernel
mailing list