Function dm_pci_hose_probe_bus() expects that bus is valid PCI device with
Bridge header type (0x01). So add check before touching PCI config space to
prevent misconfiguring some non-standard device.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
PCI Rom Address is currently supported only for Normal (0x00) and
Bridge (0x01) header types. Fix code accordingly.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
There were several changes for this structure but the documentation was
not changed at the time. Fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Now that PCI Bridge (PCIe Root Port) for Aardvark is emulated in U-Boot,
add support for handling and propagation of CRSSVE bit.
When CRSSVE bit is unset (default), driver has to reissue config
read/write request on CRS response.
CRSSVE bit is supported only when CRSVIS bit is provided in read-only
Root Capabilities register. So manually inject this CRSVIS bit into read
response for that register.
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>
Now that PCI Bridge is working for the PCIe Root Port, U-Boot's PCI_PNP
code automatically enables memory access and bus mastering when needed.
We do not need to enable it when setting the HW up.
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>
Aardvark does not have a real PCIe Root Port device on the root bus.
Instead it has PCIe registers of PCIe Root Port device mapped in
internal Aardvark memory space starting at offset 0xc0.
The PCIe Root Port itself is normally available as a PCI Bridge device
on the root bus with bus number zero. Aardvark instead has the
configuration registers of this PCI Bridge at offset 0x00 of Aardvark's
memory space, but the class code of this device is Mass Storage
Controller (0x010400), instead of PCI Bridge (0x600400), which causes
U-Boot to fail to recognize it as a P2P Bridge
Add a hook into the pcie_advk_read_config() / pcie_advk_write_config()
functions to redirect access for root bus from PIO transfer to this
internal Aardvark memory space. This will allow U-Boot to access
configuration space of this PCI Bridge which represents PCIe Root Port.
Redirect access to PCI Bridge registers in range 0x10 - 0x34 to driver's
internal buffer (cfgcache[]). This is because at those addresses
Aardvark has different registers, incompatible with config space of a
PCI Bridge.
Redirect access to PCI Bridge register PCI_ROM_ADDRESS1 (0x38) to
Aardvark internal address for that register (0x30).
When reading PCI Bridge register PCI_HEADER_TYPE, set it explicitly to
value Type 1 (PCI_HEADER_TYPE_BRIDGE) as PCI Bridge must be of Type 1.
When writing to PCI_PRIMARY_BUS or PCI_SECONDARY_BUS registers on this
PCI Bridge, correctly update driver's first_busno and sec_busno
variables, so that pcie_advk_addr_valid() function can check if address
of any device behind the root bus is valid and that PIO transfers are
started with correct config type (1 vs 0), which is required for
accessing devices behind some PCI bridge after the root bus.
U-Boot's PCI_PNP code sets primary and secondary bus numbers as relative
to the configured bus number of the root bus. This is done so that
U-Boot can support multiple PCIe host bridges or multiple root port
buses, when internal bus numbers are different.
Now that root bus is available, update code in pcie_advk_read_config()
and pcie_advk_write_config() functions to correctly calculate real
Aardvark bus number of the target device from U-Boot's bus number as:
busno = PCI_BUS(bdf) - dev_seq(bus)
Stefan: Small fix of header masking as suggested by Pali.
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>
Aardvark reports Disabled and Hot Reset LTSSM states as values >= 0x20.
Link is not up in these states, so fix pcie_advk_link_up() function.
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>
On Amlogic A311D, when the PCIe link fails disabling the related clocks
makes USB fail. For an unknown reason, this doesn happen on the S905D3 SoC.
Mimic the Linux behavior by not considering a link failure a probe failure,
and continue even if the PCIe link is down.
Reported-by: Art Nikpal <email2tema@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The function prototype for ft_pci_setup is inside fdt_support.h, we need
to include that header.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid W=1 build warnings, declare this function as static, since it
is not used outside of this translation module.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To avoid a build warning with W=1, provide a function prototype for
dm_pciauto_prescan_setup_bridge, which is a non-static function whose
definition is inside pci_auto.c.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some PCIe controller's read_config() method support indicating error
directly via return value, but some cannot distinguish all-ones (or
all-zeros) read response from an error.
The current code in pci_bind_bus_devices() interprets all-ones /
all-zeros in PCI_VENDOR_ID register as "nothing connected", and
continues the cycle, but an error returned via return value breaks the
cycle.
This is wrong for the PCIe controllers which return this error via
return value.
Handle all errors when reading PCI_VENDOR_ID the same way.
This fixes enumeration of PCI devices for example when there is a PCI
bridge connected behind another PCI bridge and not all ports are
connected to a device, and the controller (for example Aardvark)
translates the UR error (Unsupported Request) as -EOPNOTSUPP.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Lower 4 bits of PCI_MEMORY_BASE and PCI_MEMORY_LIMIT registers are reserved
and should be zero. So do not set them to non-zero value.
Lower 4 bits of PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT registers
contain information if 64-bit memory addressing is supported. So preserve
this information when overwriting these registers.
Lower 4 bits of PCI_IO_BASE and PCI_IO_LIMIT register contain information
if 32-bit io addressing is supported. So preserve this information and do
not try to configure 32-bit io addressing (via PCI_IO_BASE_UPPER16 and
PCI_IO_LIMIT_UPPER16 registers) when it is unsupported.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
With legacy PCI code removed and thus DM_PCI also removed, a few places
did not get correctly updated with the merge to next and thus broke.
Remove now extraneous dependencies on DM_PCI.
Signed-off-by: Tom Rini <trini@konsulko.com>
Use dev_dbg() instead of dev_err() in pcie_advk_check_pio_status().
For example CRS is not an error status, it just says that the request
should be retried.
Without this, U-Boot spams the terminal with
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x100000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x108000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x110000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x120000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x128000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x130000
...
when a device is not connected to a PCIe switch (Unsupported Request
from the switch).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
According to PCIe base specification, if CRS Software Visibility is not
enabled, the Root Complex must re-issue the Configuration Request as a new
Request.
Normally this part of Root Complex is implemented in hardware but aardvark
is somehow special and does not implement it in hardware and expect that
handling of config requests are fully implemented in software.
This re-issuing functionality is required also because U-Boot does not
support CRS Software Visibility feature and therefore expects that Root
Complex re-issues requests as is specified in PCIe base specification.
Retry / re-issue config request up to the PIO_MAX_RETRIES, to prevent
infinite loop. After retry count exceed PIO_MAX_RETRIES, returns failure.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
There was mistake in commit 4cd61c43fd ("arm: a37xx: pci: Fix handling
PIO config error responses"). U-Boot does not support handling of CRS
return value for PCI_VENDOR_ID config read request and also does not set
CRSSVE bit.
Therefore disable returning CRS response for now.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 4cd61c43fd ("arm: a37xx: pci: Fix handling PIO config error responses")
Reviewed-by: Stefan Roese <sr@denx.de>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
Returning fabricated CRS value (0xFFFF0001) by PCIe Root Complex to OS is
allowed only for 4-byte PCI_VENDOR_ID config read request and only when
CRSSVE bit in Root Port PCIe device is enabled. In all other error PCIe
Root Complex must return all-ones.
So implement this logic in pci-aardvark.c driver properly.
aardvark HW does not have Root Port PCIe device and U-Boot does not
implement emulation of this device. So expect that CRSSVE bit is set as
U-Boot can already handle CRS value for PCI_VENDOR_ID config read request.
More callers of pci_bus_read_config() function in U-Boot do not check for
return value, but check readback value. Therefore always fill readback
value in pcie_advk_read_config() function. On error fill all-ones of
correct size as it is required for PCIe Root Complex.
And also correctly propagates error from failed config write request to
return value of pcie_advk_write_config() function. Most U-Boot callers
ignores this return value, but it is a good idea to return correct value
from function.
These issues about return value of failed config read requests, including
special handling of CRS were reported by Lorenzo and Bjorn for Linux kernel
driver pci-aardvark together with quotes from PCIe r4.0 spec, see details:
https://lore.kernel.org/linux-pci/20210624213345.3617-1-pali@kernel.org/t/#u
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This driver is currently only used on MIPS Malta boards.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This driver is currently only used on MIPS Malta boards.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On MIPS the DRAM start address respectively CONFIG_SYS_SDRAM_BASE
is still used as a virtual, CPU-mapped address instead of being used
as physical address. Converting all MIPS boards and generic MIPS code
to fix that is not trivial. Due to the approaching deadline for
PCI DM conversion, this workaround is required for MIPS boards with
PCI support until the CONFIG_SYS_SDRAM_BASE issue could be solved.
Add a compile-time option to let the PCI uclass core optionally map
the DRAM address to a physical address when adding the PCI region
of type PCI_REGION_SYS_MEMORY.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
At present only bridge devices are bound before relocation, to save space
in pre-relocation memory. In some cases we do actually want to bind a
device, e.g. because it provides the console UART. Add a devicetree
binding to support this.
Use the PCI_VENDEV() macro to encode the cell value. This is present in
U-Boot but not used, so move it to the binding header-file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These functions don't modify the device-ID struct that is passed in, so
mark the argument as const, so the data structure can be declared that
way. This allows it to be placed in the rodata section.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Remapped address of PCIe outbound window may have set only bits from the
mask. Add additional check that remapped address which is calculated from
PCIe bus address specified in DTS file is valid.
Remove also useless clearing of low 16 bits in win_mask. As win_size is
power of two and is at least 0x10000 it means that it always has zero low
16 bits.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Add PCIe driver for UniPhier SoCs. This PCIe controller is based on
Synopsys DesignWare Core IP.
This version doesn't apply common DW functions because supported
controller doesn't have unroll version of iATU.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
If reset-gpio is defined by device-tree use that if
CONFIG_PCIE_IMX_PERST_GPIO is not defined.
Note that after this the following boards which define
CONFIG_PCIE_IMX_PERST_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
- tbs2910
- vining_2000
Note that the ge_bx50v3 board uses CONFIG_PCIE_IMX_PERST_GPIO and does
not have reset-gpios defined it it's pcie node in the dt thus removing
CONFIG_PCIE_IMX_PERST_GPIO globally can't be done until that board adds
reset-gpios.
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)
Cc: Soeren Moch <smoch@web.de> (maintainer:TBS2910 BOARD)
Cc: Silvio Fricke <open-source@softing.de> (maintainer:VINING_2000 BOARD)
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
These boards have not been converted to CONFIG_DM_PCI by the deadline
and is also missing conversion to CONFIG_DM. Remove them.
Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
