Initially there was only one DSI bridge with one panel attached to this
device. This explained the call to uclass_first_device_err(UCLASS_PANEL,
...) which worked fine at the time.
Now that multiple bridges and panels, with different technologies, can
be plugged onto the board this way to get the panel device is outdated.
The lookup is done is two steps. First we circle through the
UCLASS_VIDEO_BRIDGE, and once we get one, we search through its
endpoints until we get a UCLASS_PANEL device available.
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
STM32MP2 SoCs feature a new version of the LTDC IP. This new version
features a bus clock, as well as a 150MHz pad frequency. Add its
compatible to the list of device to probe and handle quirks. The new
hardware version features a bus clock.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
The LVDS Display Interface Transmitter handles the LVDS protocol:
it maps the pixels received from the upstream Pixel-DMA (LTDC)
onto the LVDS PHY.
The LVDS controller driver supports the following high-level features:
• FDP-Link-I and OpenLDI (v0.95) protocols
• Single-Link or Dual-Link operation
• Single-Display or Double-Display (with the same content
duplicated on both)
• Flexible Bit-Mapping, including JEIDA and VESA
• RGB888 or RGB666 output
• Synchronous design, with one input pixel per clock cycle
• No resolution limitation.
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Add the compatible "panel-lvds" for simple-panel driver in U-Boot. In
Linux this compatible is managed by the driver
drivers/gpu/drm/panel/panel-lvds.c but in U-Boot the specific LVDS
features (bus_format/bus_flags) are not supported.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
The "Display Timings" in panel-common.yaml can be provided by 2 properties
- panel-timing: when display panels are restricted to a single resolution
the "panel-timing" node expresses the required timings.
- display-timings: several resolutions with different timings are supported
with several timing subnode of "display-timings" node
This patch update the parsing function to handle this 2 possibility
when index = 0.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Add support of STM32 ADCs to STM32MP13x. This patch introduces
stm32_adc_regspec structure, as this is already done in kernel
driver, to manage smartly the differences in register set
between STMP32MP15 and STM32MP13 ADCs.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.
The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.
Signed-off-by: Tom Rini <trini@konsulko.com>
Hrushikesh Salunke <h-salunke@ti.com> says:
This series enables PCIe Endpoint mode on TI's J784S4 SoC. The J784S4
SoC features two Cadence PCIe controller instances (PCIe0 and PCIe1)
that can operate in endpoint mode. This series adds support for
configuring these controllers with up to 4 lanes.
Key changes include:
- Adding a stabilization delay after power domain reset to prevent
timing-related initialization issues
- SERDES mux configuration support for proper lane routing, which is
essential for SoCs where SERDES lanes are shared between multiple
controllers (PCIe, USB, etc.) with different configurations across
boot phases
- J784S4 SoC endpoint configuration with 4-lane support
- Disabling unconfigured endpoint functions to prevent enumeration
issues on the Root Complex side
This series has been tested on J784S4 EVM with PCIe endpoint boot
configuration. Following are the corresponding test logs.
https://gist.github.com/hrushikesh221/331d65f45f43fd138f57e6adb61c4332
Link: https://lore.kernel.org/r/20251023114604.3655625-1-h-salunke@ti.com
Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> says:
This patch series adds basic support for the boards based on Airoha
EN7523/EN7529/EN7562 SoCs. Due to ATF restrictions these boards are
able to run 32-bit OS only.
This patch series adds support for the following hardware:
* console UART
* ethernet controller/switch
* spinand flash (in non-dma mode)
The following issues may be expected:
* Extra slow UBI attaching in U-Boot (up to 20 sec with fastmap enabled).
This is caused by the lack of DMA support in the U-Boot airoha-snfi driver.
* Linux airoha-snfi driver in some cases might damage you flash data
(see: https://lore.kernel.org/lkml/20251012121707.2296160-15-mikhail.kshevetskiy@iopsys.eu/)
* Latest linux kernel is recommended to properly support flashes
with more than one plane per lun
(see: https://lore.kernel.org/lkml/20251012121707.2296160-7-mikhail.kshevetskiy@iopsys.eu/)
* It's NOT recommended to use flashes working in continuous mode because
U-Boot airoha-snfi driver does not support such flashes properly.
The patches was tested on the board:
- SoC: Airoha EN7562
- RAM: 512 MB
- SPI NAND: 4 Gbit, made by Toshiba
- Linux boot: was NOT tested
The U-Boot was chain-loaded from the running U-Boot. Airoha ATF-2.3 does
not allow easily chain-loading of U-Boot from U-Boot, so a special FIT
image (mimic linux kernel) was created
1) Create u-boot.its file with the following contents:
=== cut here ===
/dts-v1/;
/ {
description = "ARM OpenWrt FIT (Flattened Image Tree)";
#address-cells = <1>;
images {
u-boot-ram {
description = "OpenWrt U-Boot RAM image";
data = /incbin/("u-boot.bin.lzma");
type = "kernel";
arch = "arm";
os = "linux";
compression = "lzma";
load = <0x81e00000>;
entry = <0x81e00000>;
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};
fdt-1 {
description = "OpenWrt device tree blob";
data = /incbin/("dts/upstream/src/arm/airoha/en7523-evb.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1 {
algo = "crc32";
};
hash@2 {
algo = "sha1";
};
};
};
configurations {
default = "config-ram-uboot";
config-ram-uboot {
description = "OpenWrt RAM U-Boot";
kernel = "u-boot-ram";
fdt = "fdt-1";
};
};
};
==================
2) Create u-boot.itb image to chain-load new u-boot from the old one
lzma_alone e u-boot.bin u-boot.bin.lzma
mkimage -f u-boot.its u-boot.itb
3) Load new u-boot from the old one
U-Boot> tftpboot u-boot.itb && bootm
Link: https://lore.kernel.org/r/20251101004503.2379529-1-mikhail.kshevetskiy@iopsys.eu
TI's J784S4 SoC has two instances of PCIe Controller namely PCIe0 and
PCIe1 which are Cadence PCIe Controllers. Add support to configure PCIe
instances in Endpoint mode of operation.
While at it disable all endpoint functions except function 0 during
probe to prevent the Root Complex from enumerating unconfigured
functions. This ensures only properly configured endpoint functions
are visible to the host and avoids enumeration issues with
multi-function devices.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Probe the mux device early in the SERDES configuration flow to ensure
proper lane routing before PHY initialization. This is required for SoCs
where SERDES lanes can be muxed between different controllers
(PCIe, USB, etc), and different mux configurations are required between
different boot phases.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Add a 1ms delay after powering on the PCIe power domain to ensure
the controller stabilizes before subsequent operations. This prevents
potential timing issues during PCIe endpoint initialization.
The delay allows sufficient time for the power domain to fully come
up and the hardware to be in a stable state before configuration
begins.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
This allow us remove some an7581/an7583 specific code and use a common
code instead.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
This patch unify probing code using airoha SCU regmap helper, thus a
common function can be used instead of an7581/an7583 specific ones.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
In preparation for support for Airoha AN7583, convert the driver to
regmap API. This is needed as Airoha AN7583 will use syscon to access
reset registers.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This adds clock driver for airoha en7523/en7529/en7562 SoCs. The code
is based on corresponding linux driver.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Clean up the sound Kconfig options to let all sound devices depend on
CONFIG_SOUND.
Before this patch it was possible to select CONFIG_SOUND_MAX98357A even
with CONFIG_SOUND=n.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Quentin Schulz <foss+uboot@0leil.net> says:
This improves readability in menuconfig by putting PWM symbols under a
Kconfig menu.
It also groups PWM symbols that depend on DM_PWM together under an if
DM_PWM block so that we don't need to always list the dependency in the
depends on of the symbol.
No intended change in behavior except how it shows in menuconfig.
Link: https://lore.kernel.org/r/20251030-pwm-kconfig-v2-0-d151a42784ce@cherry.de
This simplifies the "depends on" since we don't need DM_PWM listed
explicitly there as it already is made explicit via the surrounding
"if". No intended change in behavior.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Since it is registered as a U_CLASS_DRIVER, Sandbox PWM driver is a
Driver Model Driver and thus to be usable depends on DM_PWM to be
selected.
Let's make sure of that via the appropriate Kconfig option.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
So it's visually better split from the other subsystems when using
menuconfig.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Add support for R-Car Gen5 SoCs into the driver.
The default quirk is identical to previous generation.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Tweak commit message
Some shared memory mailboxes may have empty receive operation,
because the data are polled by upper layers directly from the
shared memory region, and there is no completion interrupt or
bit of any sort. Allow empty .recv callback, and if the .recv
callback is empty, exit from mbox_recv() right away, because
any polling for completion here would be meaningless.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Isolate Renesas R-Car Gen3 clock driver to R-Car Gen3 and Gen4 and RZ/G2L.
The Renesas R-Car Gen5 uses SCMI clock protocol driver instead. This is
a preparatory change for R-Car Gen5. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Pull request efi-2026-01-rc2
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28208
Documentation:
* bootstd: Describe environment variable extension_overlay_addr
environment and remove extension support from TODO list
EFI:
* Correct the detection of the video mode in the EFI payload app:
- Use struct efi_gop_mode_info in the definition of struct
efi_entry_gopmode.
- In function get_mode_from_entry() use the correct type for the video
mode structure.
* Use a valid error code as return value in efi_store_memory_map().
* Avoid a memory leak for the variable name in efi_bl_create_block_device().
* Correct the code indentation in efi_uc_stop().
* Correct the description of struct efi_priv.
* Fix typos in code comments.
Other:
* qfw: Add more fields and a heading to qfw list
* Fix the support for ACPI pass-through on ARM and RISC-V:
Avoid zeroing out the XSDT address
* test: provide unit test for 'acpi list' command
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmkNj/kACgkQxIHbvCwF
# GsS8NQ/6Aj+Z54HJTIEfoXssvElLr5ATactrCxszq42i/yy6dLqa2Ym1afG6w1XS
# 1ZbCeU/bCXFke5Tsz+x89gEfckUm83oTwngwcID0WR1qn8mWjwR7tM5MuORq8NxU
# 7NwLuFs9O/QZihagKdz6hv1/Y+cBwiAYLY16EYVSuUlbLaKQo3QvxwWkqG3jdKWV
# Rm58/PolU+2h04MBwP0SxSduX4OyRF/tMOGjf5RGLyqCyj8kIgdu7PvUAPMM+Gps
# KemL59V0Bdv8hlF4JknmPz+idtZg2nHIDdNrBZvoxwzwGQeRZ1YXAMruRxZXqDYL
# tiuDp6HMv/GfIIGkz14tJtJMdboaAybAnluPWGalx8JQJqJzEPww0R+9s4KKQeWL
# mHgRyl6PxVV9p19f79Qq6q6ETwrFDX0YH3pdrGUk3DBa3lDt0UsEAnuW4FvaJ8tx
# 3PMrjKAxpxocT0hglsMVnptnfvDEigMsjwH/TWrau83mY+juxFQLjm+U4vye+qCa
# 4zXjjLas18+eRcrv2KxU7teakyi1Jp+WbqHq37L26YcQMaLq/RkBc0bTrsreKKLu
# jprYFpvc7EJpH2Fd1XWaZ2EnxXcVSJSvrY/iwRQqb6wbwQ6XGtMvSh3IFY8IzAoh
# N2Pj78oaYqyL1q/TftuZWhEHo3a0M/HfM4D+oMSHzJtWCb0wZHE=
# =OGcS
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 07 Nov 2025 12:21:45 AM CST
# gpg: using RSA key 6DC4F9C71F29A6FA06B76D33C481DBBC2C051AC4
# gpg: Good signature from "Heinrich Schuchardt <xypron.glpk@gmx.de>" [unknown]
# gpg: aka "[jpeg image of size 1389]" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4
Add DWMCI_QUIRK_DISABLE_FMP flag to Exynos850 driver data to make the
driver disable FMP in case of Exynos850 chip. That makes eMMC on
Exynos850 functional when U-Boot is executed during USB boot.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Up until now "samsung,exynos7-dw-mshc-smu" compatible was used for
Exynos850 SoC, as it's present in its device tree. But Exynos850 device
tree also supports "samsung,exynos850-dw-mshc-smu" compatible string.
Add it in compatible ID list in the driver so that it can be matched
against this string for Exynos850 device tree.
No functional change, as the driver data is just a copy of
"samsung,exynos7-dw-mshc-smu" data for now.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add DWMCI_QUIRK_DISABLE_FMP which disables Flash Memory Protector (FMP)
during driver's init. It's usually done by early bootloaders, but in
some cases (like USB boot) the FMP may be left unconfigured. The issue
was observed on Exynos850 SoC (the E850-96 board). Enabling this quirk
makes eMMC functional even in such cases.
No functional change, as this feature is only added here but not enabled
for any chips yet.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Exynos DW MMC glue layer driver have seen a lot of changes recently.
Stabilize the coding style.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Do not over-expose the private dw_mmc API. The glue layer drivers at
this point shouldn't be aware and shouldn't use the generic
dwmci_send_cmd() and dwmci_set_ios() functions. Making those functions
public causes a "leaky abstraction" issue. It clutters the public
interface of generic dw_mmc driver and possibly leads to improper usage
of those functions, so it's a bad design.
If struct dm_dwmci_ops has to be extended, do so by copying it first
(like it's done for example in snps_dw_mmc driver). That also makes sure
the future changes to struct dm_dwmci_ops in dw_mmc driver will be
automatically reflected in all extended copies, and avoid code
duplication.
This effectively reverts commit ef3b16bb8e73 ("mmc: dw_mmc: export
dwmci_send_cmd() and dwmci_set_ios()").
No functional change.
Fixes: ef3b16bb8e73 ("mmc: dw_mmc: export dwmci_send_cmd() and dwmci_set_ios()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Instead of extending dm_dwmci_ops by copy-pasting the structure code
first, copy the actual structure data with memcpy() and then set the
.execute_tuning field. Now if struct dm_dwmci_ops gets modified in
future, these changes will be automatically reflected in struct
exynos_dwmmc_ops, which prevents possible issues in future. It also
avoids code duplication.
No functional change, but it can prevent possible isssues in future.
Fixes: eda4bd29929c ("mmc: exynos_dw_mmc: add support for MMC HS200 and HS400 modes")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
I have a hunch VPL_DM_SERIAL should not be selectable if VPL isn't set
as implied by the prefix. Additionally, still based on the prefix, I'm
assuming VPL_DM should be a dependency. Since VPL_DM can only be
selectable when VPL is enabled, only depend on VPL_DM.
This mirrors SPL_DM_SERIAL and TPL_DM_SERIAL so seems right to me.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently, the EFI framebuffer is non-functional in payload mode. It
always reports: "No video mode configured in EFI!"
This is caused by a copy-paste error that replaced
"struct efi_entry_gopmode" with "struct efi_gop_mode".
Fixes: 88753816cf ("efi: video: Move payload code into a function")
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
On RISC-V QEMU provides an XSDT table. The RSDP table points to it.
We must not zero out this pointer because otherwise no ACPI table can be
found.
Fixes: 15ca25e31e ("x86: emulation: Support BLOBLIST_TABLES properly")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add initial pin control tables for the Renesas R-Car X5H R8A78000 SoC.
This SoC is the first one which includes custom DRV register handling,
different from previous generations due to change in DRV register bit
layout.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Khanh Le <khanh.le.xr@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The upcoming Renesas R-Car Gen5 uses different mapping of bits in DRV
control register, which is incompatible with existing DRV register bit
mapping. Add .set_drive_strength callback into sh_pfc_soc_operations
and call it from sh_pfc_pinconf_set(), to allow each SoC specific PFC
driver to implement replacement .set_drive_strength. Make the current
sh_pfc_pinconf_set_drive_strength() non-static, rename it with rcar_
prefix, and pass it as .set_drive_strength for existing PFC drivers.
This is a preparatory patch for R-Car Gen5, no functional change.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Consistently use .set_drive_strength() and pass exisiting
sh_pfc_pinconf_set_drive_strength() as its parameter for
all PFC drivers. Rewrite commit message.]
Show bit position in config write debug log, which is helpful for cases
where the p port setting is applied at the exact p bit position.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Unsplit the string
Fix Kconfig entry indent to be always consistently indented with
leading tabs, never with leading spaces. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add support for the GPIO controller block in the R-Car Gen5 SoC family.
The GPIO controller has a General Input Enable Register (INEN), whose
reset state is to have all input disabled. The GPIO controller also has
updated offsets for its control registers. U-Boot uses three registers,
INDT, POSNEG, INEN, which have updated offsets, those are handled by the
driver.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: - Access Gen5 specific registers via driver data offsets,
- Update commit message]
