1. 22 2月, 2017 1 次提交
    • K
      PCI: Move DesignWare IP support to new drivers/pci/dwc/ directory · 950bf638
      Kishon Vijay Abraham I 提交于
      Group all the PCI drivers that use DesignWare core in dwc directory.
      dwc IP is capable of operating in both host mode and device mode and
      keeping it inside the *host* directory is misleading.
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJingoo Han <jingoohan1@gmail.com>
      Acked-By: NJoao Pinto <jpinto@synopsys.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Minghuan Lian <minghuan.Lian@freescale.com>
      Cc: Mingkai Hu <mingkai.hu@freescale.com>
      Cc: Roy Zang <tie-fei.zang@freescale.com>
      Cc: Richard Zhu <hongxing.zhu@nxp.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Murali Karicheri <m-karicheri2@ti.com>
      Cc: Pratyush Anand <pratyush.anand@gmail.com>
      Cc: Niklas Cassel <niklas.cassel@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Zhou Wang <wangzhou1@hisilicon.com>
      Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>
      Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
      950bf638
  2. 08 12月, 2016 3 次提交
  3. 07 12月, 2016 3 次提交
    • D
      PCI: Add MCFG quirks for X-Gene host controller · c5d46039
      Duc Dang 提交于
      PCIe controllers in X-Gene SoCs are not ECAM compliant: software needs to
      configure additional controller's register to address device at
      bus:dev:function.
      
      Add a quirk to discover controller MMIO register space and configure
      controller registers to select and address the target secondary device.
      
      The quirk will only be applied for X-Gene PCIe MCFG table with
      OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
      Tested-by: NJon Masters <jcm@redhat.com>
      Signed-off-by: NDuc Dang <dhdang@apm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c5d46039
    • T
      PCI: Add MCFG quirks for Cavium ThunderX pass1.x host controller · 648d93fc
      Tomasz Nowicki 提交于
      ThunderX pass1.x requires to emulate the EA headers for on-chip devices
      hence it has to use custom pci_thunder_ecam_ops for accessing PCI config
      space (pci-thunder-ecam.c). Add new entries to MCFG quirk array where it
      can be applied while probing ACPI based PCI host controller.
      
      ThunderX pass1.x is using the same way for accessing off-chip devices
      (so-called PEM) as silicon pass-2.x so we need to add PEM quirk entries
      too.
      
      Quirk is considered for ThunderX silicon pass1.x only which is identified
      via MCFG revision 2.
      
      ThunderX pass 1.x requires the following accessors:
      
        NUMA node 0 PCI segments  0- 3: pci_thunder_ecam_ops (MCFG quirk)
        NUMA node 0 PCI segments  4- 9: thunder_pem_ecam_ops (MCFG quirk)
        NUMA node 1 PCI segments 10-13: pci_thunder_ecam_ops (MCFG quirk)
        NUMA node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk)
      
      [bhelgaas: change Makefile/ifdefs so quirk doesn't depend on
      CONFIG_PCI_HOST_THUNDER_ECAM]
      Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      648d93fc
    • T
      PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller · 44f22bd9
      Tomasz Nowicki 提交于
      ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
      compliant with ECAM standard. It uses non-standard configuration space
      accessors (see thunder_pem_ecam_ops) and custom configuration space
      granulation (see bus_shift = 24). In order to access configuration space
      and probe PEM as ACPI-based PCI host controller we need to add MCFG quirk
      infrastructure. This involves:
      1. A new thunder_pem_acpi_init() init function to locate PEM-specific
         register ranges using ACPI.
      2. Export PEM thunder_pem_ecam_ops structure so it is visible to MCFG quirk
         code.
      3. New quirk entries for each PEM segment. Each contains platform IDs,
         mentioned thunder_pem_ecam_ops and CFG resources.
      
      Quirk is considered for ThunderX silicon pass2.x only which is identified
      via MCFG revision 1.
      
      ThunderX pass 2.x requires the following accessors:
      
        NUMA Node 0 PCI segments  0- 3: pci_generic_ecam_ops (ECAM-compliant)
        NUMA Node 0 PCI segments  4- 9: thunder_pem_ecam_ops (MCFG quirk)
        NUMA Node 1 PCI segments 10-13: pci_generic_ecam_ops (ECAM-compliant)
        NUMA Node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk)
      
      [bhelgaas: adapt to use acpi_get_rc_resources(), update Makefile/ifdefs so
      quirk doesn't depend on CONFIG_PCI_HOST_THUNDER_PEM]
      Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      44f22bd9
  4. 05 10月, 2016 1 次提交
  5. 04 9月, 2016 1 次提交
  6. 30 7月, 2016 1 次提交
  7. 27 7月, 2016 1 次提交
  8. 16 6月, 2016 1 次提交
    • A
      PCI/MSI: irqchip: Fix PCI_MSI dependencies · 3ee80364
      Arnd Bergmann 提交于
      The PCI_MSI symbol is used inconsistently throughout the tree, with some
      drivers using 'select' and others using 'depends on', or using conditional
      selects.  This keeps causing problems; the latest one is a result of
      ARCH_ALPINE using a 'select' statement to enable its platform-specific MSI
      driver without enabling MSI:
      
        warning: (ARCH_ALPINE) selects ALPINE_MSI which has unmet direct dependencies (PCI && PCI_MSI)
        drivers/irqchip/irq-alpine-msi.c:104:15: error: variable 'alpine_msix_domain_info' has initializer but incomplete type
         static struct msi_domain_info alpine_msix_domain_info = {
      		 ^~~~~~~~~~~~~~~
        drivers/irqchip/irq-alpine-msi.c:105:2: error: unknown field 'flags' specified in initializer
          .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
          ^
        drivers/irqchip/irq-alpine-msi.c:105:11: error: 'MSI_FLAG_USE_DEF_DOM_OPS' undeclared here (not in a function)
          .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
      	     ^~~~~~~~~~~~~~~~~~~~~~~~
      
      There is little reason to enable PCI support for a platform that uses MSI
      but then leave MSI disabled at compile time.
      
      Select PCI_MSI from irqchips that implement MSI, and make PCI host bridges
      that use MSI on ARM depend on PCI_MSI_IRQ_DOMAIN.
      
      For all three architectures that support PCI_MSI_IRQ_DOMAIN (ARM, ARM64,
      X86), enable it by default whenever MSI is enabled.
      
      [bhelgaas: changelog, omit crypto config change]
      Suggested-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      3ee80364
  9. 12 6月, 2016 1 次提交
  10. 11 6月, 2016 1 次提交
    • A
      PCI: generic: Select IRQ_DOMAIN · d7d5677c
      Arnd Bergmann 提交于
      The generic PCI host controller calls of_irq_parse_and_map_pci() in its IRQ
      fixup, but that function is only available when CONFIG_IRQ_DOMAIN is set:
      
        drivers/pci/built-in.o: In function `pci_host_common_probe':
        drivers/pci/host/pci-host-common.c:181: undefined reference to `of_irq_parse_and_map_pci'
      
      There is no downside in enabling the domains here, so use a Kconfig
      select statement to ensure it's always available to this driver.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d7d5677c
  11. 12 5月, 2016 1 次提交
    • J
      PCI: generic, thunder: Use generic ECAM API · 1958e717
      Jayachandran C 提交于
      Use functions provided by drivers/pci/ecam.h for mapping the config space
      in drivers/pci/host/pci-host-common.c, and update its users to use 'struct
      pci_config_window' and 'struct pci_ecam_ops'.
      
      The changes are mostly to use 'struct pci_config_window' in place of
      'struct gen_pci'.  Some of the fields of gen_pci were only used temporarily
      and can be eliminated by using local variables or function arguments, these
      are not carried over to struct pci_config_window.
      
      pci-thunder-ecam.c and pci-thunder-pem.c are the only users of the
      pci_host_common_probe function and the gen_pci structure; these have been
      updated to use the new API as well.
      
      The patch does not introduce any functional changes other than a very minor
      one: with the new code, on 64-bit platforms, we do just a single ioremap
      for the whole config space.
      Signed-off-by: NJayachandran C <jchandra@broadcom.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      1958e717
  12. 03 5月, 2016 1 次提交
    • A
      PCI: rcar: Select PCI_MSI_IRQ_DOMAIN · 76ba8c1f
      Arnd Bergmann 提交于
      The R-Car PCIe driver requires the use of IRQ domains for its MSI code:
      
        drivers/pci/host/pcie-rcar.c:635:9: error: implicit declaration of function 'irq_find_mapping' [-Werror=implicit-function-declaration]
        drivers/pci/host/pcie-rcar.c:666:8: error: implicit declaration of function 'irq_create_mapping' [-Werror=implicit-function-declaration]
        ...
      
      Add a Kconfig select to ensure that the feature is always enabled.
      
      This is not consistent with what the other drivers do at the moment, but I
      have another patch that changes them to do it like this one, which is more
      logical.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NSimon Horman <horms+renesas@verge.net.au>
      76ba8c1f
  13. 27 4月, 2016 1 次提交
  14. 22 4月, 2016 1 次提交
  15. 22 3月, 2016 1 次提交
  16. 15 3月, 2016 1 次提交
  17. 12 3月, 2016 5 次提交
  18. 09 3月, 2016 1 次提交
  19. 27 2月, 2016 1 次提交
  20. 09 1月, 2016 1 次提交
  21. 08 1月, 2016 1 次提交
  22. 07 1月, 2016 1 次提交
    • R
      PCI: iproc: Add iProc PCIe MSI support · 3bc2b234
      Ray Jui 提交于
      Add PCIe MSI support for both PAXB and PAXC interfaces on all iProc-based
      platforms.
      
      The iProc PCIe MSI support deploys an event queue-based implementation.
      Each event queue is serviced by a GIC interrupt and can support up to 64
      MSI vectors.  Host memory is allocated for the event queues, and each event
      queue consists of 64 word-sized entries.  MSI data is written to the lower
      16-bit of each entry, whereas the upper 16-bit of the entry is reserved for
      the controller for internal processing.
      
      Each event queue is tracked by a head pointer and tail pointer.  Head
      pointer indicates the next entry in the event queue to be processed by
      the driver and is updated by the driver after processing is done.
      The controller uses the tail pointer as the next MSI data insertion
      point.  The controller ensures MSI data is flushed to host memory before
      updating the tail pointer and then triggering the interrupt.
      
      MSI IRQ affinity is supported by evenly distributing the interrupts to each
      CPU core.  MSI vector is moved from one GIC interrupt to another in order
      to steer to the target CPU.
      
      Therefore, the actual number of supported MSI vectors is:
      
        M * 64 / N
      
      where M denotes the number of GIC interrupts (event queues), and N denotes
      the number of CPU cores.
      
      This iProc event queue-based MSI support should not be used with newer
      platforms with integrated MSI support in the GIC (e.g., giv2m or
      gicv3-its).
      
      [bhelgaas: fold in Kconfig fixes from Arnd Bergmann <arnd@arndb.de>]
      Signed-off-by: NRay Jui <rjui@broadcom.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NAnup Patel <anup.patel@broadcom.com>
      Reviewed-by: NVikram Prakash <vikramp@broadcom.com>
      Reviewed-by: NScott Branden <sbranden@broadcom.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      3bc2b234
  23. 06 1月, 2016 1 次提交
  24. 09 12月, 2015 1 次提交
  25. 25 11月, 2015 1 次提交
    • A
      PCI: iproc: Hide CONFIG_PCIE_IPROC · c1b98e41
      Arnd Bergmann 提交于
      PCIE_IPROC_BCMA does not require CONFIG_OF in Kconfig, but
      CONFIG_PCIE_IPROC does, so we can get a warning when building for an ARM
      platform without DT support:
      
        warning: (PCIE_IPROC_PLATFORM && PCIE_IPROC_BCMA) selects PCIE_IPROC which has unmet direct dependencies (PCI && OF && (ARM || ARM64))
      
      It turns out that CONFIG_PCIE_IPROC never needs to be enabled by a user
      anyway, we can simply rely on it being selected implictly through either
      PCIE_IPROC_PLATFORM or PCIE_IPROC_BCMA.
      
      Fixes: 4785ffbd ("PCI: iproc: Add BCMA PCIe driver")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
      c1b98e41
  26. 03 11月, 2015 3 次提交
  27. 30 10月, 2015 2 次提交
    • G
      PCI: rcar: Build pcie-rcar.c only on ARM · 7c537c67
      Geert Uytterhoeven 提交于
      The pcie-rcar.c driver (controlled by PCI_RCAR_GEN2_PCIE) uses struct
      pci_sys_data and pci_ioremap_io(), which only exist on ARM.  Building it on
      other arches, e.g., arm64/shmobile, causes errors like this:
      
        drivers/pci/host/pcie-rcar.c:138:52: warning: 'struct pci_sys_data' declared inside parameter list
        drivers/pci/host/pcie-rcar.c:380:4: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
      
      Build pcie-rcar.c only on ARM.
      
      [bhelgaas: changelog, split to separate pci-rcar-gen2 from pcie-rcar]
      Reported-by: Wolfram Sang <wsa@the-dreams.de> (pci_ioremap_io())
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      7c537c67
    • G
      PCI: rcar: Build pci-rcar-gen2.c only on ARM · 6cbfeae7
      Geert Uytterhoeven 提交于
      The pci-rcar-gen2.c driver (controlled by PCI_RCAR_GEN2) uses struct
      pci_sys_data, which only exists on ARM.  Building it on other arches, e.g.,
      arm64/shmobile, causes errors like this:
      
        drivers/pci/host/pci-rcar-gen2.c: In function 'rcar_pci_cfg_base': drivers/pci/host/pci-rcar-gen2.c:112:34: error: dereferencing pointer to incomplete type
          struct rcar_pci_priv *priv = sys->private_data;
                                          ^
      
      Build pci-rcar-gen2.c only on ARM.
      
      [bhelgaas: changelog, split to separate pci-rcar-gen2 from pcie-rcar]
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      6cbfeae7
  28. 24 10月, 2015 1 次提交
  29. 21 8月, 2015 1 次提交