I'm not sure whether this has already been implemented, but at least I
haven't found a patch for the kernel on the net. This patch promises
serial data transmission without FIFO overrun/underrun errors resulting
in data loss, confused modems, hanging modem software etc. given that
you have one of those 16550C UART chips (quite common in today's serial
cards but not yet built into the main boards). It works even under high
system load.
It's not so simple as that.
First take a look at the chipset release. The 16550 UART series has a
number of subreleases:
16550 First version, buggy. Very rarely used. (Replace!)
16550A Most common version. This chip is today's standard.
16550B Enhanced version.
16550C More enhanced version with hardware autoflow.
First of all, when you talk about 16550 UART's, you have to specify
which manufacturer. There are a *large* number of companies making
16550 clones. Some of these clones include StarTech's 16650, TI's
16750, and Oxford Semiconductor's 16950.
National Semiconductor made the original 8250, 16450, and 16550 UART
chips. As such, I consider them as morally owning the above namespaces,
and if someone else came up with a 16550C that wasn't National
Semiconductor, I wouldn't consider it part of the same product line.
Your subreleases is also oversimplifies the issue of the 16550. The
NS16550 is the first buggy version. This was followed by the NS16550A,
which did not have the FIFO bug. However, for a while after that,
National Semiconductor was selling a PC16550 which was bug-free, and
which Linux will identify as a 16550A. National Semiconductor's current
16450 part is called the PC16550D, but it has no enhanced features over
the original 16550A at the software programming level.
So whoever designed and manufacturered the 16550C, it wasn't National
Semiconductor. And given that there are so many National Semiconductor
clone manufacturers out there, I doubt whether this chip really is
"quite common in today's serial cards".
This patch now enables detection of the 16550C and uses one of its
advanced feature: hardware autoflow. This feature handles the CTS and RTS
automatically (i.e. by hardware in the chip) depending on FIFO state.
This means, if the FIFO gets full the chip itself stops the data transfer
via RTS and CTS lines. No software interaction is necessary for that.
I've found that hardware receive autoflow based on the FIFO flowing
generally isn't a great idea. First of all, if the system can't handle
the serial interrupt within 8 character times, there's something pretty
seriously wrong, and automatic flow control merely hides the problem.
If you are in this bad situation, yanking the flow control signals up
and down rapidly as the FIFO fills and empties is also not good for
performance, because there is often a delay before a device starts
sending after it stops sending due to a flow control signal.
Also, many devices aren't can't stop instantly, either. That's why
Linux as a 1024 byte internal buffer, and will start signalling the flow
control signal when there 128 bytes left. I want to give plenty of time
for the flow control signal to happen.
As you yourself point out in the source code, this can cause some data
transfer lockups.
+ * *** Currently only implemented for the 16550C. The 16650=
+ * can do autoflow too, but it uses different registers.
Not true. The National Semiconductor 16550 can not do automatic flow
control.
In any case, I'll look at supporting the 16550C, but only if someone can
identify the manufacturer and I can get a hold of some formal datasheets
describing it. I've done some web searching, and nothing's shown up as
far as an manufacturer is concerned.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/