This takes the SPCR code currently in uart_cpu_arm64.c, moves it into a new uart_cpu_acpi.c, and uses it from both arm64 and x86. (In the process there is some refactoring and I added some comments to help me understand the code.)
Details
Details
- Reviewers
val_packett.cool andrew manu - Commits
- rS348195: Use ACPI SPCR on x86
Test on EC2 i3.metal instance: Successful.
Test on EC2 A1 instances: Successful.
Test on other arm64 instances... hoping that someone can do this for me.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Tested on Ampere eMAG (along with WIP I brought over from @manu).
That same kernel did not boot on ThunderX2, but I do not know which specific changes were responsible.
| sys/dev/uart/uart_cpu_acpi.c | ||
|---|---|---|
| 132 ↗ | (On Diff #57708) | Lost comment about zero.. I guess it's not very valuable but still |
Comment Actions
That same kernel did not boot on ThunderX2
Oh, I tested without options NUMA so this is not surprising. @manu retesting on TX2 w/ NUMA
| sys/dev/uart/uart_cpu_acpi.c | ||
|---|---|---|
| 132 ↗ | (On Diff #57708) | I disagree, the spec says that value 0-2, 5, 8-255 are reserved so if we handle one of those value differently because $reason we should preserve the comment. |
Comment Actions
good for me, please just commit with the baudrate 0 comment preserved, I'm sure this will help someone in the future.
Comment Actions
please just commit with the baudrate 0 comment preserved
OK in my testing too, agreed on the comment.
| sys/dev/uart/uart_cpu_acpi.c | ||
|---|---|---|
| 132 ↗ | (On Diff #57708) | Which spec are you looking at? says "0 = as is, operating system relies on the current configuration of serial port until the full featured driver will be initialized." I'll add the comment back anyway... |