u-boot.git/drivers/pci, branch v2011.06

IXP42x PCI rewrite

2011-06-23T06:25:18+00:00

clean up IXP PCI handling: get rid of IXP-private bus scan, BAR assign etc.
code and use u-boot's PCI infrastructure instead.  Move board-specific PCI
setup code (clock/reset) to board directory.

Signed-off-by: Michael Schwingen

fsl_pci: Add support for FSL PCIe controllers v2.x

2011-04-04T14:24:41+00:00

FSL PCIe controller v2.1:
	- New MSI inbound window
	- Same Inbound windows address as PCIe controller v1.x

Added new pit_t member(pmit) to struct ccsr_pci for MSI inbound window

FSL PCIe controller v2.2 and v2.3:
	- Different addresses for PCIe inbound window 3,2,1
	- Exposed PCIe inbound window 0
	- New PCIe interrupt status register

Added new Interrupt Status register to struct ccsr_pci & updated pit_t array
size to reflect the 4 inbound windows.

To maintain backward compatiblilty, on V2.2 or greater controllers we
start with inbound window 1 and leave inbound 0 with its default value
(which maps to CCSRBAR).

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Kumar Gala

powerpc/85xx: Handle PCIe initialization requires for P1021 class SoCs

2011-03-29T12:41:37+00:00

The P1011, P1012, P1015, P1016, P1020, P1021, P1024, & P1025 SoCs require
that we initialize the SERDES registers if the lanes are configured for
PCIe.  Additionally these devices PCIe controller do not support ASPM
and we have to explicitly disable it.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Kumar Gala

Minor Coding Style Cleanup.

2011-02-02T21:36:10+00:00

Signed-off-by: Wolfgang Denk

fsl_pci: Update PCIe boot ouput

2011-01-14T07:32:21+00:00

This change does the following:
- Adds printing of negotiated link width.  This information can be
  useful when debugging PCIe issues.
- Makes it optional for boards to implement board_serdes_name().
  Previously boards that did not implement it would print unsightly
  output such as "PCIE1: Connected to ..."
- Rewords the PCIe boot output to reduce line length and to make it
  clear that the "base address XYZ" value refers to the base address of
  the internal processor PCIe registers and not a standard PCI BAR
  value.
- Changes "PCIE" output to the standard "PCIe"

Before change:
PCIE1: connected to  as Root Complex (base addr ef008000)
  01:00.0     - 10b5:8518 - Bridge device
   02:01.0    - 10b5:8518 - Bridge device
   02:02.0    - 10b5:8518 - Bridge device
   02:03.0    - 10b5:8518 - Bridge device
PCIE1: Bus 00 - 05
PCIE2: connected to  as Endpoint (base addr ef009000)
PCIE2: Bus 06 - 06

After change:
PCIe1: Root Complex of PEX8518 Switch, x4, regs @ 0xef008000
  01:00.0     - 10b5:8518 - Bridge device
   02:01.0    - 10b5:8518 - Bridge device
   02:02.0    - 10b5:8518 - Bridge device
   02:03.0    - 10b5:8518 - Bridge device
PCIe1: Bus 00 - 05
PCIe2: Endpoint of VPX Fabric A, x2, regs @ 0xef009000
PCIe2: Bus 06 - 06

Signed-off-by: Peter Tyser 
Signed-off-by: Kumar Gala

powerpc/fsl-pci: Add generic code to setup PCIe controllers

2011-01-14T07:32:19+00:00

Since all the PCIe controllers are connected over SERDES on the SoCs we
can utilize is_serdes_configured() to determine if a controller is
enabled.  After which we can setup the ATMUs and LAWs for the controller
in a common fashion and allow board code to specify what the controller
is connected to for reporting reasons.

We also provide a per controller (rather than all) for some systems that
may have special requirements.

Finally, we refactor the code used by the P1022DS to utilize the new
generic code.

Based on patch by: Li Yang 

Signed-off-by: Kumar Gala

powerpc/fsl-pci: Determine pci_controller based on cfg addr for dts fixup

2011-01-14T07:32:19+00:00

Previously we passed in a specifically named struct pci_controller to
determine if we had setup the particular PCI bus.  Now we can search for
the struct so we dont have to depend on the name or the struct being
statically allocated.

Introduced new find_hose_by_cfg_addr() to get back a pci_controller struct
back by searching for it means we can do things like dynamically allocate
them or not have to expose the static structures to all users.

Signed-off-by: Kumar Gala 
Acked-by: Wolfgang Denk

74xx_7xx: Cleanup for partial linking and --gc-sections

2010-11-27T22:35:12+00:00

Signed-off-by: Wolfgang Denk 
Acked-by: Stefan Roese

Switch from archive libraries to partial linking

2010-11-17T20:02:18+00:00

Before this commit, weak symbols were not overridden by non-weak symbols
found in archive libraries when linking with recent versions of
binutils.  As stated in the System V ABI, "the link editor does not
extract archive members to resolve undefined weak symbols".

This commit changes all Makefiles to use partial linking (ld -r) instead
of creating library archives, which forces all symbols to participate in
linking, allowing non-weak symbols to override weak symbols as intended.
This approach is also used by Linux, from which the gmake function
cmd_link_o_target (defined in config.mk and used in all Makefiles) is
inspired.

The name of each former library archive is preserved except for
extensions which change from ".a" to ".o".  This commit updates
references accordingly where needed, in particular in some linker
scripts.

This commit reveals board configurations that exclude some features but
include source files that depend these disabled features in the build,
resulting in undefined symbols.  Known such cases include:
- disabling CMD_NET but not CMD_NFS;
- enabling CONFIG_OF_LIBFDT but not CONFIG_QE.

Signed-off-by: Sebastien Carlier

pci: Use intelligent indentation for CONFIG_PCI_SCAN_SHOW

2010-11-14T22:46:48+00:00

When CONFIG_PCI_SCAN_SHOW is defined U-Boot prints out PCI devices as
they are found during bootup, eg:
  PCIE1: connected as Root Complex
        01:00.0 - 10b5:8518 - Bridge device
        02:01.0 - 10b5:8518 - Bridge device
        03:00.0 - 10b5:8112 - Bridge device
        04:01.0 - 8086:1010 - Network controller
        04:01.1 - 8086:1010 - Network controller
        02:02.0 - 10b5:8518 - Bridge device
        02:03.0 - 10b5:8518 - Bridge device
        06:00.0 - 10b5:8518 - Bridge device
        07:00.0 - 10b5:8518 - Bridge device
        08:00.0 - 1957:0040 - Processor
        07:01.0 - 10b5:8518 - Bridge device
        09:00.0 - 10b5:8112 - Bridge device
        07:02.0 - 10b5:8518 - Bridge device
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
        0d:00.0 - 1957:0040 - Processor
  PCIE2: Bus 0c - 0d

This information is useful, but its difficult to determine the PCI bus
topology.  To things clearer, we can use indention to make it more
obvious how the PCI bus is organized.  For the example above, the
updated output with this change is:

  PCIE1: connected as Root Complex
    01:00.0     - 10b5:8518 - Bridge device
     02:01.0    - 10b5:8518 - Bridge device
      03:00.0   - 10b5:8112 - Bridge device
       04:01.0  - 8086:1010 - Network controller
       04:01.1  - 8086:1010 - Network controller
     02:02.0    - 10b5:8518 - Bridge device
     02:03.0    - 10b5:8518 - Bridge device
      06:00.0   - 10b5:8518 - Bridge device
       07:00.0  - 10b5:8518 - Bridge device
        08:00.0 - 1957:0040 - Processor
       07:01.0  - 10b5:8518 - Bridge device
        09:00.0 - 10b5:8112 - Bridge device
       07:02.0  - 10b5:8518 - Bridge device
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
    0d:00.0     - 1957:0040 - Processor
  PCIE2: Bus 0c - 0d

In the examples above, an MPC8640 is connected to a PEX8518 PCIe switch
(01:00 and 02:0x), which is connected to another PEX8518 PCIe switch
(06:00 and 07:0x), which then connects to a MPC8572 processor (08:00).
Also, the MPC8640's PEX8518 PCIe switch is connected to a PCI ethernet
card (04:01) via a PEX8112 PCIe-to-PCI bridge (03:00).

Signed-off-by: Peter Tyser