| Age | Commit message (Collapse) | Author |
|
Currently the implementation does not just skip all devices beside
device 0, it also skips all functions (besides 0) on device 0. This
broke basically all AMD platforms, since they have a lot of internal SOC
devices behind these functions.
This was detected, because the XHCI controller and therefore the USB
devices were not found by u-boot on AMD/crater platform.
PCI_MASK_BUS() returns both device and function bits, so it skips any
bdf where either device > 0 or function > 0. Using PCI_DEV() extracts
only the device number, matching the intent in only_one_child().
It therefore now checks all functions on device 0 (Linux does the same).
I build tested u-boot as coreboot payload and run it on a recent x86 AMD
platform. Devices like the XHCI controller are now found again.
Fixes: fbde868ba4aa ("pci: skip unnecessary PCIe scanning")
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
CC: Tom Rini <trini@konsulko.com>
CC: Andrew Goodbody <andrew.goodbody@linaro.org>
CC: George McCollister <george.mccollister@konsulko.com>
CC: Simon Glass <sjg@chromium.org>
|
|
Add support for the DesignWare-based PCIe host controller found in
AMD Versal2 SoCs. This enables PCIe functionality (e.g. NVMe storage)
on boards such as the VEK385.
The driver builds on the existing pcie_dw_common infrastructure and
adds Versal2-specific handling: it maps the SLCR register region to
mask and clear TLP interrupt status bits, parses dbi/config/atu/slcr
register regions from device tree, and supports an optional PERST#
GPIO on child nodes for endpoint reset sequencing. The outbound iATU
is programmed for the non-prefetchable memory window from device tree
ranges.
Signed-off-by: Pranav Sanwal <pranav.sanwal@amd.com>
Link: https://lore.kernel.org/r/20260327121015.996806-2-pranav.sanwal@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
The driver requests explicitly "reset-gpio" property, not the one with
"gpios" suffix but upstream Linux kernel deprecated it in 2021.
Existing upstream Linux kernel DTS is being changed to "reset-gpios"
property, thus update the driver to read that one too.
Note that driver is probably broken already, because it parsed GPIO in
standard way respecting the flags and on top of that applied the
"reset-gpio-active-high" flag, thus "reset-gpio ACTIVE_LOW" with the
"reset-gpio-active-high" property would be double inverted.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
|
|
Get and enable a optional power gpio. This feature is ported
from the jh7110 pcie driver in Linux. VisionFive 2 Lite needs
this gpio to enable the PCI bus device (M.2 M-Key) power.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
|
|
Prepare v2026.04-rc4
|
|
The PCIe Controllers on the J784S4 SoC support Root-Complex mode of
operation. Hence, enable it.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Fixes: 79f3e77133bd ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
|
|
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.
Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
struct fdt_resource, u32 and bool types are used in this header, add
missing header files following "include what you use".
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
George McCollister <george.mccollister@konsulko.com> says:
This patch series brings over several changes from Linux that are required
to get PCIe working on the j722s and also enables PCIe in
j722s_evm_a53_defconfig. This allows Linux to be booted from an NVMe drive.
The J722S SoC provides pcie0 (using pcie_cdns_ti) thru serdes1
(using phy-cadence-torrent) thru serdes_wiz1 (using phy-j721e-wiz). Changes
to the three drivers needed to be ported from Linux to enable the REFCLK
output which is used with this SoC. These changes should be tested on other
platforms using these drivers by those with the hardware available to make
sure no problems were introduced.
The PCIe controller in this SoC relies on the code performing the PCI scan
not scanning devices which cannot exist. In Linux this is implemented as
only_one_child() in probe.c. If this mechanism is not used, PCI config reads
for subsequent functions will return information for device 0 resulting in
U-Boot detecting 32 devices when only 1 is present. This change should be
tested on other platforms with PCI to ensure the same PCI devices are
enumerated before and after the patch is applied.
I would like to thank Opto 22 for sponsoring the initial development and
anyone that is able to contribute to testing of patches.
Link: https://lore.kernel.org/r/20260130153856.2049575-1-george.mccollister@konsulko.com
|
|
TI's J722S SoC has one instance of PCIe namely PCIe0 which is a Gen3
single lane PCIe controller. Add support for the "ti,j722s-pcie-host"
compatible specific to J722S SoC.
Based on:
https://lore.kernel.org/all/20240524092349.158443-1-s-vadapalli@ti.com/
Signed-off-by: George McCollister <george.mccollister@konsulko.com>
Tested-by: Bryan Brattlof <bb@ti.com>
|
|
Add support to provide refclk to PCIe connector.
Based on: https://lore.kernel.org/r/20210308063550.6227-5-kishon@ti.com
Signed-off-by: George McCollister <george.mccollister@konsulko.com>
Tested-by: Bryan Brattlof <bb@ti.com>
|
|
Use the same mechanism as the Linux kernel to skip unnecessary (and in
the case of the J722S, errant) scanning of direct children of root
ports, downstream ports or bridges.
Based on Linux PCI code in the following files as of b927546677c8:
drivers/pci/probe.c
drivers/pci/pci.h
include/linux/pci.h
Signed-off-by: George McCollister <george.mccollister@konsulko.com>
Tested-by: Bryan Brattlof <bb@ti.com>
|
|
The ECAM will return a slave error if we access non-root devices while
the link is down. Add a check for this like Linux does so we don't
crash.
Fixes: 2f5ad77cfea ("PCI: zynqmp: Add ZynqMP NWL PCIe root port driver")
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20260106220853.731358-1-sean.anderson@linux.dev
|
|
The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c8c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).
This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
In case the link is down, or the controller driver is removed before
booting the next stage, shut down the PCIe link, put both the remote
PCIe device and the controller into reset, and disable clock. This
way, the hardware is not left active when not in use.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Correct the memory and IO mbus windows size increments in mvebu_pcie_bind.
Currently, pcie1 controller resource_size(&mem) and resource_size(&io)
checks result in a failure. This is because mem.end and io.end must be
incremented at the end of pcie0 windows assignment.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>
|
|
This driver has never been enabled by a platform since introduction and
does not currently compile. Remove it.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
SoCFPGA updates for v2025.10:
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/27762
This pull request brings a set of updates across SoCFPGA platforms
covering Agilex5, Agilex7, N5X, and Stratix10. The changes include:
* Agilex5 enhancements:
- USB3.1 enablement and DWC3 host driver support
- System Manager register configuration for USB3
- Watchdog timeout increase and SDMMC clock API integration
- dcache handling improvements in SMC mailbox path
- Enable SPL_SYS_DCACHE_OFF in defconfig
* Clock driver improvements:
- Introduce dt-bindings header for Agilex clocks
- Add enable/disable API and EMAC clock selection fixes
- Replace manual shifts with FIELD_GET usage
* DDR updates:
- IOSSM mailbox compatibility check
- Correct DDR calibration status handling
* Device tree changes:
- Agilex5: disable cache allocation for reads
- Stratix10: add NAND IP node
- Enable driver model watchdog
- Enable USB3.1 node for Agilex5
* Config cleanups:
- Simplify Agilex7 VAB defconfig
- Remove obsolete SYS_BOOTM_LEN from N5X VAB config
- Enable CRC32 support for SoCFPGA
- Increase USB hub debounce timeout
Overall this set improves reliability of DDR and cache flows,
adds missing USB and MMC features for Agilex5, and refines clock
and configuration handling across platforms.
This patch set has been tested on Agilex 5 devkit, and Agilex devkit.
|
|
R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 585
Figure 9.3.2 Software Reset flow (B) indicates that for peripherals in HSC
domain, after reset has been asserted by writing a matching reset bit into
register SRCR, it is mandatory to wait 1ms.
Because it is the controller driver which can determine whether or not the
controller is in HSC domain based on its compatible string, add the missing
delay into the controller driver.
This 1ms delay is documented on R-Car V4H and V4M, it is currently unclear
whether S4 is affected as well. This patch does apply the extra delay on
R-Car S4 as well.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Assure the reset is latched and the core is ready for DBI access.
On R-Car V4H, the PCIe reset is asynchronized and does not take
effect immediately, but needs a short time to complete. In case
DBI access happens in that short time, that access generates an
SError. Make sure that condition can never happen, read back the
state of the reset which should turn the asynchronized reset into
synchronized one, and wait a little over 1ms to add additional
safety margin.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 4581
Figure 104.3b Initial Setting of PCIEC(example), third quarter of the figure
indicates that register 0xf8 should be polled until bit 18 becomes set to 1.
Register 0xf8 bit 18 is 0 immediately after write to PCIERSTCTRL1 and is set
to 1 in less than 1 ms afterward. The current readl_poll_timeout() break
condition is inverted and returns when register 0xf8 bit 18 is set to 0,
which in most cases means immediately. In case CONFIG_DEBUG_LOCK_ALLOC=y ,
the timing changes just enough for the first readl_poll_timeout() poll to
already read register 0xf8 bit 18 as 1 and afterward never read register
0xf8 bit 18 as 0, which leads to timeout and failure to start the PCIe
controller.
Fix this by inverting the poll condition to match the reference manual
initialization sequence.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/27684
- Add i.MX8 ahab-commit command.
- Add support for flashing board with UUU on imx93_frdm.
- Fix the acces of PFUZE100 regulator desc.
- Add more i.MX6 PWM clock definitions.
- Enable OP-TEE on phytec-imx8m and update documentation.
- Enable PCI host controller on iMX95 19x19 EVK.
[trini: Fixup spacing issues]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Adding iMX95/iMX94 support to the dw driver. Follow kernel driver
stype to use flags to distinguish the characteristic of different
platforms.
Signed-off-by: Ye Li <ye.li@nxp.com>
|
|
Wirting to command register should use PCI_COMMAND not PCI_PRIMARY_BUS
Signed-off-by: Ye Li <ye.li@nxp.com>
|
|
The dev_err() is used incorrectly and we don't need the driver
to state probe success.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
|
|
Replace use of uninitialized variable with the PCI device number
in an error message as this is what we use elsewhere to derive
the PCIe port number. Use ofnode_read_pci_addr() to read the
PCI address of the node and derive the device number from that.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reported-by: Andrew Goodbody <andrew.goodbody@linaro.org>
|
|
Prepare v2025.10-rc3
|
|
R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025
page 4581 Figure 104.3b Initial Setting of PCIEC(example) middle
of the figure indicates that fourth write into register 0x148 [2:0]
is 0x3 or GENMASK(1, 0). The current code writes GENMASK(11, 0)
which is a typo. Fix the typo.
Fixes: be3dd0dc2fd9 ("pci: pcie-rcar-gen4: Add Renesas R-Car Gen4 DW PCIe controller driver")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
A large number of PCI controllers cannot build without access to some
platform specific header files. Express those requirements in Kconfig as
well.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This driver references the SZ_ macros while relying on an indirection
inclusion of <linux/sizes.h>. Add the missing include directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Many callers of PCI read functions do not check the return value for
error before using the variable that should contain the value read were
there not to be an error. However in the error case this variable is
never assigned to and so will contain uninitialised data.
To provide some certainty as to behaviour in the error case assign a
default value of all bits set.
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
|
|
Add R-Car Gen4 PCIe controller support for host mode.
This controller is based on Synopsys DesignWare PCIe. However, this
particular controller has a number of vendor-specific registers, and as
such, requires initialization code, including PHY firmware loading.
The PHY firmware loading is implemented in an entirely generic manner,
by calling a firmware loading script, which the user can configure in
a way they require. This provides the user with flexibility of loading
the PCIe firmware from whichever storage device they need to load it
from.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Use dw_pcie_link_set_max_link_width() instead of local implementation
of the same functionality. This does change the behavior slightly, as
the dw_pcie_link_set_max_link_width() implementation also programs the
LNKCAP register MLW, this should however be correct and is now aligned
with Linux kernel behavior.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Use dw_pcie_link_set_max_link_width() instead of local implementation
of the same functionality.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Use dw_pcie_link_set_max_link_width() instead of local implementation
of the same functionality. This does change the behavior slightly, as
the dw_pcie_link_set_max_link_width() implementation also programs the
LNKCAP register MLW, this should however be correct and is now aligned
with Linux kernel behavior.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add dw_pcie_link_set_max_link_width() implementation ported from Linux kernel
as of commit 89db0793c9f2 ("PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling").
This is common code which is already duplicated in multiple drivers.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
The pcireg base is not assigned to any address, reading the
pcireg base with PS_LINKUP_OFFSET which is incorrect and
giving random values. So update the pcireg base from
devicetree so that we can read the valid PCIE link status
and PHY ready status.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Link: https://lore.kernel.org/r/20250516092314.939424-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Hrushikesh Salunke <h-salunke@ti.com> says:
TI's AM64 SoC has a single instance of Cadence PCIe Controller. This
series enables support for PCIe in AM64 SoC and to configure it in
Root-Complex mode of operation.
Link: https://lore.kernel.org/r/20250416120830.138965-1-h-salunke@ti.com
|
|
TI's AM64 SoC has single instance of PCIe Controller namely PCIe0 which
is Cadence PCIe Controller. Add support to configure PCIe0 in Root-
Complex mode of operation.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
Driver uses macro SZ_4G to configure inbound base address register.
The macro is used without including the header file in which it is
defined. Fix this.
Fixes: 59ad5480098 ("pci: Add TI K3 Cadence PCIe Controller")
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
Jiaxun Yang <jiaxun.yang@flygoat.com> says:
This is a huge series which promoted MIPS/Boston target into a
usable state, with fixes to drivers and general framework issues
I found in this process.
I also converted the target to OF_UPSTREAM.
This target is covered by QEMU, to test on QEMU:
```
make boston64r6el_defconfig
make
qemu-system-mips64el -M boston -cpu I6500 -bios ./u-boot.bin -nographic
```
Link: https://lore.kernel.org/r/20240517-boston-v3-0-1ea7d23f4a1d@flygoat.com
|
|
For MIPS we are always looking gd->dram in virtual address so
PCI_MAP_SYSTEM_MEMORY should always be enabled.
If in future we ever want to make it physical we have to set
ARCH_MAP_SYSMEM.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
Boston has a very limited memory range for PCI controllers, where
1MB can't easily fit into it.
Make alignment boundary of PCI memory resource allocation a Kconfig
option and default to 0x10000 for boston.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
Probe size of ecam from devicetree properly and cap accessible
bus number accorading to ecam region size to ensure we don't go
beyond hardware address space.
Also disable all interrupts to ensure errors are handled silently.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
Legacy PCI devices, like qemu's Bochs VGA device, are allowed to have
prefetchable 32-bit BARs, while PCIe devices are not allowed to have
32-bit prefetchable BARs. Typically prefetchable BARs are 64-bit and
typically the prefetch MMIO window is also 64-bit and placed above
4GiB, as it's the case on qemu sbsa-ref.
Currently the U-Boot code assumes that prefetchable BARs are
64-bit BARs and always tries to assign them into the prefetch
MMIO window.
When a 32-bit BAR is marked as prefetch, but the prefetch area is
not within the first 4GiB of the address space, then downgrade the
BAR and place it in the non-prefetch MMIO window.
For prefetch BARs there's no downside on being placed in non prefetch
MMIO areas, besides the possible slower performance when a driver tries
to map it Write-Combine.
TEST: Fixes pci_auto on QEMU sbsa-ref fails to autoconfigure BAR0.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
|
|
One MediaTek PCIe Gen3 controller has only one port, where PCI bus 0
on this port represents the controller itself and bus 1 represents
the external PCIe device.
If multiple PCIe controllers are probed in U-Boot, U-Boot will use
bus numbers greater than 2 as input parameters. Therefore, we should
convert the BDF bus number to either 0 or 1 by subtracting the
offset by controller->seq_.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
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
|
|
Add this information to the handoff structure so that it is available to
U-Boot proper. Update bochs and the video handoff.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add support for the PCIe busses on Qualcomm platforms,
by using the pcie_dw_common infrastructure.
The driver is based on the Linux driver but only supporting
the "1_9_0" and compatible platforms like:
- sa8540p
- sc7280
- sc8180x
- sc8280xp
- sdm845
- sdx55
- sm8150
- sm8250
- sm8350
- sm8450
- sm8550
- sm8650
- x1e80100
But it has only been tested on:
- sc7280
- sm8550
- sm8650
- x1e80100
It supports setting the IOMMU SID table for supported platforms.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241125-topic-pcie-controller-v1-2-45c20070dd53@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Add PCIe config space capability search function specific for
the host controller, which are bridges *to* PCI devices but
are not PCI devices themselves.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241125-topic-pcie-controller-v1-1-45c20070dd53@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|