When there is no PCI bus uclass_first_device will return no bus and no
error which will result in pci_find_first_device calling
skip_to_next_device with no bus, and the bus is only checked at the end
of the while cycle, not the beginning.
Fixes: 76c3fbcd3d ("dm: pci: Add a way to iterate through all PCI devices")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCIe config space has address range 0-4095. So do not allow reading from
addresses outside of this range. Lot of U-Boot drivers do not expect that
passed value is not in this range. PCI DM read function is extended to
fill read value to all ones or zeros when it fails as U-Boot callers
ignores return value.
Calling U-Boot command 'pci display.b 0.0.0 0 0x2000' now stops printing
config space at the end (before 0x1000 address).
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Rename these to VESA, itself an abbreviation, to avoid a conflict with
Verified Boot for Embedded.
Rename this to avoid referencing VBE.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to use VBE to mean Verfiied Boot for Embedded in U-Boot. Rename
the existing VBE (Vesa BIOS extensions) to allow this.
Verified Boot for Embedded is documented doc/develop/vbe.rst
Signed-off-by: Simon Glass <sjg@chromium.org>
Release PERST# signal via GPIO when "reset-gpios" is defined in device tree.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
This driver is not enabled anywhere, remove it. Also remove definitions
of symbols only used in this driver, on platforms that did not enable
it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add new lines to make errorr messages easier to read.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add a check for calloc() failing to allocate the requested memory.
Make decode_regions() return an error code.
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Add a mask parameter to control the lookup of the PCI region from which
the mapping can be made.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add mask parameter and reorder length parameter to match the other PCI
address conversion functions. Using PCI_REGION_TYPE as the mask gives
the old behaviour.
It's converted from a macro to an inline function as the length
parameter is now used twice, but should only be calculated once.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When converting addresses, apply a mask to the region flags during
lookup. This allows the caller to specify which flags are important and
which are not, for example to exclude system memory regions.
The behaviour of the function is changed such that they don't
preferentially search for a non-system memory region. However, system
memory regions are added after other regions in decode_regions() leading
to a similar outcome.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Evolve dm_pci_map_bar() to include an offset and length parameter. These
allow a portion of the memory to be mapped and range checks to be
applied.
Passing both the offset and length as zero results in the previous
behaviour and this is used to migrate the previous callers.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When converting between PCI bus and physical addresses, include a length
parameter that can be used to check that the entire range fits within
one of the PCI regions. This prevents an address being returned that
might be only partially valid for the range it is going to be used for.
Where the range check is not wanted, passing a length of 0 will have the
same behaviour as before this change.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When parsing the `ranges` DT node, check that both extremes of the
regions are addressable without overflow. This assumption can then be
safely made when processing the regions.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The flags parameter of dm_pci_map_bar() is used for PCI region flags
rather than memory mapping flags. Fix the type to match that of the
region flags and stop using the regions flags as memory mapping flags.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Upstream Linux kernel uses for mpc8548-based PCIe controllers compatible
string "fsl,mpc8548-pcie". So change U-Boot fsl PCIe driver and all DTS
files to use "fsl,mpc8548-pcie" instead of "fsl,pcie-mpc8548" to be
compatible with Linux kernel.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
There are no users of the imx6_pcie_toggle_power and imx6_pcie_toggle_reset
weak overrides and as these functions are able to be handled now via dt
properties lets remove these.
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
If vpcie-supply is defined by device-tree use that if
CONFIG_PCIE_IMX_POWER_GPIO is not defined.
Note that after this the following boards which define
CONFIG_PCIE_IMX_POWER_GPIO in their board header file as well as their
device-tree should be able to remove CONFIG_PCIE_IMX_PERST_GPIO without
consequence:
- mx6sabresd
- mx6sxsabresd
- novena
Note that the ge_bx50v3 board uses CONFIG_PCIE_IMX_POWER_GPIO and does
not have vpcie-supply defined in it's pcie node in the dt thus removing
CONFIG_PCIE_IMX_POWER_GPIO globally can't be done until that board adds
vpcie-supply.
Cc: Ian Ray <ian.ray@ge.com> (maintainer:GE BX50V3 BOARD)
Cc: Sebastian Reichel <sebastian.reichel@collabora.com> (maintainer:GE BX50V3 BOARD)
Cc: Fabio Estevam <festevam@gmail.com> (maintainer:MX6SABRESD BOARD)
Cc: Marek Vasut <marex@denx.de> (maintainer:NOVENA BOARD)
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Add following two new PCI class codes defines into pci_ids.h include file:
PCI_CLASS_BRIDGE_PCI_NORMAL
PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE
And use these defines in all U-Boot code for describing PCI class codes for
normal and subtractive PCI bridges.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Use "MVPCIE_" prefix instead of generic "PCIE_" prefix for pci_mvebu.c
specific macros. Define offset macros for Root Port registers and use
standard register macros from pci.h when accessing Root Port registers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Macro SELECT() is unused and struct mvebu_pcie field lane_mask is unused
too. Remove them.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Remove some code, primarily CPM2 related, that is now unused since the
removal of MPC8540/60ADS.
Fixes 3913191c8a ("powerpc: mpc8540ads: mpc8560ads: Drop support for MPC8540/60ADS")
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.
Same change and exactly same fix as was done in commit for pci-aardvark.c.
Fixes: a7b61ab58d ("pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port)")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Allow access to config space of PCIe Root Port (which is always present on
the root bus) even when PCIe link is down or no card is connected.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
If a PIO request is executed while link-down, the whole controller gets
stuck in a non-functional state, and even after link comes up again, PIO
requests won't work anymore, and a reset of the whole PCIe controller is
needed. Therefore we need to prevent sending PIO requests while the link
is down.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.
This PCI_PRIMARY_BUS register is used only for correct configuration of
legacy PCI stuff, like forwarding of PCI special cycles between buses.
Aardvark HW does not support PCI special cycles, so it does not have HW
register for PCI_PRIMARY_BUS and therefore it does not matter what is
stored in this register.
So fix this issue and do not use PCI_PRIMARY_BUS register in pci-aardvark.c
driver for moving root bus of the root port.
After this change there is no reason for storing bus number (zero) into
first_busno variable, so remove this variable.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>
There is only one base address, so use dev_read_addr() instead of dev_read_addr_index().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Remove "PCI_" prefix from all macros which are aardvark specific to not
conflict with macros defined in global include file pci.h. Instead add
"ADVK_" prefix for them so it is visible that they are aardvark specific.
After "ADVK_" prefix append keyword which describes register group, so it
would be clear to which register each macro value belongs.
Rename some macros for consistency with other macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
PCI config space of the aardvark PCIe Root Port is available only in
internal aardvark memory space starting at offset 0x0. PCI Express
registers (PCI_EXP_*) start at offset 0xc0. And Advanced Error Reporting
registers (PCI_ERR_*) start at offset 0x100.
Replace custom aardvark register macros by standard PCI macros from
include/pci.h file with fixed offset.
Some DEVCTL and AER macros are not defined in include/pci.h file, so define
them in the same way as in linux uapi header file pci_regs.h.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
The current fixup of LX2160A PCIe nodes is based on non-production
rev1 silicon, and in Linux the nodes have been updated for rev2
silicon, so update the searching compatible string to match the
kernel changes. And for compatibility with the rev1 nodes, move
forward the board specific fixup.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Initially it is set to dev_seq but update to the last bus number is
missing. Fix it.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Register 0x43c in its low 24 bits contains PCI class code.
Update code to set all 24 bits of PCI class code and not only upper 16 bits
of PCI class code.
Use standard U-Boot macro (PCI_CLASS_BRIDGE_PCI << 8) for constructing all
24-bits of PCI class for PCI bridge Normal decode.
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Roman Bacik <roman.bacik@broadcom.com>
- fdt_support: Add fdt_for_each_node_by_compatible() helper macro
(Marek)
- turris_omnia: Fixup SATA or PCIe nodes at runtime in DT blob (Pali)
- pci_mvebu: Add support for Kirkwood PCIe controllers (Pali)
- SPL: More verifications for kwbimage in SPL (Pali)
- mvebu: Remove comphy_update_map() (Pali)
- Minor misc stuff
Kirkwood uses macros KW_DEFADR_PCI_MEM and KW_DEFADR_PCI_IO for base
address of PCIe mappings. Size of PCIe windows is not defined in any macro
yet, so export them in new KW_DEFADR_PCI_MEM_SIZE and KW_DEFADR_PCI_IO_SIZE
macros.
Kirkwood arch code already maps mbus windows for io and mem, so avoid
calling mvebu_mbus_add_window_by_id() function which would try to do
duplicate window mapping.
Kirkwood PCIe controllers already use "marvell,kirkwood-pcie" DT compatible
string, so mark pci_mvebu.c driver as compatible for it.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Add macro fdt_for_each_node_by_compatible() to allow iterating over
fdt nodes by compatible string.
Convert various usages of
off = fdt_node_offset_by_compatible(fdt, start, compat);
while (off > 0) {
code();
off = fdt_node_offset_by_compatible(fdt, off, compat);
}
and similar, to
fdt_for_each_node_by_compatible(off, fdt, start, compat)
code();
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Attempt to handle cases with a downstream port of a PCIe switch where
link training never completes and the link continues switching between
speeds indefinitely with the data link layer never reaching the active
state.
It has been observed with a downstream port of the ASMedia ASM2824 Gen 3
switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2
switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device,
P/N 41433, wired to a SiFive HiFive Unmatched board. In this setup the
switches are supposed to negotiate the link speed of preferably 5.0GT/s,
falling back to 2.5GT/s.
However the link continues oscillating between the two speeds, at the
rate of 34-35 times per second, with link training reported repeatedly
active ~84% of the time, e.g.:
02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 5GT/s (downgraded), Width x1 (ok)
TrErr- Train+ SlotClk+ DLActive- BWMgmt+ ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis+, Selectable De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
[...]
Forcibly limiting the target link speed to 2.5GT/s with the upstream
ASM2824 device makes the two switches communicate correctly however:
02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=09, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis+, Selectable De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
[...]
and then:
05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane Packet Switch [12d8:2304] (rev 05) (prog-if 00 [Normal decode])
[...]
Bus: primary=05, secondary=06, subordinate=09, sec-latency=0
[...]
Capabilities: [c0] Express (v2) Upstream Port, MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
[...]
Make use of this observation then and attempt to detect the inability to
negotiate the link speed automatically, and then handle it by hand. Use
the Data Link Layer Link Active status flag as the primary indicator of
successful link speed negotiation, but given that the flag is optional
by hardware to implement (the ASM2824 does have it though), resort to
checking for the mandatory Link Bandwidth Management Status flag showing
that the link speed or width has been changed in an attempt to correct
unreliable link operation (the ASM2824 does set it too).
If these checks indicate that link may not operate correctly, then poll
the Data Link Layer Link Active status flag along with the Link Training
flag for the duration of 200ms to see if the link has stabilised, that
is either that the Data Link Layer Link Active status flag has been set
or that Link Training has been inactive during at least the second half
of the interval.
If that has indicated failure, restrict the target speed to 2.5GT/s,
request a link retrain and check again if the link has stabilised. If
that does not work either, then restore the original speed setting and
claim defeat, otherwise we are done.
NB interestingly enough with the ASM2824 vs PI7C9X2G304 configuration
referred above asking the ASM2824 to retrain with a higher target link
speed once the 2.5GT/s speed has been negotiated makes the two devices
successfully negotiate 5.0GT/s. Lifting the 2.5GT/s speed restriction
would however prevent our workaround from working with an OS that issues
a reset and that is unaware of the problem. This is because the devices
would then try to negotiate a higher link speed from scratch and fail,
while the sticky property of the Target Link Speed setting will keep the
2.5GT/s speed restriction across a reset.
Keep the 2.5GT/s speed restriction then, conservatively, if functional
once applied.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Reviewed-by: Stefan Roese <sr@denx.de>
