summaryrefslogtreecommitdiff
path: root/drivers/pci
Commit message (Collapse)AuthorAgeLines
* Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'Albert ARIBAUD2014-02-19-0/+607
|\
| * pci: mx6: Implement reset callbackMarek Vasut2014-02-11-3/+44
| | | | | | | | | | | | | | Add a callback so that a board can implement it's own specific routine to toggle the port's #PERST line or #define a GPIO to do so. Signed-off-by: Marek Vasut <marex@denx.de>
| * ARM: mx6: Add PCI express driverMarek Vasut2014-01-26-0/+566
| | | | | | | | | | | | | | | | | | | | | | | | Add PCIe driver for the Freescale i.MX6 SoC . This driver operates the PCIe block in RC mode only, the EP mode is NOT supported. The driver is tested with the Intel e1000 NIC driver. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Eric Nelson <eric.nelson@boundarydevices.com> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de>
* | Merge branch 'u-boot-pxa/master' into 'u-boot-arm/master'Albert ARIBAUD2014-02-19-352/+0
|\ \
| * | ARM: PCI: Remove the IXP PCI driverMarek Vasut2014-02-06-352/+0
| |/ | | | | | | | | | | | | | | | | The driver is no longer used, remove it. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Michael Schwingen <michael@schwingen.org> Cc: Tom Rini <trini@ti.com>
* | driver/fsl_pci:Update print to display PCIe generationPrabhakar Kushwaha2014-02-03-2/+2
|/ | | | | | | | Current print only display width of PCIe device. Add print to display PCIe generation supported by the device. Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* malta: support for coreFPGA6 boardsPaul Burton2013-11-09-0/+126
| | | | | | | | | | | | | | | | | | | | | This patch adds support for running on Malta boards using coreFPGA6 core cards, including support for the msc01 system controller used with them. The system controller is detected at runtime allowing one U-boot binary to run on a Malta with either. Due to the PCI I/O base differing between Maltas using gt64120 & msc01 system controllers, the UART setup is modified slightly. A second UART is added so that there is one pointing at the correct address for each system controller. The Malta board then defines its own default_serial_console function to select the correct one at runtime. The incorrect UART will simply not function. Tested on: - A coreFPGA6 Malta running interAptiv and proAptiv bitstreams, both with and without an L2 cache. - QEMU. Signed-off-by: Paul Burton <paul.burton@imgtec.com>
* drivers: convert makefiles to Kbuild styleMasahiro Yamada2013-10-31-33/+11
| | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* PCIe:change the method to get the address of a requested capability in ↵Zhao Qiang2013-10-16-12/+97
| | | | | | | | | | | | | | | | | | | configuration space. Previously, the address of a requested capability is define like that "#define PCI_DCR 0x78" But, the addresses of capabilities is different with regard to PCIe revs. So this method is not flexible. Now a function to get the address of a requested capability is added and used. It can get the address dynamically by capability ID. The step of this function: 1. Read Status register in PCIe configuration space to confirm that Capabilities List is valid. 2. Find the address of Capabilities Pointer Register. 3. Find the address of requested capability from the first capability. Signed-off-by: Zhao Qiang <B45475@freescale.com>
* pci: Properly configure prefetchable memory regionThierry Reding2013-10-07-1/+1
| | | | | | | | 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>
* powerpc/pcie: add PCIe version 3.x supportZang Roy-R619112013-08-09-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | T4240 PCIe IP is version 3.0 and has some update comparing previous QorIQ products. 1. Move Freescale specific register define to arch/powerpc/include/asm/fsl_pci.h and update the register offset define for T4240. 2. add the status/control register define use status/control register to judge the link status 3. The original code uses 'Programming Interface' field to judge if PCIE is EP or RC mode, however, T4240 does not support this functionality. According to PCIE specification, 'Header Type' offset 0x0e is used to indicate header type, so for PCIE controller, the patch changes code to use 'Header Type' field to identify if the PCIE is RC or EP mode. This patch fixes the PCIe card link up issue on T4240QDS. Signed-off-by: Roy Zang <tie-fei.zang@freescale.com> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com> Signed-off-by: York Sun <yorksun@freescale.com>
* Merge branch 'master' of git://git.denx.de/u-boot-nds32Tom Rini2013-07-25-84/+2
|\
| * pci: move pci_ftpci100.h to include/faraday/ftpci100.hGabor Juhos2013-07-24-98/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though the header files is used only by the pci_ftpci100 driver, it contains declaration for a function which is used by external code. Move the header file to a common location which lets external code use it. Compile tested only. Cc: Macpaul Lin <macpaul@andestech.com> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
| * pci: add prototype for pci_ftpci_init() functionGabor Juhos2013-07-24-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The pci_ftpci_init() function is implemented in 'drivers/pci/pci_ftpci100.c' however it is always called by external code. Add function declaration into ftpci100.h to make it visible for external code. Compile tested only. Cc: Macpaul Lin <macpaul@andestech.com> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
* | qemu-malta: Update for SPDX license identifiersTom Rini2013-07-25-3/+1
| | | | | | | | Signed-off-by: Tom Rini <trini@ti.com>
* | MIPS: qemu-malta: add PCI supportGabor Juhos2013-07-24-0/+179
| | | | | | | | | | | | | | | | | | | | | | Qemu emulates the Galileo GT64120 System Controller which provides a CPU bus to PCI bus bridge. The patch adds driver for this bridge and enables PCI support for the emulated Malta board. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
* | Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-184/+13
|/ | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* powerpc/boot: Change the macro of Boot from SRIO and PCIE master moduleLiu Gang2013-06-20-3/+3
| | | | | | | | | | | | | | | | | Currently, the macro "CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER" can enable the master module of Boot from SRIO and PCIE on a platform. But this is not a silicon feature, it's just a specific booting mode based on the SRIO and PCIE interfaces. So it's inappropriate to put the macro into the file arch/powerpc/include/asm/config_mpc85xx.h. Change the macro "CONFIG_SYS_FSL_SRIO_PCIE_BOOT_MASTER" to "CONFIG_SRIO_PCIE_BOOT_MASTER", remove them from arch/powerpc/include/asm/config_mpc85xx.h file, and add those macros in configuration header file of each board which can support the master module of Boot from SRIO and PCIE. Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
* pci: introduce CONFIG_PCI_INDIRECT_BRIDGE optionGabor Juhos2013-06-07-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pci_indirect.c file is always compiled when CONFIG_PCI is defined although the indirect PCI bridge support is not needed by every board. Introduce a new CONFIG_PCI_INDIRECT_BRIDGE config option and only compile indirect PCI bridge support if this options is enabled. Also add the new option into the configuration files of the boards which needs that. Compile tested for powerpc, x86, arm and nds32. MAKEALL results: powerpc: --------------------- SUMMARY ---------------------------- Boards compiled: 641 Boards with warnings but no errors: 2 ( ELPPC MPC8323ERDB ) ---------------------------------------------------------- Note: the warnings for ELPPC and MPC8323ERDB are present even without the actual patch. x86: --------------------- SUMMARY ---------------------------- Boards compiled: 1 ---------------------------------------------------------- arm: --------------------- SUMMARY ---------------------------- Boards compiled: 311 ---------------------------------------------------------- nds32: --------------------- SUMMARY ---------------------------- Boards compiled: 3 ---------------------------------------------------------- Cc: Tom Rini <trini@ti.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
* powerpc/p4080ds: fix PCI-e x8 link training down failureYuanquan Chen2012-11-27-0/+22
| | | | | | | | | | | | Due to SerDes configuration error, if we set the PCI-e controller link width as x8 in RCW and add a narrower width(such as x4, x2 or x1) PCI-e device to PCI-e slot, it fails to train down to the PCI-e device's link width. According to p4080ds errata PCIe-A003, we reset the PCI-e controller link width to x4 in u-boot. Then it can train down to x2 or x1 width to make the PCI-e link between RC and EP. Signed-off-by: Yuanquan Chen <B41889@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
* powerpc/boot: Change the compile macro for SRIO & PCIE boot master moduleLiu Gang2012-10-22-3/+3
| | | | | | | | | | | | | | | | | Currently, the SRIO and PCIE boot master module will be compiled into the u-boot image if the macro "CONFIG_FSL_CORENET" has been defined. And this macro has been included by all the corenet architecture platform boards. But in fact, it's uncertain whether all corenet platform boards support this feature. So it may be better to get rid of the macro "CONFIG_FSL_CORENET", and add a special macro for every board which can support the feature. This special macro will be defined in the header file "arch/powerpc/include/asm/config_mpc85xx.h". It will decide if the SRIO and PCIE boot master module should be compiled into the board u-boot image. Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
* powerpc/mpc85xx: Add T4240 SoCYork Sun2012-10-22-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for Freescale T4240 SoC. Feature of T4240 are (incomplete list): 12 dual-threaded e6500 cores built on Power Architecture® technology Arranged as clusters of four cores sharing a 2 MB L2 cache. Up to 1.8 GHz at 1.0 V with 64-bit ISA support (Power Architecture v2.06-compliant) Three levels of instruction: user, supervisor, and hypervisor 1.5 MB CoreNet Platform Cache (CPC) Hierarchical interconnect fabric CoreNet fabric supporting coherent and non-coherent transactions with prioritization and bandwidth allocation amongst CoreNet end-points 1.6 Tbps coherent read bandwidth Queue Manager (QMan) fabric supporting packet-level queue management and quality of service scheduling Three 64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving support Memory prefetch engine (PMan) Data Path Acceleration Architecture (DPAA) incorporating acceleration for the following functions: Packet parsing, classification, and distribution (Frame Manager 1.1) Queue management for scheduling, packet sequencing, and congestion management (Queue Manager 1.1) Hardware buffer management for buffer allocation and de-allocation (BMan 1.1) Cryptography acceleration (SEC 5.0) at up to 40 Gbps RegEx Pattern Matching Acceleration (PME 2.1) at up to 10 Gbps Decompression/Compression Acceleration (DCE 1.0) at up to 20 Gbps DPAA chip-to-chip interconnect via RapidIO Message Manager (RMAN 1.0) 32 SerDes lanes at up to 10.3125 GHz Ethernet interfaces Up to four 10 Gbps Ethernet MACs Up to sixteen 1 Gbps Ethernet MACs Maximum configuration of 4 x 10 GE + 8 x 1 GE High-speed peripheral interfaces Four PCI Express 2.0/3.0 controllers Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz with Type 11 messaging and Type 9 data streaming support Interlaken look-aside interface for serial TCAM connection Additional peripheral interfaces Two serial ATA (SATA 2.0) controllers Two high-speed USB 2.0 controllers with integrated PHY Enhanced secure digital host controller (SD/MMC/eMMC) Enhanced serial peripheral interface (eSPI) Four I2C controllers Four 2-pin or two 4-pin UARTs Integrated Flash controller supporting NAND and NOR flash Two eight-channel DMA engines Support for hardware virtualization and partitioning enforcement QorIQ Platform's Trust Architecture 1.1 Signed-off-by: York Sun <yorksun@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Andy Fleming <afleming@freescale.com> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
* driver/pci: Fix compiling errorYork Sun2012-10-22-0/+4
| | | | | | | | Fix compiling error in case CONFIG_SYS_PCIE2_MEM_VIRT or CONFIG_SYS_PCIE3_MEM_VIRT not defined. Signed-off-by: York Sun <yorksun@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
* fsl_pci: use 'Header Type' field to judge PCIE modeMinghuan Lian2012-10-22-14/+16
| | | | | | | | | | | The original code uses 'Programming Interface' field to judge if PCIE is EP or RC mode, however, T4240 does not support this functionality. According to PCIE specification, 'Header Type' offset 0x0e is used to indicate header type, so for PCIE controller, the patch changes code to use 'Header Type' field to identify if the PCIE is EP or RC mode. Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
* Merge branch 'master' of git://git.denx.de/u-boot-mpc85xxTom Rini2012-09-25-0/+116
|\
| * powerpc/corenet_ds: Master module for boot from PCIELiu Gang2012-08-23-0/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the powerpc processors with PCIE interface, boot location can be configured from one PCIE interface by RCW. The processor booting from PCIE can do without flash for u-boot image. The image can be fetched from another processor's memory space by PCIE link connected between them. The processor booting from PCIE is slave, the processor booting from normal flash memory space is master, and it can help slave to boot from master's memory space. When boot from PCIE, slave's core should be in holdoff after powered on for some specific requirements. Master will release the slave's core at the right time by PCIE interface. Environment and requirement: master: 1. NOR flash for its own u-boot image, ucode and ENV space. 2. Slave's u-boot image is in master NOR flash. 3. Normally boot from local NOR flash. 4. Configure PCIE system if needed. slave: 1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV. 2. Boot location should be set to one PCIE interface by RCW. 3. RCW should configure the SerDes, PCIE interfaces correctly. 4. Must set all the cores in holdoff by RCW. 5. Must be powered on before master's boot. For the master module, need to finish these processes: 1. Initialize the PCIE port and address space. 2. Set inbound PCIE windows covered slave's u-boot image stored in master's NOR flash. 3. Set outbound windows in order to configure slave's registers for the core's releasing. 4. Should set the environment variable "bootmaster" to "PCIE1", "PCIE2" or "PCIE3" using the following command: setenv bootmaster PCIE1 saveenv Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
* | pci: fix some warnings related to assumptions aboutKumar Gala2012-09-22-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit introduced some warnings associated with using pci_addr_t instead of a proper 32-bit data type. commit af778c6d9e2b945ee03cbc53bb976238a3374f33 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>
* | pci: add CONFIG_PCI_ENUM_ONLY for platforms that don't need PCI setup doneAndrew Sharp2012-09-02-10/+25
| | | | | | | | | | | | | | | | | | | | | | 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>
* | pci: minor cleanup of CONFIG_PCI_PNP usageAndrew Sharp2012-09-02-6/+6
| | | | | | | | | | | | | | | | | | Refactor the common PCI code just a tiny bit surrounding the PCI_PNP (pciauto) stuff. Makes the code a tiny bit easier to read, and also makes it more obvious that almost no platform needs to setup or use the pci_config_table stuff. Signed-off-by: Andrew Sharp <andywyse6@gmail.com>
* | pci: clean up some whitespace and formattingAndrew Sharp2012-09-02-70/+91
| | | | | | | | | | | | | | | | | | | | | | 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>
* | pci: fix errant data types and corresponding access functionsAndrew Sharp2012-09-02-10/+12
|/ | | | | | | | 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>
* pci: declare pciauto functions in headerLinus Walleij2012-03-30-5/+0
| | | | | | | | | | | The FSL PCI driver uses local prototypes for pciauto_[pre|post]scan_setup_bridge(), this does not seem right, so move them to the <pci.h> file. Fixed a small extern declaration too, this is harmless but distracts the view since all other prototypes are explicitly external. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pci: move pciauto_config_init() to pci.hLinus Walleij2012-03-04-2/+0
| | | | | | | | | | | | | Fixing build regressions for the Integrator I get find that a few boards try to work around the missing declaration of pciauto_config_init() by declaring it in the local scope. This does not make sense when the sibling functions are in <pci.h> so move the function to the header, ridding the build error in the Integrator and getting rid of the local declarations here and there. Reported-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* pci_ftpci100: Implementation FTPCI100 PCI driverGavin Guo2011-12-05-0/+425
| | | | | | | | | FTPCI100 is a SoC PCI componenet of Faraday company. Which is usually built into SoC chips for providing embedded PCI functions. Signed-off-by: Gavin Guo <gavinguo@andestech.com> Signed-off-by: Macpaul Lin <macpaul@andestech.com>
* GCC4.6: Squash warnings in fsl_pci_init.cMarek Vasut2011-10-27-4/+4
| | | | | | | | | | | | | | | | | | | | | fsl_pci_init.c: In function 'fsl_pci_init': fsl_pci_init.c:308: warning: format '%08x' expects type 'unsigned int', but argument 6 has type 'long unsigned int' fsl_pci_init.c:347: warning: format '%x' expects type 'unsigned int', but argument 2 has type 'volatile u32 *' fsl_pci_init.c: In function 'fsl_pci_init': fsl_pci_init.c:308: warning: format '%016llx' expects type 'long long unsigned int', but argument 4 has type 'pci_addr_t' fsl_pci_init.c:308: warning: format '%016llx' expects type 'long long unsigned int', but argument 5 has type 'pci_size_t' fsl_pci_init.c:308: warning: format '%08x' expects type 'unsigned int', but argument 6 has type 'long unsigned int' Signed-off-by: Marek Vasut <marek.vasut@gmail.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Mike Frysinger <vapier@gentoo.org>
* pci: move pcidelay code to new location just before PCI bus scanAnatolij Gustschin2011-10-15-13/+17
| | | | | | | | | | | | | | | | | | | | PCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at pci_init_board() time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before calling pci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too. Since pci_hose_scan() could be called multiple times, restrict the function to wait only during its first call and to ignore pcidelay for any further call (as pointed out by Matthias). Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: Matthias Fuchs <matthias.fuchs@esd.eu> Acked-by: Stefan Roese <sr@denx.de> Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu> Tested-by: Matthias Fuchs <matthias.fuchs@esd.eu>
* cleanup: Fix typos and misspellings in various files.Mike Williams2011-07-28-1/+1
| | | | | | | | | | | Recieve/Receive recieve/receive Interupt/Interrupt interupt/interrupt Addres/Address addres/address Signed-off-by: Mike Williams <mike@mikebwilliams.com>
* IXP42x PCI rewriteMichael Schwingen2011-06-23-423/+206
| | | | | | | | 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 <michael@schwingen.org>
* fsl_pci: Add support for FSL PCIe controllers v2.xPrabhakar Kushwaha2011-04-04-2/+10
| | | | | | | | | | | | | | | | | | | | | | | 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 <prabhakar@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* powerpc/85xx: Handle PCIe initialization requires for P1021 class SoCsPrabhakar Kushwaha2011-03-29-0/+7
| | | | | | | | | | 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 <prabhakar@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* Minor Coding Style Cleanup.Wolfgang Denk2011-02-02-1/+1
| | | | Signed-off-by: Wolfgang Denk <wd@denx.de>
* fsl_pci: Update PCIe boot ouputPeter Tyser2011-01-14-18/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <NULL>..." - 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 <NULL> 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 <NULL> 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 <ptyser@xes-inc.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* powerpc/fsl-pci: Add generic code to setup PCIe controllersKumar Gala2011-01-14-0/+148
| | | | | | | | | | | | | | | | | | 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 <leoli@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* powerpc/fsl-pci: Determine pci_controller based on cfg addr for dts fixupKumar Gala2011-01-14-1/+16
| | | | | | | | | | | | | | 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 <galak@kernel.crashing.org> Acked-by: Wolfgang Denk <wd@denx.de>
* 74xx_7xx: Cleanup for partial linking and --gc-sectionsWolfgang Denk2010-11-27-1/+2
| | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> Acked-by: Stefan Roese <sr@denx.de>
* Switch from archive libraries to partial linkingSebastien Carlier2010-11-17-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <sebastien.carlier@gmail.com>
* pci: Use intelligent indentation for CONFIG_PCI_SCAN_SHOWPeter Tyser2010-11-14-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ptyser@xes-inc.com>
* pci: Fix ordering of devices when CONFIG_PCI_SCAN_SHOWPeter Tyser2010-11-14-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the printing of PCI device information to before the PCI device is configured. This prevents the case where recursive scanning results in the deepest devices being printed first. This change also makes PCI lockups during enumeration easier to diagnose since the device that is being configured is printed out prior to configuration. Previously, it was not possible to determine which device caused the PCI lockup. Original example: PCIE1: connected as Root Complex 04:01.0 - 8086:1010 - Network controller 04:01.1 - 8086:1010 - Network controller 03:00.0 - 10b5:8112 - Bridge device 02:01.0 - 10b5:8518 - Bridge device 02:02.0 - 10b5:8518 - Bridge device 08:00.0 - 1957:0040 - Processor 07:00.0 - 10b5:8518 - Bridge device 09:00.0 - 10b5:8112 - Bridge device 07:01.0 - 10b5:8518 - Bridge device 07:02.0 - 10b5:8518 - Bridge device 06:00.0 - 10b5:8518 - Bridge device 02:03.0 - 10b5:8518 - Bridge device 01:00.0 - 10b5:8518 - Bridge device PCIE1: Bus 00 - 0b Updated example: 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 Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
* pci: Clean up PCI info when CONFIG_PCI_SCAN_SHOWPeter Tyser2010-11-14-28/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change does the following: - Removes the printing of the PCI interrupt line value. This is normally set to 0 by U-Boot on bootup and is rarely used during everyday operation. - Prints out the PCI function number of a device. Previously a device with multiple functions would be printed identically 2 times, which is generally confusing. For example, on an Intel 2 port gigabit Ethernet card the following was displayed: ... 04 01 8086 1010 0200 00 04 01 8086 1010 0200 00 ... - Prints a text description of each device's PCI class instead of the raw PCI class code. The textual description makes it much easier to determine what devices are installed on a PCI bus. - Changes the general formatting of the PCI device output. Previous output: PCIE1: connected as Root Complex 04 01 8086 1010 0200 00 04 01 8086 1010 0200 00 03 00 10b5 8112 0604 00 02 01 10b5 8518 0604 00 02 02 10b5 8518 0604 00 08 00 1957 0040 0b20 00 07 00 10b5 8518 0604 00 09 00 10b5 8112 0604 00 07 01 10b5 8518 0604 00 07 02 10b5 8518 0604 00 06 00 10b5 8518 0604 00 02 03 10b5 8518 0604 00 01 00 10b5 8518 0604 00 PCIE1: Bus 00 - 0b PCIE2: connected as Root Complex 0d 00 1957 0040 0b20 00 PCIE2: Bus 0c - 0d Updated output: PCIE1: connected as Root Complex 04:01.0 - 8086:1010 - Network controller 04:01.1 - 8086:1010 - Network controller 03:00.0 - 10b5:8112 - Bridge device 02:01.0 - 10b5:8518 - Bridge device 02:02.0 - 10b5:8518 - Bridge device 08:00.0 - 1957:0040 - Processor 07:00.0 - 10b5:8518 - Bridge device 09:00.0 - 10b5:8112 - Bridge device 07:01.0 - 10b5:8518 - Bridge device 07:02.0 - 10b5:8518 - Bridge device 06:00.0 - 10b5:8518 - Bridge device 02:03.0 - 10b5:8518 - Bridge device 01:00.0 - 10b5:8518 - Bridge device PCIE1: Bus 00 - 0b PCIE2: connected as Root Complex 0d:00.0 - 1957:0040 - Processor PCIE2: Bus 0c - 0d Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
* fsl_pci_init: Quiet scanning printf()Peter Tyser2010-11-14-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "Scanning PCI bus X" message doesn't provide any real useful information, so remove it. Original output: PCIE1: connected as Root Complex Scanning PCI bus 01 04 01 8086 1010 0200 00 04 01 8086 1010 0200 00 03 00 10b5 8112 0604 00 02 01 10b5 8518 0604 00 02 02 10b5 8518 0604 00 08 00 1957 0040 0b20 00 07 00 10b5 8518 0604 00 09 00 10b5 8112 0604 00 07 01 10b5 8518 0604 00 07 02 10b5 8518 0604 00 06 00 10b5 8518 0604 00 02 03 10b5 8518 0604 00 01 00 10b5 8518 0604 00 PCIE1: Bus 00 - 0b PCIE2: connected as Root Complex Scanning PCI bus 0d 0d 00 1957 0040 0b20 00 PCIE2: Bus 0c - 0d Updated output: PCIE1: connected as Root Complex 04 01 8086 1010 0200 00 04 01 8086 1010 0200 00 03 00 10b5 8112 0604 00 02 01 10b5 8518 0604 00 02 02 10b5 8518 0604 00 08 00 1957 0040 0b20 00 07 00 10b5 8518 0604 00 09 00 10b5 8112 0604 00 07 01 10b5 8518 0604 00 07 02 10b5 8518 0604 00 06 00 10b5 8518 0604 00 02 03 10b5 8518 0604 00 01 00 10b5 8518 0604 00 PCIE1: Bus 00 - 0b PCIE2: connected as Root Complex 0d 00 1957 0040 0b20 00 PCIE2: Bus 0c - 0d Signed-off-by: Peter Tyser <ptyser@xes-inc.com> CC: galak@kernel.crashing.org
generated by cgit v1.1 at 2024-11-06 20:19:17 +0000