Introduce device_is_on_pci_bus() which can be utilized by driver
to test if a device is on a PCI bus.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
At present, until a PCI bus is probed, it cannot be found by its sequence
number unless it has an alias. This is the same with any device.
However with PCI this is more annoying than usual, since bus 0 is always the
same device.
Add a function that tries a little harder to locate PCI bus 0. This means
that PCI enumeration will happen automatically on the first access.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If there is no pci device listed in the device tree,
don't bother scanning the device tree.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
In pci_uclass_child_post_bind(), bdf is extracted from fdt_pci_addr.
Mask bus number before save it to pplat->devfn.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Per Intel FSP specification, we should call FSP notify API to
inform FSP that PCI enumeration has been done so that FSP will
do any necessary initialization as required by the chipset's
BIOS Writer's Guide (BWG).
Unfortunately we have to put this call here as with driver model,
the enumeration is all done on a lazy basis as needed, so until
something is touched on PCI it won't happen.
Note we only call this after U-Boot is relocated and root bus has
finished probing.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
On some platforms pci devices behind bridge need to be probed (eg:
a pci uart on recent x86 chipset) before relocation. But we won't
bind all devices found during the enumeration. Only devices whose
driver with DM_FLAG_PRE_RELOC set will be bound. Any other generic
devices except bridges won't be bound.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This reverts commit df189d9ba3.
Unfortunately this commit breaks chromebook_link because it adds lots of PCI devices
before relocation and there is not enough pre-reloc malloc() memory.
Rathar then increase this memory, revert for now until we figure this out.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These functions allow iteration through all PCI devices including bridges.
The children of each PCI bus are returned in turn. This can be useful for
configuring, checking or enumerating all the devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present there are no PCI functions which allow access to PCI
configuration using a struct udevice. This is a sad situation for driver
model as it makes use of PCI harder. Add these functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
On some platforms pci devices behind bridge need to be probed (eg:
a pci uart on recent x86 chipset) before relocation. Remove such
limitation so that dm pci can be used before relocation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Commit aec241d "dm: pci: Use the correct hose when configuring devices"
was an attempt to fix pci bridge device configuration, but unfortunately
that does not work 100%. In pciauto_config_devices(), the fix tried to
call pciauto_config_device() with a ctlr_hose which is supposed to be
the root controller hose, however when walking through a pci topology
with 2 or more pci bridges this logic simply fails.
The call chain is: pciauto_config_devices()->pciauto_config_device()
->dm_pci_hose_probe_bus(). Here the call to dm_pci_hose_probe_bus()
does not make any sense as the given hose is not the bridge device's
hose, instead it is either the root controller's hose (case#1: if it
is the 2nd pci bridge), or the bridge's parent bridge's hose (case#2:
if it is the 3rd pci bridge). In both cases the logic is wrong.
For example, for failing case#1 if the bridge device to config has the
same devfn as one of the devices under the root controller, the call
to pci_bus_find_devfn() will return the udevice of that pci device
under the root controller as the bus, but this is wrong as the udevice
is not a bus which does not contain all the necessary bits associated
with the udevice which causes further failures.
To correctly support pci bridge device configuration, we should still
call pciauto_config_device() with the pci bridge's hose directly.
In order to access valid pci region information, we need to refer to
the root controller simply by a call to pci_bus_to_hose(0) and get the
region information there in the pciauto_prescan_setup_bridge(),
pciauto_postscan_setup_bridge() and pciauto_config_device().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
In dm_pci_hose_probe_bus(), pci_bus_find_devfn() is called with a bdf
which includes a bus number, but it really should not as this routine
only expects a device/function encoding.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Currently pci_bus_read_config() and pci_bus_write_config() are
called with bus number masked off in the parameter bdf, and bus
number is supposed to be added back in the bridge driver's pci
config read/write ops if the device is behind a pci bridge.
However this logic only works for a pci topology where there is
only one bridge off the root controller. If there is addtional
bridge in the system, the logic will create a non-existent bdf
where its bus number gets accumulated across bridges.
To correct this, we change all pci config read/write routines
to use complete bdf all the way up to the root controller.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
It is useful to be able to find the full PCI address (bus, device and
function) for a PCI device. Add a function to provide this.
Adjust the existing code to use this.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present all PCI devices must be present in the device tree in order to
be used. Many or most PCI devices don't require any configuration other than
that which is done automatically by U-Boot. It is inefficent to add a node
with nothing but a compatible string in order to get a device working.
Add a mechanism whereby PCI drivers can be declared along with the device
parameters they support (vendor/device/class). When no suitable driver is
found in the device tree the list of such devices is consulted to determine
the correct driver. If this also fails, then a generic driver is used as
before.
The mechanism used is very similar to that provided by Linux and the header
file defintions are copied from Linux 4.1.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Commit afbbd413a fixed this for non-driver-model. Make sure that the driver
model code handles this also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The sub-bus passed to pciauto_prescan_setup_bridge() is incorrect. Fix it
so that sub-buses are numbered correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Only the PCI controller has access to the PCI region information. Make sure
to use the controller (rather than any attached bridges) when configuring
devices.
This corrects a failure to scan and configure devices when driver model is
enabled for PCI.
Also add a comment to explain the problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Commit 9cc36a2 'dm: core: Add a flag to control sequence numbering' changed
the default uclass behaviour to not support bus numbering. This is incorrect
for PCI and that commit should have enabled the flag for PCI.
Enable it so that PCI buses can be found and the 'pci' command works again.
Also add a test for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a uclass for PCI controllers and a generic one for PCI devices. Adjust
the 'pci' command and the existing PCI support to work with this new uclass.
Keep most of the compatibility code in a separate file so that it can be
removed one day.
TODO: Add more header file comments to the new parts of pci.h
Signed-off-by: Simon Glass <sjg@chromium.org>
