Messages in this thread | | | Date | Wed, 23 Sep 1998 18:42:58 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: patch: serial 16550C autoflow |
| |
From: Frank Gockel <gockel@sent13.uni-duisburg.de> Date: Wed, 23 Sep 1998 12:17:26 +0200 (MET DST)
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/
| |