aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/uart/uart_cpu_acpi.c
Commit message (Collapse)AuthorAgeFilesLines
* Kill ignore regshft flagWarner Losh2025-01-151-12/+0
| | | | | | | | | | | | This flag was introduced to ignore bad firmware values. These were present in older versions of EDK-II that many devices (both Ampere and Amazon) used. QEMU also used this value, but fixed it. But since it's tied to the firmware bug not the device name ID it doesn't make sense to have it flagged there. Sponsored by: Netflix Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D47947
* uart: Implement SPCR rev 3 and 4 for PreciseBaudrate and UartClkFreqWarner Losh2024-10-151-21/+39
| | | | | | | | | If we have a new enough SPCR, then use it when it provides a PreciseBaudrate and/or a UartClkFreq. Sponsored by: Netflix Reviewed by: andrew,adrian Differential Revision: https://reviews.freebsd.org/D47097
* uart: Add a signal to compute rclk from baudrateWarner Losh2024-10-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | With newer, more diverse hardware designs, the rclk can be unknown. Currently deployed systems have no standard way to discover the baud-clock generator frequency. However, sometimes we have a fairly good idea that the firmware programmed the UART to be the baud rate that it's telling us it's at. Create a way to instruct the uart class drivers to compute the baud clock frequency the first time their init routines are called. Usually the 'divisors' are relatively small, meaning we will likely have a fairly large error (goes as 1 / (divisor + 1). However, we also know that the baud-generator clock needs to be divided down to the baud-rate +/- about 5% (so while the error could be large for an arbitrary baud-clock, standard baud rates generally will give an error of 5% or less). Often, the console speed and the getty-configured speed are the same, so this heuristic allows boot messages and login sessions to work. Sponsored by: Netflix Reviewed by: andrew Differential Revision: https://reviews.freebsd.org/D47072
* uart: Fix cut-n-paste error in DBG2 codeWarner Losh2024-10-111-1/+1
| | | | | | | This code is parsing the DBG2 ACPI table, not the SPCR table, so tweak the comment. Sponsored by: Netflix
* uart: Use uintptr_t instead of vm_offset_t for pointer arithmeticJohn Baldwin2024-09-041-5/+5
| | | | | | | Reviewed by: imp Obtained from: CheriBSD Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D46490
* uart: DBG2 support to find the debug uartAndrew Turner2024-05-171-0/+83
| | | | | | | | | | | The Debug Port Table 2 (DBG2) contains information on which devices can be used for debugging purposes. Add support to the uart driver to use the DBG2 table when enabled from loader. Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D44359
* uart: Add uart_cpu_acpi_setup to setup the uartAndrew Turner2024-03-181-5/+11
| | | | | | | | | In preperation for adding debug port support add a generic function to setup the uart from ACPI tables. Reviewed by: imp Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D44358
* uart: Split out initilisation of the acpi devinfoAndrew Turner2024-03-181-37/+49
| | | | | | | | | | Split out the common parts of building the uart devinfo from ACPI tables from the SPCR parser. This will be used when we support the DBG2 table to find the debug uart to be used by the kernel gdb stub. Reviewed by: imp Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D44357
* sys: Automated cleanup of cdefs and other formattingWarner Losh2023-11-271-1/+0
| | | | | | | | | | | | | | | | Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row. Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/ Sponsored by: Netflix
* sys: Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-161-2/+0
| | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
* spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDWarner Losh2023-05-121-1/+1
| | | | | | | | | The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
* uart(4): Add a concept of "unique" serial devicesColin Percival2022-03-311-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FreeBSD detects serial ports twice: First, very early in the boot process, in order to obtain a usable console; and second, during the device probe/attach process. When a UART is discovered during device probing, FreeBSD attempts to determine whether it is a device which was already being used as a console; without this, the console doesn't work in userland. Unfortunately it's possible for a UART to be mapped to a different location in memory when it is discovered on a bus than it has when it is announced via the ACPI SPCR table; this breaks the matching process, which relies on comparing bus addresses. To address this, we introduce a concept of "unique" serial devices, i.e. devices which are guaranteed to be present *only once* on any system. If we discover one of these during device probing, we can match it to a same-PCI-vendor-and-device-numbers console which was announced via the ACPI SPCR table, regardless of the differing bus addresses. At present, the only unique serial device is the "Amazon PCI serial device" (vendor 0x1d0f, device 0x8250) found in some EC2 instances. This unbreaks the serial console on those systems. Reviewed by: imp MFC after: 3 days Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D34703
* Fix AccessWidth and BitWidth parsing in SPCR tableMarcin Wojtas2020-06-241-4/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI Specification defines a Generic Address Structure (GAS), which is used to describe UART controller register layout in the SPCR table. The driver responsible for parsing it (uart_cpu_acpi) wrongly associates the Access Size field to the uart_bas's regshft and the register BitWidth to the regiowidth - according to the definitions it should be opposite. This problem remained hidden most likely because the majority of platforms use 32-bit registers (BitWidth) which are accessed with the according size (Dword). However on Marvell Armada 8k / Cn913x platforms, the 32-bit registers should be accessed with Byte granulity, which unveiled the issue. This patch fixes above by proper values assignment and slightly improved parsing. Note that handling of the AccessWidth set to EFI_ACPI_6_0_UNDEFINED is needed to work around a buggy SPCR table on EC2 x86 "bare metal" instances. Reviewed by: manu, imp, cperciva, greg_unrelenting.technology Obtained from: Semihalf MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25373 Notes: svn path=/head/; revision=362574
* uart_cpu_acpi: Fix GCC build break from r348195Conrad Meyer2019-05-231-3/+0
| | | | | | | | | | extern declarations are redundant with those in uart_cpu.h, which this file includes. X-MFC-with: r348195 Notes: svn path=/head/; revision=348198
* Use ACPI SPCR on x86Colin Percival2019-05-231-0/+167
This takes the SPCR code currently in uart_cpu_arm64.c, moves it into a new uart_cpu_acpi.c (with some associated refactoring), and uses it from both arm64 and x86. An SPCR serial port address AccessWidth field value of 0 ("reserved") is now treated as 1 ("byte access") in order to work around a buggy SPCR table on Amazon EC2 i3.metal instances. Reviewed by: manu, Greg V MFC after: 3 days Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D20357 Notes: svn path=/head/; revision=348195
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-10 06:50:03 +0000