These take the 'struct udevice *' as an argument, not the
'struct xilinx_pcie *` which is a local variable. Fix the comments to
match the code.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.
Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.
Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
This bug is brought by the commit 3d8553f0a3 (pci: layerscape: add
LS2088A series SoC pcie support), which only updated cfg_res.start
and did not update the .end field. This causes fdt_resource_size()
getting wrong value when calculate the cfg1 space address.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
[YS: Revise subject and commit message]
Reviewed-by: York Sun <york.sun@nxp.com>
PCI is the de facto interconnect bus in an x86 system.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update the tegra pci driver to support a live device tree. Fix the check
for nvidia,num-lanes so that an error will actually be detected.
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
This function returns the pointer to the value of a node property.
The current name ofnode_read_prop() is confusing. Follow the naming
of_get_property() from Linux.
The return type (const u32 *) is wrong. DT property values can be
strings as well as integers. This is why of_get_property/fdt_getprop
returns an opaque pointer.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
The of_n_addr_cells() and of_n_size_cells() functions are useful for
getting the size of addresses in a node, but in a few places U-Boot needs
to obtain the actual property value for a node without walking up the
stack. Add functions for this and just the existing code to use it.
Add a comment to the existing ofnode functions which do not do the right
thing with a flat tree.
This fixes a problem reading PCI addresses.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
There was for long time no activity in the 4xx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 4xx,
so remove it.
Signed-off-by: Heiko Schocher <hs@denx.de>
There was for long time no activity in the 8260 area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 8260,
so remove it.
Signed-off-by: Heiko Schocher <hs@denx.de>
The declarations should not be in common.h. Move them to the arch-specific
headers.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Fixup thinko defined(FSL_LSCH3) -> defined(CONFIG_FSL_LSCH3)]
Signed-off-by: Tom Rini <trini@konsulko.com>
Update the PCI uclass to support livetree. This mostly involves fixing
the address decoding from the device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
These support the flat device tree. We want to use the dev_read_..()
prefix for functions that support both flat tree and live tree. So rename
the existing functions to avoid confusion.
In the end we will have:
1. dev_read_addr...() - works on devices, supports flat/live tree
2. devfdt_get_addr...() - current functions, flat tree only
3. of_get_address() etc. - new functions, live tree only
All drivers will be written to use 1. That function will in turn call
either 2 or 3 depending on whether the flat or live tree is in use.
Note this involves changing some dead code - the imx_lpi2c.c file.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is no dedicated reset signal wired up for the MX6QDL thus if the
bootloader enables the link we need some special handling to get the core
back into a state where it is safe to touch it for configuration.
While there has been some special handling in the Linux kernel to do this,
it was removed in 4.11 thus we need to do it properly in the bootloader
and therefore without this if you enable PCI in the bootloader you will hang
while booting the 4.11 kernel.
This puts the PCIe controller back into a safe state for the kernel driver
before launching the kernel.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Peter Senna Tschudin <peter.senna@collabora.com>
The QorIQ LS2081A SoC has eight 64-bit ARM v8 Cortex A72 cores and
is built on layerscape architecture. It is 40-pin derivative of
LS2084A (non-AIOP personality of LS2088A). So feature-wise it is
same as LS2084A. LS2041A is a 4-core personality of LS2081A.
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Signed-off-by: Santan Kumar <santan.kumar@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can
bypass executing VGA roms in S3.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>
strdup uses malloc to allocate memory for str.
If we cannot bind to the generic driver we should release
the memory.
The problem was indicated by clang scan-build.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch allows probing all PCIe nodes defined in DTS
even if there no device connected to such node (no link).
Without this fix the driver returns -ENODEV when the PCIe
link is down. As result the pci_init function stops
scanning bus on first empty PCIe slot and all devices
located in higher numbered buses are not discovered.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Igal Liberman <igall@marvell.com>
Cc: Nadav Haklai <nadavh@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch fixup iommu-map property on pci node to have a valid
mapping of requester-id to stream-id. The requester-id to stream-id
mapping is based on PCI-LUT table initialization.
Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Layerscape Chasis-2 also uses same PCIe controller as Chasis-3
and have similar PCI-Lut.
Signed-off-by: Bharat Bhushan <bharat.bhushan@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
LS2088A and its variants have different PCIe node than LS2080A.
The compatible string is updated accordingly.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
The LS2088A series SoCs has different physical memory map address and
CCSR registers address against LS2080A series SoCs.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
In EP mode, to enable accesses from the Root Complex, the
CONFIG_READY bit must be set, otherwise any config attempts
from the Root Complex will be returned with config retry
status (CRS).
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
In the description of function pci_match_one_id(), there are some
problems on arguments list and return value description, so correct
them.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add support for "marvell,reset-gpio" property to mvebu DW PCIe
driver.
This option is valid when CONFIG_DM_GPIO=y
Change-Id: Ic17c500449050c2fbb700731f1a9ca8b83298986
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Nadav Haklai <nadavh@marvell.com>
Cc: Neta Zur Hershkovits <neta@marvell.com>
Cc: Igal Liberman <igall@marvell.com>
Cc: Haim Boot <hayim@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Armada 38x has four PCI ports, not three.
The optimization in pci_init_board() seems to assume that every port has
three lanes. This is obviously wrong, and breaks support for Armada 38x.
Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
The read-only-write-enable bit is set by default and must be cleared
to prevent overwriting read-only registers. This should be done
immediately after resetting the PCI Express controller.
Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Signed-off-by: Tony O'Brien <tony.obrien@alliedtelesis.co.nz>
[York S: Move SYS_FSL_ERRATUM_A007815 to Kconfig]
Reviewed-by: York Sun <york.sun@nxp.com>
All Layerscape SoCs have supported new PCIe driver based on DM.
The lagecy PCIe driver code is unused and can be removed.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
There are more than five kinds of Layerscape SoCs. unfortunately,
PCIe controller of each SoC is a little bit different. In order
to avoid too many macro definitions, the patch addes a new
implementation of PCIe driver based on DM. PCIe dts node is
used to describe the difference.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
To make the layerscape pcie driver clear, move the kernel DT fixup
code from pcie_layerscape.c to pcie_layerscape_fixup.c.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
There may be multiple PCIe controllers in a SoC.
It is not correct that always calling pci_bus_to_hose(0) to get
the first PCIe controller for the PCIe device connected other
controllers. We just remove this calling because hose always point
the correct PCIe controller.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: York Sun <york.sun@nxp.com>
for the legacy PCI driver, the function pci_bus_to_hose() returns
the real PCIe controller. To keep consistency, this function is
changed to return the PCIe controller pointer of the root bus
instead of the current PCIe bus.
Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Fix 'driver model' rather than 'driver mode' in description.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This patch adds a driver for the PCIe controller integrated in the
Marvell Armada-8K SoC. This controller is based on the DesignWare
IP core.
The original version was written by Shadi and Yehuda. I ported this
driver to the latest mainline U-Boot version with DM support.
Tested on the Marvell DB-88F8040 Armada-8K eval board.
Signed-off-by: Shadi Ammouri <shadi@marvell.com>
Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Nadav Haklai <nadavh@marvell.com>
Cc: Neta Zur Hershkovits <neta@marvell.com>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Omri Itach <omrii@marvell.com>
Cc: Igal Liberman <igall@marvell.com>
Cc: Haim Boot <hayim@marvell.com>
Cc: Hanna Hawa <hannah@marvell.com>
For ease of use and accounting a condition that on SH4
pci_phys_to_bus() and pci_bus_to_phys() are one in one mappings due to
unimplemented __iomem() conversion, this change fixes access to SDRAM
memory by PCI devices.
This change also generalizes PCI system memory configuration, which is
taken from board specific defines rather than hardcoded in the PCI
host driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
The change actually maps PCI I/O window to the same address on PCI bus
as it is stated by a comment, before the change transfers to the PCI I/O
space are failed due to misconfiguration of the most significant 14 bits
of the PCI address in PCIIOBR (note that it is set to 0x0).
Most probably the problem remained unnoticed, because communcation
to all tested PCI devices is done over PCI memory space only.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Introduce CONFIG_PCI_PNP in Kconfig and move over boards' defconfig
to use that.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Re-generate configs and include/configs/ changes]
Signed-off-by: Tom Rini <trini@konsulko.com>
The signature for this macro has changed. Bring in the upstream version and
adjust U-Boot's usages to suit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update to drivers/power/pmic/palmas.c:
Signed-off-by: Keerthy <j-keerthy@ti.com>
Change-Id: I6cc9021339bfe686f9df21d61a1095ca2b3776e8
With DM conversion, information like "Video: 1024x768x16" is not
shown anymore. Now add these verbose output back.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Provide a function to run the Vesa BIOS for a given PCI device and obtain
the resulting configuration (e.g. display size) for use by the video
uclass. This makes it easier to write a video driver that uses vesa and
supports driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Now, arch/${ARCH}/include/asm/errno.h and include/linux/errno.h have
the same content. (both just wrap <asm-generic/errno.h>)
Replace all include directives for <asm/errno.h> with <linux/errno.h>.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Fixup include/clk.]
Signed-off-by: Tom Rini <trini@konsulko.com>
In pci_uclass_pre_probe an attempt is made to detect whether the parent
of a device is a PCI device and that the device is thus a bridge. This
was being done by checking whether the parent of the device is of the
UCLASS_ROOT class. This causes problems if the PCI controller is a child
of some other non-PCI node, for example a simple-bus node.
For example, if the device tree contains something like the following
then pci_uclass_pre_probe would incorrectly believe that the PCI
controller is a bridge, with a PCI parent:
/ {
some_child {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <>;
pci_controller: pci@10000000 {
compatible = "my-pci-controller";
device_type = "pci";
reg = <0x10000000 0x2000000>;
};
};
};
Avoid this incorrect detection of bridges by instead checking whether
the parent devices class is UCLASS_PCI and treating a device as a bridge
when this is true, making use of device_is_on_pci_bus to perform this
test.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This patch adds a driver for the Xilinx AXI bridge for PCI express, an
IP block which can be used on some generations of Xilinx FPGAs. This is
mostly a case of implementing PCIe ECAM specification, but with some
quirks about what devices are valid to access.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tegra186 supports the new standard clock, reset, and power domain APIs.
Older Tegra SoCs still use custom APIs. Enhance the Tegra PCIe driver so
that it can operate with either set of APIs.
On Tegra186, the BPMP handles all aspects of PCIe PHY (UPHY) programming.
Consequently, this logic is disabled too.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Quite a few places have a bind() method which just calls dm_scan_fdt_dev().
We may as well call dm_scan_fdt_dev() directly. Update the code to do this.
Signed-off-by: Simon Glass <sjg@chromium.org>
For consistency with board_should_run_oprom(), do the same to
should_load_oprom(). Board support codes can provide this one
to override the default weak one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present should_load_oprom() calls board_should_run_oprom() to
determine whether oprom should be loaded. But sometimes we just
want to load oprom without running. Make them independent.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On recent SoCs, tegra_pcie_phy_enable() isn't called; but instead
tegra_pcie_enable_controller() calls tegra_xusb_phy_enable(). However,
part of tegra_pcie_phy_enable() needs to happen in all cases. Move that
code to tegra_pcie_port_enable() instead.
For reference, NVIDIA's downstream Linux kernel performs this operation
in tegra_pcie_enable_rp_features(), which is called immediately after
tegra_pcie_port_enable(). Since that function doesn't exist in the U-Boot
driver, we'll just add it to the tail of tegra_pcie_port_enable() instead.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The value that should be programmed into the PADS_REFCLK register varies
per SoC. Fix the Tegra PCIe driver to program the correct values. Future
SoCs will require different values in cfg0/1, so the two values are stored
separately in the per-SoC data structures.
For reference, the values are all documented in NV bug 1771116 comment 20.
The Tegra210 value doesn't match the current TRM, but I've filed a bug to
get the TRM fixed. Earlier TRMs don't document the value this register
should contain, but the ASIC team has validated all these values, except
for the Tegra20 value which is simply left unchanged in this patch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
When multiple PCI cards are present in an ls2080a board, the second
card does not get its msi-map set up properly due to a bug in
computing the bus number.
The bus number returned by PCI_BDF() is not the actual PCI bus
number, but instead represents a global u-boot PCI bus number. A
given bus number is relative to hose->first_busno, so that has to be
subtracted from the PCI device id.
Signed-off-by: Bogdan Purcareata <bogdan.purcareata@nxp.com>
Acked-by: Stuart Yoder <stuart.yoder@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Tegra20's PCIe controller has a couple of quirks. There are workarounds in
the driver for these, but they don't work after the DM conversion:
1) The PCI_CLASS value is wrong in HW.
This is worked around in pci_tegra_read_config() by patching up the value
read from that register. Pre-DM, the PCIe core always read this via a
16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses are used,
so we need to check for offset 0x8 instead. Mask the offset value back to
32-bit alignment to make this work in all cases.
2) Accessing devices other than dev 1 causes a data abort.
Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core code
called during enumeration while iterating over a bus. The DM PCIe core
doesn't use this function. Instead, enhance tegra_pcie_conf_address() to
validate the bdf being accessed, and refuse to access invalid devices.
Since pci_skip_dev() isn't used, delete it.
I've also validated that both these WARs are only needed for Tegra20, by
testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them in
conditionally.
Fixes: e81ca88451 ("dm: tegra: pci: Convert tegra boards to driver model for PCI")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The terminal condition in the area where a PCI device is scanned is wrong,
and 1f.7 isn't scanned.
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
msi-map properties are used to tell an OS how PCI requester IDs are
mapped to ARM SMMU stream IDs.
for all PCI devices discovered in a system:
-allocate a LUT (look-up-table) entry in that PCI controller
-allocate a stream ID for the device
-program and enable a LUT entry (maps PCI requester id to stream ID)
-set the msi-map property on the controller reflecting the
LUT mapping
basic bus scanning loop/logic was taken from drivers/pci/pci.c
pci_hose_scan_bus().
Signed-off-by: Stuart Yoder <stuart.yoder@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Remove stream ID partitioning support that has been made
obsolete by upstream device tree bindings that specify how
representing how PCI requester IDs are mapped to MSI specifiers
and SMMU stream IDs.
Signed-off-by: Stuart Yoder <stuart.yoder@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Two comments are missing a parameter and there is an extra blank line. Also
two of the region access macros are misnamed. Correct these problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is common to read a config register value, clear and set some bits, then
write back the updated value. Add functions to do this in one step, for
convenience.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Each region is displayed in almost the same way. Break out this common code
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Fix the following compiler warnings when DEBUG is on.
warning: 'bar_res' may be used uninitialized in this function.
drivers/pci/pci_auto.c:101:21:
if (!enum_only && pciauto_region_allocate(bar_res, bar_size,
^
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Building pci_rom.c with my toolchain complains about may be used uninitialized
rom varaible:
---8<---
+drivers/pci/pci_rom.c:269:25: note: 'rom' was declared here
w+drivers/pci/pci_rom.c: In function 'dm_pci_run_vga_bios':
w+drivers/pci/pci_rom.c:154:14: warning: 'rom' may be used uninitialized in this function [-Wmaybe-uninitialized]
--->8---
Fix this as done in 55616b86c7 the ram variable.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
With CONFIG_DM_PCI enabled, PCI buses are not enumerated at boot, as they
are without that config option enabled. No command exists to enumerate the
PCI buses. Hence, unless some board-specific code causes PCI enumeration,
PCI-based Ethernet devices are not detected, and network access is not
available.
This patch implements "pci enum" in the CONFIG_DM_PCI case, thus giving a
mechanism whereby PCI can be enumerated.
do_pci()'s handling of case 'e' is moved into a single location before the
dev variable is assigned, in order to skip calculation of dev. The enum
sub-command doesn't need the dev value, and skipping its calculation
avoids an irrelevant error being printed.
Using a command to initialize PCI like this has a disadvantage relative to
enumerating PCI at boot. In particular, Ethernet devices are not probed
during PCI enumeration, but only when used. This defers setting variables
such as ethact, ethaddr, etc. until the first network-related command is
executed. Hopefully this will not cause further issues. Perhaps in the
long term, we need a "net start/enum" command too?
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function can fail, so be sure to report any errors that occur.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
At present this BIOS emulator uses a bus/device/function number. Change
it to use a device if CONFIG_DM_PCI is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function is only available for compatibility with old code. Avoid
using it in the uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver-model version of the pci_write_bar32 function so that this is
supported in the new API.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function should not be used by driver-model code, so move it to the
compatibility portion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With gcc-5.x we get:
drivers/pci/pci_rom.c: In function 'dm_pci_run_vga_bios':
drivers/pci/pci_rom.c:352:3: warning: 'ram' may be used uninitialized in
this function [-Wmaybe-uninitialized]
While unconvinced that this can happen in practice (if we malloc we set
alloced to true, it will be false otherwise), silence the compiler.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Adjust pci_rom_load() to return an indication of whether it allocated
memory or not. Adjust the caller to free it. This fixes a memory leak
when PCI_VGA_RAM_IMAGE_START is not used.
Reported-by: Coverity (CID: 134194)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
For this class it is intended to set up the PCI device, so add a comment to
indicate this. This avoids a coverity warning.
Reported-by: Coverity (CID: 134194)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Armada XP has support for X4 lanes, boards specify this in their
serdes_cfg. During PEX init in high_speed_env_lib.c, the configuration
is stored in GEN_PURP_RES_2_REG.
When enumerating PEX, subsequent interfaces of an X4 lane must be
skipped. Otherwise the enumeration hangs up the board.
The way this is implemented here is not exactly beautiful, but it mimics
how Marvell's BSP does it. Alternatively we could get the information
using board_serdes_cfg_get(), but that won't lead to clean code, either.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
The debug printing references bar_res, which exists only if
CONFIG_PCI_ENUM_ONLY is not defined. Therefore move it into the ifdef'd
area.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
The current comments are confusing. We don't actually bind a generic device
when the device tree has no information. We try to scan available PCI
drivers. Update the comments to reflect this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We should use the new address mapping functions unless we are in
compatibility mode. Disable the old functions by default.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the PCI address map functions use the old API. Add new functions
for this so that drivers can be converted.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move this function into the compatibility file so that it is not available
by default.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Move these functions into the compatibility file so that they are not
available by default.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function should take a struct udevice rather than pci_dev_t. Update it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Adjust these files to use the driver-model PCI API instead of the legacy
functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add a driver-model function for reading the PCI BAR from a device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a function which scans the driver model device information rather
than scanning the PCI bus again.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
