3 extra driver need to develop for GTA03

Mike (mwester) mwester at dls.net
Thu May 29 06:51:32 CEST 2008


Alan Cox wrote:
>> The Linux serial driver is an abomination in itself (the only saving grace is 
>> that it's largely compatible back to the days of the ASR33 teletype machine). 
> 
> We do 2Mbits/sec quite happily.

I'm not referring to speed, I'm referring to the incredible set of serial 
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 
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 
a good thing, but if we were to do it again, would all of that really be in the 
kernel?

>> IMO, if performance is the goal, we need to consider a custom high-speed serial 
>> driver for the UART connected to the GSM, one that gets rid of the overhead of 
>> the entire tty layer in the kernel.
> 
> What overhead. If you are driving the tty layer properly on a modern
> kernel you should have almost no overhead from the tty layer. If not
> collect profile traces from 2.6.24 or later, gprof them, produce the
> graphs and file a bug.

What overhead, you ask? The overhead of handling everything a character at a 
time!  I have no doubt that with enough CPU dedicated to the task, one can 
achieve remarkable throughput.  But I think that's unnecessary overhead 
especially for when dealing with protocols that are not character-at-a-time. I 
doubt that the type of driver I mentioned in the original email would be very 
useful for a console, but that's not the problem I'm considering; I'm speaking 
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.

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.

> Alan

Mike (mwester)




More information about the openmoko-kernel mailing list