MFC 359899: Correct baud rate error calculation.

Shifting right by 1 is not the same as dividing by 2 for signed
values. In particular, dividing a signed value by 2 gives the integer
ceiling of the (e.g. -5 / 2 == -2) whereas shifting right by 1 always
gives the floor (-5 >> 1 == -3).

An embedded board with a 25 Mhz base clock results in an error of
-30.5% when used with a baud rate of 115200. Using division, this
truncates to -30% and is permitted. Using the shift, this fails and
is rejected causing TIOCSETA requests to fail with EINVAL and breaking
getty(8).

Using division gives the same error range for both over and under baud
rates and also makes the code match the behavior documented in the
existing comment about supporting boards with 25 Mhz clocks.

MFC r336623 by mmacy:

Fixes the interrupt storm in UART during the boot on ARMADA38X. The missing
attribution of ns8250->busy_detect breaks the UART support.

Original commit log:

Add busy detect quirk to list of console options

This change allows one to set the busy_detect flag
required by the synopsys UART at the loader prompt.
This is needed by the EPYC 3000 SoC.

This will give users a working console up to the point where getty is required:
hw.uart.console="mm:0xfedc9000,rs:2,bd:1"

Sponsored by: Rubicon Communications, LLC (Netgate)

MFC r352369: Relax TX draining in ns8250_bus_transmit().

Since TX interrupt is generated when THRE is set, wait for TEMT set means
wait for full character transmission time. At low speeds that may take
awhile, burning CPU time while holding sc_hwmtx lock, also congested.

This is partial revert of r317659.

Backport of r338074 - generalize uart_bus_probe and add SNPS support to x86

Submitted by: Rajesh Kumar
Differential Revision: https://reviews.freebsd.org/D17381

Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg

MFC r317659, r317752:
Make some UART consoles to not spin wait for data to be sent.

At least with Tx FIFO enabled it shows me ~10% reduction of verbose boot
time with serial console at 115200 baud.

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

Move support for Synopsys Designware APB UART out of ns8250 and into a
separate driver. Add support for activating clock and hwreset resources
for these devices when the EXT_RESOURCES option is present.

Reviewed by: andrew, mmel, Emmanuel Vadot <manu@bidouilliste.com>
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5749

Add ns16550a compatible string in UART 8250 driver

Obtained from: Semihalf
Submitted by: Michal Stanek <mst@semihalf.com>
Sponsored by: Annapurna Labs
Approved by: cognet (mentor)
Reviewed by: imp, wma
Differential revision: https://reviews.freebsd.org/D5404

UART: Fix spurious interrupts generated by ns8250 and lpc drivers:
- don't enable transmitter empty interrupt before filling TX FIFO.
- add missing uart_barrier() call in interrupt service routine

Fix busy-detect when using DesignWare UART

uart_dev_ns8250 now relies on compatible property instead of additional
'busy-detect' cell. All drivers with compatible = "snps,dw-apb-uart" have
busy detection turned on. DTS files of devices affected by the change
were modified and 'busy-detect' property was removed.

Reviewed by: andrew, ian, imp
Obtained from: Semihalf
Sponsored by: Stormshield
Submitted by: Bartosz Szczepanek <bsz@semihalf.com>
Differential revision: https://reviews.freebsd.org/D4218

Add compatibility string for dw-apb-uart in ns8250 driver

This compatibility string is used in .dts file of Armada38x
and isrequired for driver attachment.

Reviewed by: andrew, ian, imp
Obtained from: Semihalf
Sponsored by: Stormshield
Submitted by: Michal Stanek <mst@semihalf.com>
Differential revision: https://reviews.freebsd.org/D4216

Restore uart PPS signal capture polarity to its historical norm, and add an
option to invert the polarity in software. Also add an option to capture
very narrow pulses by using the hardware's MSR delta-bit capability of
latching line state changes.

This effectively reverts the mistake I made in r286595 which was based on
empirical measurements made on hardware using TTL-level signaling, in which
the logic levels are inverted from RS-232. Thus, this re-syncs the polarity
with the requirements of RFC 2783, which is writen in terms of RS-232
signaling.

Narrow-pulse mode uses the ability of most ns8250 and similar chips to
provide a delta indication in the modem status register. The hardware is
able to notice and latch the change when the pulse width is shorter than
interrupt latency, which results in the signal no longer being asserted by
time the interrupt service code runs. When running in this mode we get
notified only that "a pulse happened" so the driver synthesizes both an
ASSERT and a CLEAR event (with the same timestamp for each). When the pulse
width is about equal to the interrupt latency the driver may intermittantly
see both edges of the pulse. To prevent generating spurious events, the
driver implements a half-second lockout period after generating an event
before it will generate another.

Differential Revision: https://reviews.freebsd.org/D4477

uart(4) - make the 8250 uart baudrate tolerance build time tweakable.

It turns out on a 16550 w/ a 25MHz SoC reference clock you get a little
over 3% error at 115200 baud, which causes this to fail.

Just .. cope. Things cope these days.

Default to 30 (3.0%) as before, but allow UART_DEV_TOLERANCE_PCT to be
set at build time to change that.

Actually check the DTS node value to enable the uart quirks.

Without this fix, you cannot disable the quirks by setting it to 0, just
the presence of the FDT node was enough to enable it.

Add support for the uart classes to set their default register shift value.
This is needed with the pl011 driver. Before this change it would default
to a shift of 0, however the hardware places the registers at 4-byte
addresses meaning the value should be 2.

This patch fixes this for the pl011 when configured using the fdt. The
other drivers have a default value of 0 to keep this a no-op.

MFC after: 1 week

Move the uart_class definitions and fdt compat data into the individual
uart implementations, and export them using the new linker-set mechanism.

Differential Revision: https://reviews.freebsd.org/D1993
Submitted by: Michal Meloun

Pull in r267961 and r267973 again. Fix for issues reported will follow.

Revert r267961, r267973:

These changes prevent sysctl(8) from returning proper output,
such as:

1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory

Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after: 2 weeks
Sponsored by: Mellanox Technologies

In uart_bus_grab(), use the ier_mask instead of a custom hack for XScale.

Suggested by: jmg

In the grab function, keep the bit 6 on in the IER, on XScale, using 0
turns the UART off, which is unfortunate if one want to use it as a console.

Introduce grab and ungrab upcalls. When the kernel desires to grab the
console, it calls the grab functions. These functions should turn off
the RX interrupts, and any others that interfere. This makes mountroot
prompt work again. If there's more generalized need other than
prompting, many of these routines should be expanded to do those new
things.

Should have been part of r260889, but waasn't due to command line typo.

Reviewed by: bde (with reservations)

Wait for DesignWare UART transfers completion before accessing line control

When using DW UART with BUSY detection it is necessary to wait
until all serial transfers are finished before manipulating the
line control. LCR will not be affected when UART is busy.
In addition, if Divisor Latch Access Bit is being set in order to
modify UART divisors:
1. We will get BUSY interrupt if interrupts are enabled.
2. Because LCR will not be affected the THR and (even worse) IER
contents will be corrupted. This will lead to console hang.

Approved by: cognet (mentor)

A final test with unmodified code has shown that a delay of 150ms
is not giving us a 100% success rate. Bump the delay to 200ms as
that seems to do the trick.

Note that during testing the delay was added to uart_bus_attach()
in uart_core.c. While having the delay in a different place can
change the behaviour, it was not expected. Having to bump the
delay with another 50ms could therefore be an indication that
the problem can not be solved with delays.

Reported by: kevlo@
Tested by: kevlo@

Work-around a timing problem with the ITE IT8513E now that the core
calls ns8250_bus_ipend() almost immediately after ns8250_bus_attach().
As it appears, a line break condition is being signalled for almost
all received characters due to this. A delay of 150ms seems enough
to allow the H/W to settle and to avoid the problem.
More analysis is needed, but for now a regression has been addressed.

Reported by: kevlo@
Tested by: kevlo@

Make the uart ns8250 high-level interface public rather than static.
This makes it easier to implement new drivers which are "mostly ns8250"
but with some small difference such as needing to enable clocks or poke
a non-standard register at probe or attach time.

Add support for A10 uart.
A10 uart is derived from Synopsys DesignWare uart and requires
to read Uart Status Register when IIR_BUSY has detected.
Also this change includes FDT check, where it checks device
specific properties defined in dts and sets the busy_detect variable.
broken_txfifo is also needed to be set in order to make it work for
A10 uart case.

Reviewed by: marcel@
Approved by: gonzo@

Add a loader tunable "hw.broken_txfifo" which enables a workaround for a
bug in old versions of QEMU (and Xen, and other places using QEMU code).
On those buggy emulated UARTs, the "TX idle" interrupt gets lost; with
this workaround, we spinwait for the TX to happen and then send ourselves
the interrupt. It's ugly but it works, while minimizing the impact on
the code for the !broken_txfifo case.

MFC after: 2 weeks

Disable the TX ready interrupts once we received one, some UART won't clear
the IIR_TXRDY bit upon reading.

Reviewed by: marcel

Ignore MCR[6] during the probe to fix a false negative. Bit 6 of the
MCR register on the Sunix Sun1699 chip tends to be set but doesn't
seem to have a function. That is, FreeBSD just works (provided the
correct RCLK is used) regardless.

PR: kern/129663
Diagnostics: Eygene Ryabinkin <rea-fbsd at codelabs.ru>
MFC after: 3 days

Fix typos - remove duplicate "the".

PR: bin/154928
Submitted by: Eitan Adler <lists at eitanadler.com>
MFC after: 3 days

Remove redundant checking of sc_leaving (uart_intr() already handles this).

Approved by: marcel

Fix hangs caused by hardware that signals receive errors
(framing, parity, etc), but does not indicate characters
being received. Since no chracters have been received,
ignore the line errors.

PR: 131006
MFC after: 3 days

The XScale PXA255 has three generally ns16x50 compatible UARTs. One of the
variations from normal 16x50 behaviour however is the the use of a normally
unused bit of IER to control RX timeout interrupts independently of the
generally used RXRDY bit. If this bit is not enabled, we only ever get
interrupts when the FIFO is full, never before. This is not very useful when
the UART is being used as a console.

In order to support this without causing potential problems on more "normal"
16x50 variants, this change introduces two hints for the uart device, ier_mask
and ier_rxbits. These can be used to override which bits get set and cleared
when we're enabling and disabling RX interrupts.

Reviewed by: marcel

add device hints to control the rx FIFO interrupt level on 16550A parts

PR: kern/121421
Submitted by: UEMURA Tetsuya
Reviewed by: marcel
MFC after: 2 weeks

Don't use a time-limiting loop that's defined in terms of the baudrate
in the putc() method. Likewise, in the getc() method, don't check for
received characters with an interval defined in terms of the baudrate.
In both cases it works equally well to implement a fixed delay. More
importantly, it avoids calculating a delay that's roughly 1/10th the
time it takes to send/receive a character. The calculation is costly
and happens for every character sent or received, affecting low-level
console or debug port performance significantly. Secondly, when the
RCLK is not available or unreliable, the delays could disrupt normal
operation.

The fixed delay is 1/10th the time it takes to send a character at
230400 bps.

Don't expose the uart_ops structure directly, but instead have
it obtained through the uart_class structure. This allows us
to declare the uart_class structure as weak and as such allows
us to reference it even when it's not compiled-in.
It also allows is to get the uart_ops structure by name, which
makes it possible to implement the dt tag handling in uart_getenv().
The side-effect of all this is that we're using the uart_class
structure more consistently which means that we now also have
access to the size of the bus space block needed by the hardware
when we map the bus space, eliminating any hardcoding.

For embedded UARTs compatible with the ns8250 family it is possible
that the driver clock is identical to the processor or bus clock.
This is the case for the PowerQUICC processor. When the clock is
high enough, overflows happen in the calculation of the time it
takes to send 1/10 of a character, used in delay loops. Fix the
overflows so as to fix bugs in the delay loops that can cause either
insufficient delays or excessive delays.

- Add a uart_rxready() and corresponding device-specific implementations
that can be used to check whether receive data is ready, i.e. whether
the subsequent call of uart_poll() should return a char, and unlike
uart_poll() doesn't actually receive data.
- Remove the device-specific implementations of uart_poll() and implement
uart_poll() in terms of uart_getc() and the newly added uart_rxready()
in order to minimize code duplication.
- In sunkbd(4) take advantage of uart_rxready() and use it to implement
the polled mode part of sunkbd_check() so we don't need to buffer a
potentially read char in the softc.
- Fix some mis-indentation in sunkbd_read_char().

Discussed with: marcel

The lcr variable in ns8250_probe is now unused. Remove it.

Missed by: benno

Allow uart(4)'s ns8250 driver to work with devices whose regshift is > 0.

- Rename REG_DL to REG_DLL and REG_DLH.
- Always treat DLL and DLH as two separate 8-bit registers instead of one
16-bit register.

Additionally, remove the probe for the high 4 bits of IER being 0 and don't
assume we can always read/write 0 to/from those bits.

These changes allow uart(4) to drive the UARTs on the Intel XScale PXA255.

Reviewed by: marcel

Use 115200 and not 9600 as the initial baudrate. This speeds up
detection of the FIFO size. Especially for large FIFOs.

MFp4: Calculate the divisor before setting the DLAB bit. This
prevents that there's a control flow that leaves the DLAB
bit set.

Eliminate the sc_hasfifo flag from the softc. It was only used by
the NS8250 class driver. The UART has FIFOs if sc_rxfifosz>1, so
test for that instead.
While here properly initialize sc_rxfifosz and sc_txfifosz in the
case the UART doesn't have FIFOs.

Don't hold the hardware mutex across getc(). It can wait indefinitely
for a character to be received. Instead let getc() do any necesary
locking.

Add support for scc(4).

Replace our local UART_SIGMASK_* with the global SER_MASK_*.

MFp4:
Stop using our local UART_IPEND_* and instead use the global SER_INT_*
as defined in <sys/serial.h>.

Start each of the license/copyright comments with /*-, minor shuffle of lines

Include the common <dev/ic/ns16550.h> instead of the private
<dev/uart_dev_ns8250.h>. The latter can be removed now.

Be slightly more paranoid about using the divisor in a division and
the calculated baudrate. Neither should be 0.

Implement UART_IOCTL_BAUD. Consequently, when the baudrate was unset
for the console, we emit the actual baudrate during bus enumeration.

Do not use hardware flow control for the moment. There are some issues
with it that need to be understood better before they can be resolved.
This takes time and time is already in short supply.

Reported & tested by: glebius@

When sizing the FIFO, don't count all the way up to 1030 if any FIFO
size larger than 128 is considered an incompatible size. Stop counting
when we reach 130 in the loop.

Use the new serial port definitions for modemsignals.

It seems that clearing the MCR_IE bit in the modem control register
does not reliably prevent the triggering of interrupts for all supported
configurations. Thus, the FIFO size probe could cause an interrupt,
which could lead to an interrupt storm in the shared interrupt case.

To prevent this, change ns8250_bus_probe() to use the overflow bit in
the line status register instead of the RX ready bit in the interrupt
identification register to detect whether the FIFO has filled up.
This allows us to clear all bits in the interrupt enable register during
the probe, which should prevent interrupts reliably.
Additionally, the detected FIFO size may be a bit more accurate, because
the overflow bit is only set when the FIFO did actually fill up, while
interrupts would trigger a bit early.

Reviewed and tested on a lot of hardware by: marcel

In ns8250_putc() insert a barrier between writing the character and
checking for transmitter empty.

In uart_intr() loop until all interrupts have been handled. Previously
an UART interface could get stuck when a new interrupt condition
arose while servicing a previous interrupt. Since an interrupt was
already pending, no new interrupt would be triggered.

Avoid infinite recursion by flushing the Rx FIFO and marking an
overrun condition when we could not move the data from the Rx
FIFO to the receive buffer in toto. Failure to flush the Rx FIFO
would leave the Rx ready condition pending.

Note that the SAB 82532 already did this due to the nature of the
chip.

Add locking to the hardware drivers. I intended to figure out more
precisely where locking would be needed before adding it, but it
seems uart(4) draws slightly too much attention to have it without
locking for too long.
The lock added is a spinlock that protects access to the underlying
hardware. As a first and obvious stab at this, each method of the
hardware interface grabs the lock. Roughly speaking this serializes
the methods. Exceptions are the probe, attach and detach methods.

Add support for automatic hardware flow control for 16[679]50 UARTs.
We simply use the detected FIFO size to determine whether we have
a post 16550 UART or not. The support lacks proper serialization of
hardware access for now.

If we failed to size the Rx FIFO, assume the worst. This however
is not a size of 1. Since we already know there is a FIFO, we can
safely assume that it is at least 16 bytes. Note that all this is
mostly academic anyway. We don't use the size of the Rx FIFO
currently. If we add support for hardware flow control, we only
care about Rx FIFO sizes larger than 16.

The uart(4) driver is an universal driver for various UART hardware.
It improves on sio(4) in the following areas:
o Fully newbusified to allow for memory mapped I/O. This is a must
for ia64 and sparc64,
o Machine dependent code to take full advantage of machine and firm-
ware specific ways to define serial consoles and/or debug ports.
o Hardware abstraction layer to allow the driver to be used with
various UARTs, such as the well-known ns8250 family of UARTs, the
Siemens sab82532 or the Zilog Z8530. This is especially important
for pc98 and sparc64 where it's common to have different UARTs,
o The notion of system devices to unkludge low-level consoles and
remote gdb ports and provides the mechanics necessary to support
the keyboard on sparc64 (which is UART based).
o The notion of a kernel interface so that a UART can be tied to
something other than the well-known TTY interface. This is needed
on sparc64 to present the user with a device and ioctl handling
suitable for a keyboard, but also allows us to cleanly hide an
UART when used as a debug port.

Following is a list of features and bugs/flaws specific to the ns8250
family of UARTs as compared to their support in sio(4):
o The uart(4) driver determines the FIFO size and automaticly takes
advantages of larger FIFOs and/or additional features. Note that
since I don't have sufficient access to 16[679]5x UARTs, hardware
flow control has not been enabled. This is almost trivial to do,
provided one can test. The downside of this is that broken UARTs
are more likely to not work correctly with uart(4). The need for
tunables or knobs may be large enough to warrant their creation.
o The uart(4) driver does not share the same bumpy history as sio(4)
and will therefore not provide the necessary hooks, tweaks, quirks
or work-arounds to deal with once common hardware. To that extend,
uart(4) supports a subset of the UARTs that sio(4) supports. The
question before us is whether the subset is sufficient for current
hardware.
o There is no support for multiport UARTs in uart(4). The decision
behind this is that uart(4) deals with one EIA RS232-C interface.
Packaging of multiple interfaces in a single chip or on a single
expansion board is beyond the scope of uart(4) and is now mostly
left for puc(4) to deal with. Lack of hardware made it impossible
to actually implement such a dependency other than is present for
the dual channel SAB82532 and Z8350 SCCs.

The current list of missing features is:
o No configuration capabilities. A set of tunables and sysctls is
being worked out. There are likely not going to be any or much
compile-time knobs. Such configuration does not fit well with
current hardware.
o No support for the PPS API. This is partly dependent on the
ability to configure uart(4) and partly dependent on having
sufficient information to implement it properly.

As usual, the manpage is present but lacks the attention the
software has gotten.