]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
uart(4): Honor hardware state of NS8250-class for tsw_busy
authorMarius Strobl <marius@FreeBSD.org>
Fri, 12 Jan 2024 22:27:07 +0000 (23:27 +0100)
committerMarius Strobl <marius@FreeBSD.org>
Sun, 14 Jan 2024 07:03:59 +0000 (08:03 +0100)
commit353e4c5a068d06b0d6dcfa9eb736ecb16e9eae45
tree19f030744a84a7f40a3cc537f29faa1b62ab7c65
parentd5e0a182cf153f8993a633b93d9220c99a89e760
uart(4): Honor hardware state of NS8250-class for tsw_busy

In 9750d9e5, I brought the equivalent of the TS_BUSY flag back in a
mostly hardware-agnostic way in order to fix tty_drain() and, thus,
TIOCDRAIN for UARTs with TX FIFOs. This proved to be sufficient for
fixing the regression reported. So in light of the release cycle of
FreeBSD 10.3, I decided that this change was be good enough for the
time being and opted to go with the smallest possible yet generic
(for all UARTs driven by uart(4)) solution addressing the problem at
hand.

However, at least for the NS8250-class the above isn't a complete
fix as these UARTs only trigger an interrupt when the TX FIFO became
empty. At this point, there still can be an outstanding character
left in the transmit shift register as indicated via the LSR. Thus,
this change adds the 3rd (besides the tty(4) and generic uart(4) bits)
part I had in my tree ever since, adding a uart_txbusy method to be
queried in addition for tsw_busy and hooking it up as appropriate
for the NS8250-class.

As it turns out, the exact equivalent of this 3rd part later on was
implemented for uftdi(4) in 9ad221a5.

While at it, explain the rational behind the deliberately missing
locking in uart_tty_busy() (also applying to the generic sc_txbusy
testing already present).
sys/arm/nvidia/tegra_uart.c
sys/dev/uart/uart_dev_ns8250.c
sys/dev/uart/uart_dev_ns8250.h
sys/dev/uart/uart_dev_snps.c
sys/dev/uart/uart_dev_ti8250.c
sys/dev/uart/uart_if.m
sys/dev/uart/uart_tty.c