Currently, if we happen to allocate an address requiring 64 bits to a
device only supporting 32-bit BARs, the address eventually gets silently
truncated to 32 bits. Avoid this by adding a new flag to
pciauto_region_allocate() to bail out in such situations.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-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>
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>
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>
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>
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>
PCI_HEADER_TYPE register (offset 0x0e) bit 7 is an indicator
for multi-function devices. We should mask it off before using
it as the header type.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
At present the PCI output displays 'Mem' when it allocates memory for a PCI
device, whether it is prefetchable or not. There is a distinction since the
memory comes from separate pools. Use 'Prf' instead of 'Mem' when allocating
prefetchable memory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This option is not used by any board but appears to still be useful, at least
for testing. With recent commits it does not build, so fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This file does not need its own way of doing debug(). Clean it up to use the
new way.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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 driver model, each pci bridge device has its own hose structure.
hose->first_busno points to the bridge device's device number, so
we should not substract hose->first_busno before programming the
bridge device's primary/secondary/subordinate bus number registers.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Currently PCI expansion ROM address is assigned by a call to
pciauto_setup_rom() outside of the pci auto config process.
This does not work when expansion ROM is on a device behind
PCI bridge where bridge's memory limit register was already
programmed to a value that does not cover the newly assigned
expansion ROM address. To fix this, we should configure the
ROM address during the auto config process.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
The legacy IDE device has a BAR4 (Bus Master Interface BAR) which
needs to be configured.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Remove the '#undef DEBUG' in pci_auto.c so that we can enable debug
message output via '-DDEBUG'.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-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>
PCI specification allow prefetchable memory to be 32-bit or 64-bit.
PCI express specification states that all memmory bars for prefetchable
memory must be implemented as 64-bit. They all require that 64 bit
prefetchble memory are suported especially when u-boot is ported to
more and more 64bit processors.
Signed-off-by: David Feng <fenghua@phytium.com.cn>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
U-Boot has never cared about the type when we get max/min of two
values, but Linux Kernel does. This commit gets min, max, min3, max3
macros synced with the kernel introducing type checks.
Many of references of those macros must be fixed to suppress warnings.
We have two options:
- Use min, max, min3, max3 only when the arguments have the same type
(or add casts to the arguments)
- Use min_t/max_t instead with the appropriate type for the first
argument
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Pavel Machek <pavel@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[trini: Fixup arch/blackfin/lib/string.c]
Signed-off-by: Tom Rini <trini@ti.com>
Forcibly set hose->pci_prefetch to NULL to make sure it will be setup.
This will help if for any reason callers didn't make sure themselves to
NULL the field.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The following commit introduced some warnings associated with using
pci_addr_t instead of a proper 32-bit data type.
commit af778c6d9e
Author: Andrew Sharp <andywyse6@gmail.com>
Date: Wed Aug 1 12:27:16 2012 +0000
pci: fix errant data types and corresponding access functions
On some platforms pci_addr_t is defined as a 64-bit data type so its not
proper to use with pci_{read,write}_config_dword.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Introduce CONFIG_PCI_ENUM_ONLY variable for platforms that just want a
quick enumberation of the PCI devices, but don't need any setup work done.
This is very beneficial on platforms that have u-boot loaded by another
boot loader which does a more sophisticated job of setup of PCI devices
than u-boot. That way, u-boot can just read what's there and get on
with life. This is what SeaBIOS does.
Signed-off-by: Andrew Sharp <andywyse6@gmail.com>
I tried to clean up the white space and formatting offenses and
inconsistencies in the generic PCI code that obviously has been around for
some time. Emphasis on large increases in readability and maintainability
and consistency. I omitted the platform/processor specific files in
the drivers/pci directory because I wanted to leave those file to those
that care more about them.
Signed-off-by: Andrew Sharp <andywyse6@gmail.com>
In a couple of places, unsigned int and pci_config_*_dword were being
used when u16 and _word should be used. Unsigned int was also being
used in a couple of places that should be pci_addr_t.
Signed-off-by: Andrew Sharp <andywyse6@gmail.com>
As discussed on the list, move "arch/ppc" to "arch/powerpc" to
better match the Linux directory structure.
Please note that this patch also changes the "ppc" target in
MAKEALL to "powerpc" to match this new infrastructure. But "ppc"
is kept as an alias for now, to not break compatibility with
scripts using this name.
Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Acked-by: Detlev Zundel <dzu@denx.de>
Acked-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Anatolij Gustschin <agust@denx.de>
This patch adds support for the esd VME8349 board equipped with the
MPC8349. It's a VME PMC carrier board equipped with the Tundra
TSI148 VME-bridge.
Signed-off-by: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Use the standard lowercase "x" capitalization that other Freescale
architectures use for CPU defines to prevent confusion and errors
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
PCI bus is inherently 64-bit. While not all system require access to
the full 64-bit PCI address range some do. This allows those systems
to enable the full PCI address width via CONFIG_SYS_PCI_64BIT.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andrew Fleming-AFLEMING <afleming@freescale.com>
Acked-by: Wolfgang Denk <wd@denx.de>
Remove test for CONFIG_MPC5200 in drivers/pci/pci_auto.c and define
CONFIG_PCIAUTO_SKIP_HOST_BRIDGE in related board configuration files.
Signed-off-by: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
The 440EPx has a problem when the PCI_CACHE_LINE_SIZE register is
set to non-zero, because it doesn't support MRM (memory-read-
multiple) correctly. We now added the possibility to configure
this register in the board config file, so that the default value
of 8 can be overridden.
Here the details of this patch:
o drivers_pci_auto.c: introduce CFG_PCI_CACHE_LINE_SIZE to allow
board-specific settings. As an example the sequoia board requires 0.
Idea from Stefan Roese <sr@denx.de>.
o board/amcc/sequoia/init.S: add a TLB mapping at 0xE8000000 for the
PCI IO-space. Obtained from Stefan Roese <sr@denx.de>.
o include/configs/sequoia.h: turn CONFIG_PCI_PNP back on and set
CFG_PCI_CACHE_LINE_SIZE to 0.
Signed-off-by: Gary Jennejohn <garyj@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Passing bars_num=0 to pciauto_setup_device should assign no bars.
Signed-off-by: Ed Swarthout <Ed.Swarthout@freescale.com>
Acked-by: Shinya Kuribayashi <shinya.kuribayashi@necel.com>
Acked-by: Andy Fleming <afleming@freescale.com>
If a PCI IDE card happens to get a zero address assigned to it, the Linux IDE
core complains and IDE drivers fails to work. Also, assigning zero to a BAR
was illegal according to PCI 2.1 (the later revisions seem to have excluded the
sentence about "0" being considered an invalid address) -- so, use a reasonable
starting value of 0x1000 (that's what the most Linux archs are using).
Alternatively, one might have fixed the calls to pci_set_region() individually
(some code even seems to have taken care of this issue) but that would have
been a lot more work. :-)
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Stefan Roese <sr@denx.de>
If a PCI IDE card happens to get a zero address assigned to it, the Linux IDE
core complains and IDE drivers fails to work. Also, assigning zero to a BAR
was illegal according to PCI 2.1 (the later revisions seem to have excluded the
sentence about "0" being considered an invalid address) -- so, use a reasonable
starting value of 0x1000 (that's what the most Linux archs are using).
Alternatively, one might have fixed the calls to pci_set_region() individually
(some code even seems to have taken care of this issue) but that would have
been a lot more work. :-)
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Stefan Roese <sr@denx.de>
During the pci scan process, Some devices return bar_reponse with the
highest bytes 0, such as the pci bridge in uli1575 return bar_response
with 0xffffff, So the bar_size should be manually set under 64K.
Signed-off-by: Jason Jin <jason.jin@freescale.com>
If a host controller sets up a region as prefetchable and
a device's BAR denotes it as prefetchable, allocate the
BAR into the prefetch region.
If a BAR is prefetchable and no prefetchable region has
been setup by the controller we fall back to allocating
the BAR into the normally memory region.
Patch by Kumar Gala 11 Jan 2006
o 440GX:
- Fix PCI Indirect access for type 1 config cycles with ppc440.
- Add phymode for 440 enet
- fix pci pre init
o XPedite1K:
- Change board_pre_init to board_early_init_f
- Add user flash to bus controller setup
- Fix pci pre init
- Fix is_pci_host to check GPIO for monarch bit
- Force xpedite1k to pci conventional mode (via #define option)
* Patch by Brad Kemp, 4 Feb 2004:
- handle the machine check that is generated during the PCI scans
on 82xx processors.
- define the registers used in the IMMR by the PCI subsystem.
* Patch by Pierre Aubert, 03 Feb 2004:
cpu/mpc5xxx/start.S: copy MBAR into SPR311
* Patch by Jeff Angielski, 03 Feb 2004:
Fix copy & paste error in cpu/mpc8260/pci.c
* Patch by Reinhard Meyer, 24 Jan 2004:
Fix typo in cpu/mpc5xxx/pci_mpc5200.c
Tuomas Tynkkynen
Tom Rini
Phil Sutter
Simon Glass
Bin Meng
David Feng
Masahiro Yamada
Thierry Reding
Wolfgang Denk
Kumar Gala
Andrew Sharp
Stefan Roese
Reinhard Arlt
Peter Tyser
Jean-Christophe PLAGNIOL-VILLARD
TsiChung Liew
Gary Jennejohn
Ed Swarthout
Sergei Shtylyov
Matthew McClintock
Jin Zhengxiong-R64188
Jon Loeliger
Rafal Jaworowski
wdenk