| Age | Commit message (Collapse) | Author |
|---|
|
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 55616b86c745fcac5a791268ab8e7cba36965c0f 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>
|
|
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>
|
|
At present we are using legacy functions even in the auto-configuration code
used by driver model. Add a new pci_auto.c version which uses the correct
API.
Create a new pci_internal.h header to hold functions that are used within
the PCI subsystem, but are not exported to other drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Most driver model PCI functions have a dm_ prefix. At some point, when the
old code is converted to driver model and the old functions are removed, we
will drop that prefix.
For consistency, we should use the dm_ prefix for all driver model
functions. Update pci_bus_find_bdf() accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Most driver model PCI functions have a dm_ prefix. At some point, when the
old code is converted to driver model and the old functions are removed, we
will drop that prefix.
For consistency, we should use the dm_ prefix for all driver model
functions. Update pci_get_bdf() accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
We don't want people changing the legacy PCI files while migration is in
progress. Update the file headers to indicate that.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
When trying to access non-existent/unsupported PCI devices in
ls_pcie_read_config(), when ls_pcie_addr_valid() fails it returns
error code and fills in the result with 0xffffffff manually. But it
really should return zero to upper layer codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
|
|
When trying to access non-existent/unsupported PCI devices in
imx_pcie_read_config(), when imx_pcie_addr_valid() fails it returns
error code and fills in the result with 0xffffffff manually. But it
really should return zero to upper layer codes.
Reported-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
|
|
These are currently dead codes. Until we have complete ACPI support,
we don't know if it works or not. Remove to avoid confusion.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
We eventually need to drop the compatibility functions for driver model. As
a first step, create a configuration option to enable them and hide them
when the option is disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Some functions will be used by driver model and legacy PCI code. To avoid
duplication, put these in a separate, shared file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This file should not be used with driver model as it has lots of legacy/
compatibility functions. Rename it to make this clear.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Adjust the Tegra PCI driver to support driver model and move all boards over
at the same time. This can make use of some generic driver model code, such
as the range-decoding logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
This function looks up the controller and returns a pointer to each region
type.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
A PCI bus may be a bridge device where the controller is the bridge's
parent. Add a function to return the controller device, given a PCI device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
Provide a few functions to support using 32-bit access to emulate 8- and
16-bit access.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
At present we add a new resource entry for every range entry. But some range
entries refer to configuration regions. To make this work, avoid adding two
regions of the same type. The later ranges will overwrite the earlier
(configuration) ones.
There does not seem to be a way to distinguish the configuration ranges
other than by ordering (as per the device tree binding).
We could perhaps instead just store one region of each type in a simple
array. Once we are sure that we don't need to support multiple regions, we
could change this. It would be easier to do it when all drivers are
converted to use driver model for PCI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
SDRAM doesn't always start at 0. Adjust the region mapping so that it works
on platforms where SDRAM is somewhere else.
This needs testing on other platforms.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
Move this option to Kconfig and fix up all users.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
The endian and base address of PEX LUT register region is different
between Chassis 2 and Chassis 3, so move the base address definition
to chassis specific header file and add pex_lut_* functions to access
LUT register.
Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
Signed-off-by: Gong Qianyu <Qianyu.Gong@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
Freescale's LS2085A is a another personality of LS2080A SoC with
support of AIOP and DP-DDR.
This Patch adds support of LS2085A Personality.
Signed-off-by: Pratiyush Mohan Srivastava <pratiyush.srivastava@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
[York Sun: Updated MAINTAINERS files
Dropped #ifdef in cpu.h
Add CONFIG_SYS_NS16550=y in defconfig]
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
LS2080A is a prime personality of Freescale’s LS2085A. It is a non-AIOP
personality without support of DP-DDR, L2 switch, 1588, PCIe endpoint etc.
So renaming existing LS2085A code base to reflect LS2080A (Prime personality)
Signed-off-by: Pratiyush Mohan Srivastava <pratiyush.srivastava@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
[York Sun: Dropped #ifdef in cpu.c for cpu_type_list]
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
The address range check may overflow if the memory region is located at
the top of the 32-bit address space. This can e.g. be seen on TK1 if
using the E1000 gigabit Ethernet driver where start and size are both
0x80000000 leading to the following messages:
Apalis TK1 # tftpboot $loadaddr test_file
Using e1000#0 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'test_file'.
Load address: 0x80408000
Loading: pci_hose_phys_to_bus: invalid physical address
This patch fixes this by changing the order of the addition vs.
subtraction in the range check just like already done in
__pci_hose_bus_to_phys().
Reported-by: Ivan Mercier <ivan.mercier@nexvision.fr>
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
|
|
When converting between PCI bus and phys addresses, a two pass search
was introduced with preference to non-PCI_REGION_SYS_MEMORY regions.
See commit 2d43e873a29ca4959ba6a30fc7fb396d3fd0dccf.
However, since PCI_REGION_MEM is defined as 0, the if statement was
always asserted true: ((flags & PCI_REGION_MEM) == PCI_REGION_MEM)
This patch uses PCI_REGION_TYPE bit to check if the region is
PCI_REGION_MEM: ((flags & PCI_REGION_TYPE) == PCI_REGION_MEM)
Signed-off-by: Cheng Gu <chenggu@marvell.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This needs a separate compatible value from Tegra124 since the new HW
version has bugs that would prevent a driver for previous HW versions
from operating at all.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
The board PCI setup code may control regulators that are required simply
to bring up the PCI controller itself (or PLLs, IOs, ... it uses). Move
the call to this function earlier so that all board-provided resources
are ready early enough for everything to work.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
