| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Tegra210's PCIe controller has a bug that requires the PCA (performance
counter) feature to be enabled. If this isn't done, accesses to device
configuration space will hang the chip for tens of seconds. Implement
the workaround.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
The number of cells used by each entry in the DT ranges property is
determined by the #address-cells/#size-cells properties. Fix the code
to respect this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Tegra peripherals can generally access a 32-bit physical address space,
and I believe this applies to PCIe. Clip the PCI region that refers to
DRAM so it fits into 32-bits to avoid issues.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
There are two LS series processors are built on ARMv8 Layersacpe
architecture currently, LS2085A and LS1043A. They are based on
ARMv8 core although use different chassis, so create fsl-layerscape
to refactor the common code for the LS series processors which also
paves the way for adding LS1043A platform.
Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
Signed-off-by: Hou Zhiqiang <B48286@freescale.com>
Signed-off-by: Gong Qianyu <Qianyu.Gong@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
|
|
To support graphics card behind a PCI bridge, the bridge control
register (offset 0x3e) in the configuration space must turn on
VGA address forwarding.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Currently pci_last_busno() only checks the last bridge device
under the first UCLASS_PCI device. This is not the case when
there are multiple bridge devices.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
PCI_COMMAND_IO bit must be set for VGA device as it needs to respond
to legacy VGA IO address.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
