FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F12.3.0 2020-09-08T22:50:24Z 2020-09-08T22:50:24Z John Baldwin jhb@FreeBSD.org 2020-09-08T22:50:24Z urn:sha1:13ccf661f6633628bf977612b86b6b638f0b5273 uart(4) backends currently detect RX FIFO overrun errors and report them to the uart(4) core layer. They are then reported to the generic TTY layer which promptly ignores them. As a result, there is currently no good way to determine if a uart is experiencing RX FIFO overruns. One could add a generic per-tty counter, but there did not appear to be a good way to export those. Instead, add a sysctl under the uart(4) sysctl tree to export the count of overruns. 2019-05-28T22:22:40Z Colin Percival cperciva@FreeBSD.org 2019-05-28T22:22:40Z urn:sha1:92182fab8a21dc8f5356ffe82a6562b99b8a8516 r345405: Obey SPCR AccessWidth parameter. r345406: Initialize uart_bus_space_mem on arm64. r346228: Add quirk to ignore AccessWidth on PL011 UART. r346657: Handle SPCR BaudRate = 0. r348195: Extract arm64 SPCR code and make it MI; use on x86 too. r348198: Fix for r348195. This unbreaks the console on EC2 a1.* and *.metal instances. Sponsored by: https://www.patreon.com/cperciva 2018-08-19T21:10:21Z Matt Macy mmacy@FreeBSD.org 2018-08-19T21:10:21Z urn:sha1:381388b9c48b07b08199b07b7657d46e8fcb59b0 This is an amalgam of a patch by Doug Ambrisko to generalize uart_acpi_find_device, imp moving the ACPI table to uart_dev_ns8250.c and advice by jhb to work around a bug in the EPYC 3151 BIOS (the BIOS incorrectly marks the serial ports as disabled) Reviewed by: imp MFC after: 8 weeks Differential Revision: https://reviews.freebsd.org/D16432 2017-11-27T14:52:40Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-27T14:52:40Z urn:sha1:718cf2ccb9956613756ab15d7a0e28f2c8e91cab Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. 2017-02-27T20:08:42Z Ruslan Bukin br@FreeBSD.org 2017-02-27T20:08:42Z urn:sha1:c214a270f501ce3711165c0d18f55733bcc0ca93 This is required for FDT's standard "reg-io-width" property (similar to "reg-shift" property) found in many DTS files. This fixes operation on Altera Arria 10 SOC Development Kit, where standard ns8250 uart allows 4-byte access only. Reviewed by: kan, marcel Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D9785 2016-01-12T18:42:00Z Ian Lepore ian@FreeBSD.org 2016-01-12T18:42:00Z urn:sha1:fdfbb3f5b1b6199051e3421609c783b216cef6e5 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 2015-08-10T20:08:09Z Ian Lepore ian@FreeBSD.org 2015-08-10T20:08:09Z urn:sha1:196d3019a834a737ca8354fb37e801b999299d19 eliminating the need to build a custom kernel to use the CTS signal. The historical UART_PPS_ON_CTS kernel option is still honored, but now it can be overridden at runtime using a tunable to configure all uart devices (hw.uart.pps_mode) or specific devices (dev.uart.#.pps_mode). The per- device config is both a tunable and a writable sysctl. This syncs the PPS capabilities of uart(4) with the enhancements recently recently added to ucom(4) for capturing from USB serial devices. Relnotes: yes 2015-08-08T20:11:47Z Ian Lepore ian@FreeBSD.org 2015-08-08T20:11:47Z urn:sha1:b59236ceceb2864cedcb2a4c9b9db58f63be9eea time_pps_fetch() to be used in blocking mode. Also, don't init the pps api for system devices (consoles) that provide a custom attach routine. The device may actually be a keyboard or other non- tty device. If it wants to do pps processing (unlikely) it must handle everything for itself. (In reality, only a sun keyboard uses a custom attach routine, and it doesn't make a good pps device.) 2015-07-24T17:01:16Z Marius Strobl marius@FreeBSD.org 2015-07-24T17:01:16Z urn:sha1:86fb54003393c8c3c586df44fc31d7861e121ef3 uart_bus_attach() during its test that 20 iterations weren't sufficient for clearing all pending interrupts, assuming this means that hardware is broken and doesn't deassert interrupts. However, under pressure, 20 iterations also can be insufficient for clearing all pending interrupts, leading to a panic as intr_event_handle() tries to schedule an interrupt handler not registered. Solve this by introducing a flag that is set in test mode and otherwise restores pre-r253161 behavior of uart_intr(). The approach of additionally registering uart_intr() as handler as suggested in PR 194979 is not taken as that in turn would abuse special pccard and pccbb handling code of intr_event_handle(). [1] - Const'ify uart_driver_name. - Fix some minor style bugs. PR: 194979 [1] Reviewed by: marcel (earlier version) MFC after: 3 days 2015-04-11T17:16:23Z Andrew Turner andrew@FreeBSD.org 2015-04-11T17:16:23Z urn:sha1:405ada37fbdafaa6691a906f3630ba8d064e5f30 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