-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uart #1468
Open
bsdimp
wants to merge
22
commits into
freebsd:main
Choose a base branch
from
bsdimp:UART
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Uart #1468
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If rclk is set in sysdev, then it was set during the boot process and is intended to override the defaults. By prefering the sysdev one over the class, xo=XXXX in hw.uart.console can give the user a usable console for non-traditional UARTs, especially on !x86 platforms. The default rclk generally only is good for I/O mapped UARTS or PCI ones that we can do a table lookup on. Other times, it can be hard to know what a good default is without more information. Sponsored by: Netflix
To help debugging, export the rclk a uart is using as dev.uart.X.rclk. It can be opaque when it is wrong since any error messages printed to the system console using the wrong rclk aren't informative. Sponsored by: Netflix
Sponsored by: Netflix
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
It can be confusing when the ns8250 driver prints error messages with just ns8250 as the prefix. Add uart: to the live and commented out printfs. Sponsored by: Netflix
We have two copies (soon to be three) of reading the divisor. Since it's a complicated tricky process, abstract it to its own routine. Sponsored by: Netflix
Disable interrupts before we set the parameters for the UART. Usually, it makes no difference, but it's possible that setting the baud rate, etc could create problems if there's data pending, so move the interrupt disabling ealier. Sponsored by: Netflix
When instructed to do so, compute the rclk (baud rate generator clock) based on the currently programmed divisor and the communicated baud rate. We only do this once and only for consoles that tell us the configured rate and flag we can likely safely compute rclk. Sponsored by: Netflix
When instructed to do so, compute the rclk (baud rate generator clock) based on the currently programmed divisor and the communicated baud rate. We only do this once and only for consoles that tell us the configured rate and flag we can likely safely compute rclk. Sponsored by: Netflix
This allows one to specify dt:XXXX when the default class isn't compiled into the kernel. It's not an error to not have a class until we're done parsing the spec, so defer checking until then. Sponsored by: Netflix
Switch from the long obsolete hint.0.acpi.rsdp to acpi.rsdp to get the root of the ACPI tables. MFC After: 1 week Sponsored by: Netflix
In a couple of places, we use 4 instead of ACPI_NAMESEG_SIZE. Use the Sponsored by: Netflix
Clarify what's reported with -t (it's all the fixed acpi tables, not just the listed ones). The listed tables are more fully decoded, while all other tables just have their headers decoded. Sponsored by: Netflix
Sort the ACPI signatures alphabetically and move it into a table we can iterate through Sponsored by: Netflix
Add the ability to dump a specific ACPI table rather than all of them. Sponsored by: Netflix
Make rsdp pointer to the RSDP global so we can look up other tables. Sponsored by: Netflix
how is assumed to be 0, so we directly assign to it. It might not always be 0, so or-in these bits. Sponsored by: Netflix
If there's a SPCR, then use it to create and pass the right values to the uart. Ideally, I'd just pass this all in hw.uart.console, but old kernels completely ignore the value if there's any extra entries. So I have to pass newly invented values to replace kernel values in a new kenv hw.uart.console.extra. so we pass xo=-1 in to calcuate the xo from the baud rate, and pv and pd for PCI Vendor ID and PCI Device ID of the serial console to use. Old kernels will ignore this and completely get this data from parsing SPCR itself. New kernels will dig it our of here w/o needing to parse it. We don't support Rev3 or Rev4 SPCR yet. It's too new to be in real hardware yet. Sponsored by: Netflix
Two reasons for this: we know it's a uart after we call probe and it returns successfully. Second, uart passes data between probe and attach with softc. As it is now, we call probe twice, once in the bidding process and once after bidding id done. However, the probe process for uart isn't completely idempotent (we change state of the uart sometimes). The second call can result in odd behavior (though so far only in buggy version of other code I've not committed). The bigger problem is the softc: newbus creates it, we populate it, then frees it when we don't return 0 to claim the device. It then calls us again, we repopulate it, and this time it doesn't free it before calling attach. Returning 0 avoids both of these issues. The justification for doing it in the commit that changed it was 'while I'm here', so there doesn't seem to be a use case for it. Sponsored by: Netflix
We can get the UART clock from v3 SPCR, and a precise baudrate from v4. Some precise baudrates will currently be rejected by the kernel. Sponsored by: Netflix
If we have a new enough SPCR, then use it when it provides a PreciseBaudrate and/or a UartClkFreq. Sponsored by: Netflix
Sponsored by: Netflix
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ignore this, pushing to test