Linux Serial Console Driver Lands Patch For Possible ~25% Performance Improvement

[tuxd3v]

Nah, the laptop in question is only a couple of years old. For another data point, the desktop machine where I'm writing this message is something like 5 years(?) old, and also advertises a 16550A.

Looking at the Linux 8250 driver, it's capable of handling newer chips like the 16850 too. But maybe the Windows serial driver only supports the 16550A so there's no incentive for PC chipset manufacturers to spend $$$ and transistors on more capable IP? ARM might be different, as I'd guess the embedded world might have usecases for more capable serial interfaces.

Yeah, It can be the case..
Because its a low speed device, they don't bother to update the hardware of it..

In the laptops nowadays, serials are not even available from the outside( but they are good to troubleshooting something in the motherboard ),
But in desktop/Embedded use cases, yeah serials are available and are used for a lot of different things..

I agree with you, we in the Linux world still have a limitation on hardware..
Hardware is created based on what MS Windows, can support..its a shame but its what we have..

Now on new Servers, they should take some care, because Linux occupy a great share part of the Datacenter now, but I believe they continue to release hardware based on the support is has for Windows..

[sinepgib]

Serial consoles are also very common in (x86) server platforms, and I've never seen anything but 16550A there either. For a serial console, the 115.2 kpbs that it's capable of is sufficient. I was assuming many embedded platforms would be using serial for some custom communication, hence a need for a somewhat more capable interface (without having to go to some more modern, expensive and complicated link).

Hmmmm, well, being common and being a must are very different things. I'm not sure how often you really need to use the serial interface on those servers. Then again, I have no experience working with those, so my ignorance of it doesn't make it not the case.
GSM modules work pretty much like a UART from the OS POV, but I have no idea if they actually use a serial controller for communication. But if they do, there's a pretty big incentive for them to be fast.

[jabl]

You pretty much need the serial console for hardware bring up on those devices, so there's a lot more motivation. For example, you'll often want to read what u-boot outputs during boot when it fails to launch your kernel.

Serial consoles are also very common in (x86) server platforms, and I've never seen anything but 16550A there either. For a serial console, the 115.2 kpbs that it's capable of is sufficient. I was assuming many embedded platforms would be using serial for some custom communication, hence a need for a somewhat more capable interface (without having to go to some more modern, expensive and complicated link).

[sinepgib]

ARM might be different, as I'd guess the embedded world might have usecases for more capable serial interfaces.

You pretty much need the serial console for hardware bring up on those devices, so there's a lot more motivation. For example, you'll often want to read what u-boot outputs during boot when it fails to launch your kernel.

[jabl]

Because the system is telling you that you have a 16550A, doesn't mean it is really a 16550A, it means the driver it is using has that capability... its compatible..

Yeah, or like I wrote (quoting myself):

Not in the original form, but some tiny speck of dust in the corner of the system chipset that emulates the original device.

So there is some device that advertises itself as a 16550A, and the software driver can thus work with it just like if it was a "real" 16550A. But it also means that it inherits the limitations of the original 16550A, like the 16-byte FIFO.

But It could be that you are still using ancient technology in 2022,
But I would suppose that you were using, at least, a last iteration of it, and by that I mean a 16850/16950..or any knew part developed in the 21 century..

Nah, the laptop in question is only a couple of years old. For another data point, the desktop machine where I'm writing this message is something like 5 years(?) old, and also advertises a 16550A.

Looking at the Linux 8250 driver, it's capable of handling newer chips like the 16850 too. But maybe the Windows serial driver only supports the 16550A so there's no incentive for PC chipset manufacturers to spend $$$ and transistors on more capable IP? ARM might be different, as I'd guess the embedded world might have usecases for more capable serial interfaces.

[tuxd3v]

Per wikipedia, the 16550 was originally introduced in 1987, which was actually before the 486. That being said, they are still around. Not in the original form, but some tiny speck of dust in the corner of the system chipset that emulates the original device. So still limited by the 16 byte buffer. On my laptop (that doesn't even have a rs-232 port):

$ dmesg|grep ttyS
[ 2.332159] 0000:00:16.3: ttyS4 at I/O 0x3060 (irq = 19, base_baud = 115200) is a 16550A
[ 69.425124] dw-apb-uart.1: ttyS5 at MMIO 0x604110f000 (irq = 20, base_baud = 115200) is a 16550A

Because the system is telling you that you have a 16550A, doesn't mean it is really a 16550A, it means the driver it is using has that capability... its compatible..
But It could be that you are still using ancient technology in 2022,
But I would suppose that you were using, at least, a last iteration of it, and by that I mean a 16850/16950..or any knew part developed in the 21 century..

• 8250, 16450, early 16550: Obsolete with 1-byte buffers
• 16550, 16550A, 16C552: 16-byte buffers, TL=1,4,8,14; 115.2 kbps standard, many support 230.4 or 460.8 kbps( this part were present in 486 devices.. )
• 16650: 32-byte buffers. 460.8 kbps
• 16750: 64-byte buffer for send, 56-byte for receive. 921.6 kbps
• 16850, 16C850: 128-byte buffers. 460.8 kbps or 1.5 mbps
• 16950

This is one of the reasons why ARM CPUs have great uarts, some of them with baud rates in excess of 1.5 mbps

[jabl]

The thing is, having FIFO enabled and writing using xmit buffer check basically just fills up FIFO to its highest margin, and then is no different from single byte sending (except you get 15 bytes of latency). It does not need to know if FIFO is present as it's still using pre-FIFO xmit buffer emptiness bit. So still smells like 1982 there.

Well, it needs to know the size of the FIFO buffer so it knows how many bytes it can write before switching to waiting for the buffer to empty? How else would it be done?

If to carefully read the code, it was indeed using just xmit buffer bit instead of UART_LSR_THRE,

My reading is that the old code is basically

1. Wait for LSR_THRE
2. If flow control is enabled, wait for MSR_CTS
3. Write 1 byte.
4. GOTO 1.

New code (only used when flow control isn't enabled, otherwise the above old code is used) is

1. Wait for LSR_THRE
2. Write up to fifosize bytes
3. GOTO 1.

and the check for UART_FCR_ENABLE_FIFO is what looks even more weird (so FCR is written with enable FIFO bit somewhere else). Well, it's even more weird FIFO initialization is possible present somewhere, but code parts to honor FIFO were totally missing.

Looking around the code, it indeed enables the FIFO, if present, as part of initializing the device. It seems as if the FIFO was used in other parts of the serial code, just not when writing to the serial console, which this patch fixes.

The new 'flow control check' part disabling FIFO usage also seems unnecessary and excessively weird to me as I have written 16550A DOS applications and no, FIFO will NOT send anything to the wire when h/w flow control is used and corresponding signal line indication is raised. Maybe differs per UART implementation/emulation as well nowadays, but I heavily doubt it because the logic here is not honoring flow control signal may lead to data loss if FIFO attempts to transmit anything (the receiver FIFO buffers may be full or rcv buffer IS full, that's the point of h/w flow control to ensure transmitter waits until it's read on receiver without any need for software to read fast enough or intervene).

You may well be right, I guess this is an attempt to be conservative and not modify anything that the author hasn't tested. The author was using a server platform, I'd guess usage of flow control is rare there (I've never seen it).

[Alex/AT]

No. What was missing was FIFO handling of the serial console codeparts in the 8250 driver. Up until this change, the 8250 serial console just put 1 byte into the tx fifo and waited until it was sent to put in the next one.

The thing is, having FIFO enabled and writing using xmit buffer check basically just fills up FIFO to its highest margin, and then is no different from single byte sending (except you get 15 bytes of latency). It does not need to know if FIFO is present as it's still using pre-FIFO xmit buffer emptiness bit. So still smells like 1982 there.

If to carefully read the code, it was indeed using just xmit buffer bit instead of UART_LSR_THRE, and the check for UART_FCR_ENABLE_FIFO is what looks even more weird (so FCR is written with enable FIFO bit somewhere else). Well, it's even more weird FIFO initialization is possible present somewhere, but code parts to honor FIFO were totally missing.

The new 'flow control check' part disabling FIFO usage also seems unnecessary and excessively weird to me as I have written 16550A DOS applications and no, FIFO will NOT send anything to the wire when h/w flow control is used and corresponding signal line indication is raised. Maybe differs per UART implementation/emulation as well nowadays, but I heavily doubt it because the logic here is not honoring flow control signal may lead to data loss if FIFO attempts to transmit anything (the receiver FIFO buffers may be full or rcv buffer IS full, that's the point of h/w flow control to ensure transmitter waits until it's read on receiver without any need for software to read fast enough or intervene).

[sinepgib]

Serial debugging is used quite a bit for embedded development. I guess speed is not _that_ critical, but not having to wait too much for feedback is always welcome.

[torsionbar28]

I remember upgrading my two pc's in ~1993 with 16550 uart isa cards, as I had them connected with a null modem cable for file transfers. Switched to 10 Mb ethernet over 10base2 coax a year or so later.