PCI sh7780 driver uses standard format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_ADDRESS().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI mediatek driver uses extended format of Config Address for PCI
Configuration Mechanism #1 but with cleared Enable bit.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() with clearing
PCI_CONF1_ENABLE bit and remove old custom driver address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI fsl driver uses extended format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI tegra driver uses extended format of Config Address for PCI
Configuration Mechanism #1 but with cleared Enable bit.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() with clearing
PCI_CONF1_ENABLE bit and remove old custom driver address function.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI mvebu driver uses extended format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() and remove old custom
driver address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI msc01 driver uses standard format of Config Address for PCI
Configuration Mechanism #1 but with cleared Enable bit.
So use new U-Boot macro PCI_CONF1_ADDRESS() with clearing PCI_CONF1_ENABLE
bit and remove old custom driver address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI mpc85xx driver uses extended format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI gt64120 driver uses standard format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_ADDRESS() and remove old custom driver
address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
It is common to set all base address bits to one and all limit address bits
to zero for disabling address forwarding. Forwarding is disabled when base
address is higher than limit address, so this change should not have any
effect.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
If U-Boot does not have any I/O resource for assignment then disable I/O
forwarding in PCI bridge autoconfiguration code. Default initial state of
PCI bridge IO registers is unspecified, therefore they can be in enabled if
U-Boot does not touch them.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Function dm_pciauto_prescan_setup_bridge() configures base address
registers, therefore it should read type of IO from base address registers
(and not from limit address registers).
Note that base and limit address registers should have same type, so this
change is just usage correction and has no functional change on correctly
working hardware.
Fixes: 8e85f36a8f ("pci: Fix configuring io/memory base and limit registers of PCI bridges")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
The global data pointer is not used in this driver, remove it's
declaration.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Use more appropriate resource_size() function when working with data in
struct resource.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Function mvebu_pcie_setup_wins() sets up all other BARs, so move setup of
BAR[0] to this function to have common code at one place.
In the past, commit 193a1e9f19 ("pci: pci_mvebu: set BAR0 after memory
space is set") moved setup of BAR[0] to another location, due to ath10k
not working in kernel, but the reason why was unknown, but it seems to
work now, and we think the issue then was cause by the PCIe Root Port
presenting itself as a Memory Controller and therefore U-Boot's code
have overwritten the BAR. Since the driver now ignores any write
operations to PCIe Root Port BARs, this should not be an issue anymore.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Since no one uses this feature and I am not aware of any parsers of this
in Linux, remove it.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Pratyush Yadav <p.yadav@ti.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.
In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.
Fixes: cb056005dc ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
The PCI Bridge which represents mvebu PCIe Root Port has Expansion ROM
Base Address register at offset 0x30 but its meaning is different that
of PCI's Expansion ROM BAR register, although the address format of
the register is the same.
In reality, this device does not have any configurable PCI BARs. So
ensure that write operation into BARs (including Expansion ROM BAR) is a
noop and registers always contain zero address which indicates that BARs
are unsupported.
Fixes: a7b61ab58d ("pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port)")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Since u32 takes up 4 bytes, we need to divide the number of u32s by 4
for cfgcache.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
When booting U-Boot in crosvm, the virtual machine emulates a PCI cam
device, not the PCI-E 'ecam' device normally seen on e.g. QEMU. This
PCI device can be supported with only trivial changes to the ecam
driver.
Instead of adding a completely new driver which is identical besides the
initialization step, add support for the PCI version to the existing
driver.
Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: Ram Muthiah <rammuthiah@google.com>
Lot of PCIe controllers are using ECAM addressing. So add common ECAM
macros into U-Boot's pci.h header file which can be suitable for most
PCI controller drivers.
Replace custom ECAM address macros in every PCI controller driver by new
ECAM macros from U-Boot's pci.h header file.
Similar macros are defined also in Linux kernel. There is a small
difference between Linux and these new U-Boot macros.
U-Boot's PCIE_ECAM_OFFSET() takes device and function numbers in separate
arguments. Linux's PCIE_ECAM_OFFSET() takes device and function numbers
encoded in one argument. The reason is that U-Boot's PCI_DEVFN() macro is
different than Linux's PCI_SLOT() macro. So having device and function
numbers in separate arguments makes code more straightforward.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
- device-tree sync-up with Linux for ls1028a
- fixes/update in fsl-ddr driver, fsl-validate, lx2162a, fsl-mc,
spintable code, configs, qspi node, pci
- enable EFI_SET_TIME support in sl28
- powerpc: Drop -mstring
Header file mach/cpu.h already defines MBUS_PCI_MEM_SIZE macro which
defines size of MBUS_PCI_MEM_BASE window. So use global MBUS_PCI_MEM_SIZE
macro instead of locally defined PCIE_MEM_SIZE macro. Both macros have same
definition.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
In the current code, it doesn't reset the cursors of LUT entry and
StreamID at the beginning of the fixup, so it can result in LUT entry
setup and msi-map mismatch and LUT entries and StreamID leaking
when reload and fixup the DTB.
This patch move the initialization of LUT entry and StreamID cursors
to the beginning of the fixup to resolve the issues.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
[Rebased]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
The official bindind of the PCIe controller of the ls1028a has the
following compatible string:
compatible = "fsl,ls1028a-pcie";
Additionally, the resource names and count are different. Update the
driver to support this binding and change the entry in the ls1028a
device tree.
Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
According to the Armada 3720 Functional Specification Data Strobe applies
for both read and write config requests.
Data strobe bits configure which bytes from the start address should be
returned for read request. Set value 0xf (all 4 bits) into Data Strobe
register to read all four bytes from specified 32-bit config space
register. Same value for Data Strobe register is programmed by Linux
pci-aardvark.c driver for config read requests.
Without this patch pci-aardvark driver sets data strobe register only
during config write operations. So any followup config read operations
could result with just partial datai returned (if previous write operation
was not 32-bit wide). This patch fixes it and ensures that config read
operations always read all bytes from requested register.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This is a pci driver, not an eth driver.
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>
Root Complex should be the default mode, let's set it explicitly.
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, U-Boot's CONFIG_PCI_PNP code automatically
enables memory access and bus mastering when it is needed. So do not
prematurely enable memory access and bus mastering.
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>
PCI Bridge is always accessible also when link is down. So move detection
of link up from mvebu_pcie_of_to_plat() function to mvebu_pcie_valid_addr()
function which is used when accessing PCI config space.
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>
Functions mvebu_pcie_get_local_bus_nr() and mvebu_pcie_get_local_dev_nr()
are not used, so 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>
The mysterious "Memory controller" PCI device which is present in PCI
config space is improperly configured and crippled PCI Bridge which acts
as PCIe Root Port for endpoint PCIe card.
This PCI Bridge reports in PCI config space incorrect Class Code (Memory
Controller) and incorrect Header Type (Type 0). It looks like HW bug in
mvebu PCIe controller but apparently it can be changed via mvebu registers
to correct values.
The worst thing is that this PCI Bridge is crippled and its PCI config
registers in range 0x10-0x34 alias access to internal mvebu registers which
have different functionality as PCI Bridge registers. Moreover,
configuration of PCI primary and secondary bus numbers (registers 0x18
and 0x19) is done via totally different mvebu registers via totally strange
method and cannot be done via PCI Bridge config space.
Due to above fact about PCI config range 0x10-0x34, allocate a private
cfgcache[] buffer in the driver, to which PCI config access requests to
the 0x10-0x34 space will be redirected in mvebu_pcie_read_config() and
mvebu_pcie_write_config() functions. Function mvebu_pcie_write_config()
will also catch writes to PCI_PRIMARY_BUS (0x18) and PCI_SECONDARY_BUS
(0x19) registers and set PCI Bridge primary and secondary bus numbers via
mvebu's own method.
Also, Expansion ROM Base Address register (0x38) is available, but at
different offset 0x30. So recalculate register offset before accessing PCI
config space.
After these steps U-Boot sees working PCI Bridge and CONFIG_PCI_PNP code
can finally start enumerating all PCIe devices correctly, even with more
complicated PCI topology. So update also mvebu_pcie_valid_addr() function
to reflect state of the real device topology.
Each PCIe port is de-facto isolated and every PCI Bridge which is part of
PCIe Root Complex is also isolated, so put them on separate PCI buses as
(local) device 0.
U-Boot already supports enumerating separate PCI buses, real (HW) bus
number can be retrieved by "PCI_BUS(bdf) - dev_seq(bus)" code, so update
config read/write functions to properly handle more complicated tree
topologies (e.g. when a PCIe switch with multiple PCI buses is connected
to the PCIe port).
Local bus number and local device number on mvebu are used for determining
which config request type is used (Type 0 vs Type 1). On normal non-broken
PCIe hardware it is done by primary and secondary bus numbers. So correctly
translate settings between these numbers to ensure that correct config
requests are sent over the PCIe bus.
As bus numbers are correctly re-configured, it does not make sense to print
some initial bogus configuration during probe, so remove this debug code.
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>
When reading 8 or 16 bits from config space, use appropriate readb() or
readw() calls. This ensures that PCIe controller does not read more bits
from endpoint card as asked by read_config() function.
Technically there should not be an issue with reading data from config
space which are not later used as there are no clear-by-read registers.
But it is better to use correct read operation based on requested size.
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>
Current implementation of write_config() is broken for PCI_SIZE_8 or
PCI_SIZE_16 as it always uses writel(), which means that write operation
is always 32-bit, so upper 24 bits for PCI_SIZE_8 and upper 16 bits for
PCI_SIZE_16 are cleared.
Fix this by using writeb() and writew(), respectively.
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>
As stated in comment above the code, CRS response can be returned to OS
only for 4-byte PCI_VENDOR_ID config read request. So fix the code.
Fixes: 1d7ad68559 ("arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.
So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.
After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.
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>
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>
