On 02/13/2014 01:50 PM, Grant Edwards wrote:
On 2014-02-13, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
By "support", do you mean "add new features" or "workaround hardware
bugs"?
Both. "New features" mostly meant support for new models, but there
were also some actual new features and fixes for old ones that didn't
work. For example, it turns out almost nobody on the planet uses
IXANY. It got left out of both our automated and manual regression
testing, and (embarassingly) it took 10+ years for somebody to realize
that it didn't work. And that "somebody" was a customer that still
had 2.4 kenels running in production machines.
Not unusual. The N_TTY ldisc just had a bug fixed in 3.10 where turning off
IXON with an already-stopped tty permanently hung the tty.
For another driver, it's still a tty driver because the serial-core
API just didn't fit the device well enough to make it work. One
issue I recall is that our driver for that device needs to be able to
cause specific error returns for write() calls that are made when the
hardware is unavailable (and I think there are different errors
depending on why it's unavailable).
And this is the driver that uses tty_flip_* interface directly?
Well, they all do (under some circumstances). AFAICT, the method
provided by serial core is uart_insert_char(). When we initially
moved from tty driver to serial driver, we did everything in the
simplest, most obvious way (e.g. uart_insert_char()). But we moved
away from that for performance reasons. Our hardware is optimized for
transferring data to/from continuous buffers using 32-bit bus cycles
rather than reading/writing characters one at a time. At one point in
history our drivers would use inline assembly to execute a single
machine instruction to write an entire block of tx data to the
hardware or read an entire block of data from the hardware. There
were also some prototypes that did bus-master DMA for rx/tx data, but
that turned out to be more overhead than programmed I/O, and it was
abandoned. Now that CPU speeds have increased so much faster than bus
speeds, the inline assembly is no longer needed, but making a function
call for every rx byte is still enough to use an alarming amount of
CPU time.
We should extend the serial-core to add rx methods that work
with your UARTs in their fastest and most native way. The idea behind
serial-core is only to abstract the busy-work away from the i/o, not
become an ill-fitting shoe that enforces The One True Way.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
