u-boot.git/drivers/serial, branch v2025.04 Unnamed repository; edit this file 'description' to name the repository. serial: ns16550: Add Intel XScale support 2025-01-28T08:08:44+00:00 Duje Mihanović duje.mihanovic@skole.hr 2025-01-24T15:47:48+00:00 2d84e1519c5bed8ac21057531799f3f29c897f17 Add compatible string for the Intel XScale variant of the 16550. Needed to match upstream. Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr> Reviewed-by: Stefan Roese <sr@denx.de> 
Add compatible string for the Intel XScale variant of the 16550. Needed
to match upstream.

Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
Merge patch series "upl: Prerequite patches for updated spec" 2025-01-22T23:08:47+00:00 Tom Rini trini@konsulko.com 2025-01-22T22:08:34+00:00 a3b71cc6f5cc74d4edc5808790a3d2999ea3f7fe Simon Glass <sjg@chromium.org> says: The current UPL spec[1] has been tidied up and improved over the last year, since U-Boot's original UPL support was written. This series includes some prerequisite patches needed for the real UPL patches. It is split from [2] [1] https://github.com/UniversalPayload/spec/tree/3f1450d [2] https://patchwork.ozlabs.org/project/uboot/list/?series=438574&state=* Link: https://lore.kernel.org/r/20250111000029.245022-1-sjg@chromium.org 
Simon Glass <sjg@chromium.org> says:

The current UPL spec[1] has been tidied up and improved over the last
year, since U-Boot's original UPL support was written.

This series includes some prerequisite patches needed for the real UPL
patches. It is split from [2]

[1] https://github.com/UniversalPayload/spec/tree/3f1450d
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=438574&state=*

Link: https://lore.kernel.org/r/20250111000029.245022-1-sjg@chromium.org
serial: Support info() method in ns16550 xPL with UPL 2025-01-22T21:58:03+00:00 Simon Glass sjg@chromium.org 2025-01-11T00:00:05+00:00 4219fd9a705dba1c066e02824514b9e4b13b8acf UPL needs to pass the serial details onto the next stage, so adjust the condition to support this. Signed-off-by: Simon Glass <sjg@chromium.org> 
UPL needs to pass the serial details onto the next stage, so adjust the
condition to support this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Merge tag 'v2025.01-rc5' into next 2024-12-26T04:31:04+00:00 Tom Rini trini@konsulko.com 2024-12-26T04:31:04+00:00 5cfbf8c3644cc95c3c8b5d2541ed7f32136c0da1 Prepare v2025.01-rc5 
Prepare v2025.01-rc5
drivers: serial: serial_omap: Fix TI OMAP UART U-Boot driver to support higher baudrates 2024-12-14T15:32:59+00:00 Gokul Praveen g-praveen@ti.com 2024-11-26T10:51:31+00:00 50cc0c16b7cc3a3a6d8bca646678e14aaa7cc794 Move to OMAP specific implementation of certain ops functions as the UART prints on the serial console fail for baudrates greater than 460800. The MDR1 register is responsible for determining the speed mode at which the UART should operate for OMAP specific devices. The baud divisor is used to set the UART_DLL register which is used for generation of the baud clock in the baud rate generator. The implementation logic is similar to how it is implemented in omap_8250_get_divisor function of 8250_omap UART linux driver. Signed-off-by: Gokul Praveen <g-praveen@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Move to OMAP specific implementation of certain ops functions as the UART
prints on the serial console fail for baudrates greater than 460800.

The MDR1 register is responsible for determining the speed mode at which
the UART should operate for OMAP specific devices. The baud divisor is used
to set the UART_DLL register which is used for generation of the baud
clock in the baud rate generator. The implementation logic is similar to
how it is implemented in omap_8250_get_divisor function of 8250_omap UART
linux driver.

Signed-off-by: Gokul Praveen <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
serial: ns16550: Increase scope of ops functions 2024-12-14T15:32:59+00:00 Gokul Praveen g-praveen@ti.com 2024-11-26T10:51:30+00:00 a9c61ac04fdef8de7842456ff597db375f8b48d8 Increase scope of ops functions and do some clean up for usage in device -specific UART drivers. Remove the static functionality of ops functions and migrate certain macros to header file for usage in device-specific drivers. Signed-off-by: Gokul Praveen <g-praveen@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Increase scope of ops functions and do some clean up for usage in device
-specific UART drivers.

Remove the static functionality of ops functions and migrate certain macros
to header file for usage in device-specific drivers.

Signed-off-by: Gokul Praveen <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
serial: renesas: Fix R-Car spelling 2024-12-11T07:36:24+00:00 Marek Vasut marek.vasut+renesas@mailbox.org 2024-12-11T07:30:35+00:00 b1c2886cf2ac34d76795500018fba79adef91b1d The correct spelling is R-Car, including the dash, update the usage. Kconfig strings and comment changes only, no functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> 
The correct spelling is R-Car, including the dash, update the usage.
Kconfig strings and comment changes only, no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Merge patch series "Implement ACPI on aarch64" 2024-10-28T00:44:13+00:00 Tom Rini trini@konsulko.com 2024-10-27T23:14:22+00:00 2800aecce08b47b169d8e9824dd23b1297b2cedc Patrick Rudolph <patrick.rudolph@9elements.com> says: Based on the existing work done by Simon Glass this series adds support for booting aarch64 devices using ACPI only. As first target QEMU SBSA support is added, which relies on ACPI only to boot an OS. As secondary target the Raspberry Pi4 was used, which is broadly available and allows easy testing of the proposed solution. The series is split into ACPI cleanups and code movements, adding Arm specific ACPI tables and finally SoC and mainboard related changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the mandatory ACPI tables are supported, allowing to boot into Linux without errors. The QEMU SBSA support is feature complete and provides the same functionality as the EDK2 implementation. The changes were tested on real hardware as well on QEMU v9.0: qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \ -pflash secure-world.rom \ -pflash unsecure-world.rom qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \ -smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \ -dtb bcm2711-rpi-4-b.dtb -nographic Tested against FWTS V24.03.00. Known issues: - The QEMU rpi4 support is currently limited as it doesn't emulate PCI, USB or ethernet devices! - The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly cache related). - PCI on RPI4 isn't working on real hardware since the pcie_brcmstb Linux kernel module doesn't support ACPI yet. Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com 
Patrick Rudolph <patrick.rudolph@9elements.com> says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
serial: serial_pl01x: Implement .getinfo() for PL01 2024-10-27T23:24:12+00:00 Maximilian Brune maximilian.brune@9elements.com 2024-10-23T13:19:48+00:00 ea37e5064e20c63cbaa667cb8b81838d5bab65bb When ACPI is enabled on arm it will use the getinfo function to fill the SPCR ACPI table. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Moritz Fischer <moritzf@google.com> 
When ACPI is enabled on arm it will use the getinfo function to fill
the SPCR ACPI table.

Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
Merge patch series "some serial rx buffer patches" 2024-10-16T21:54:38+00:00 Tom Rini trini@konsulko.com 2024-10-16T21:54:38+00:00 98a36deb9ab7aaea70b0b0db47718100e08cf3e8 Rasmus Villemoes <ravi@prevas.dk> says: Some small improvements to the serial rx buffer feature. CI seems happy: https://github.com/u-boot/u-boot/pull/674 Link: https://lore.kernel.org/r/20241003141029.920035-1-ravi@prevas.dk 
Rasmus Villemoes <ravi@prevas.dk> says:

Some small improvements to the serial rx buffer feature.

CI seems happy: https://github.com/u-boot/u-boot/pull/674

Link: https://lore.kernel.org/r/20241003141029.920035-1-ravi@prevas.dk