3 extra driver need to develop for GTA03
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
>> 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.
More information about the openmoko-kernel