summaryrefslogtreecommitdiffstats
path: root/drivers/pci/host/pcie-iproc.c
Commit message (Collapse)AuthorAgeFilesLines
* PCI: iproc: Hard-code PCIe capability offset instead of searchingBjorn Helgaas2016-10-111-6/+5
| | | | | | | | | | | | | | | | We know where the PCIe capability lives in the host bridge's config space; in fact, we already hard-coded the offset of the Link Control 2 register. The hard-coded Link Control 2 offset was 0xdc. Link Control 2 is at offset 0x30 into the PCIe capability, so the capability itself must be at 0xdc - 0x30 = 0xac. Hard-code the PCIe capability offset, which means we don't have to search for it and we can use the standard definitions for registers within the capability. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Remove redundant null pointer checkingBjorn Helgaas2016-10-111-3/+0
| | | | | | | | The callers never pass a null "pcie" pointer (they check for kzalloc failure), so we don't need to check here. The bus driver should never call the probe function with a null ->dev pointer, so we don't need to check that either. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Validate CSR base in BCMA setup codeBjorn Helgaas2016-10-111-1/+1
| | | | | | | Validate iproc_pcie->base for BCMA devices just like we already do for platform devices in iproc_pcie_pltfm_probe(). No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Add local struct device pointersBjorn Helgaas2016-10-111-17/+21
| | | | | | Use a local "struct device *dev" for brevity and consistency with other drivers. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Request host bridge window resourcesBjorn Helgaas2016-06-201-0/+4
| | | | | | Request host bridge window resources so they appear in ioport_resource and iomem_resource and are reflected in /proc/ioports and /proc/iomem. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Allow multiple devices except on PAXCRay Jui2016-01-271-18/+11
| | | | | | | | | | | | | | | Commit 943ebae781f5 ("PCI: iproc: Add PAXC interface support") only allowed device 0, which is a regression on BCMA-based platforms. All systems support only one device, a Root Port at 00:00.0, on the root bus. PAXC-based systems support only the Root Port (00:00.0) and a single device (with multiple functions) below it, e.g., 01:00.0, 01:00.1, etc. Non-PAXC systems support arbitrary devices below the Root Port. [bhelgaas: changelog, fold in removal of MAX_NUM_PAXC_PF check] Fixes: 943ebae781f5 ("PCI: iproc: Add PAXC interface support") Reported-by: Rafal Milecki <zajec5@gmail.com> Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Add iProc PCIe MSI supportRay Jui2016-01-061-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Anup Patel <anup.patel@broadcom.com> Reviewed-by: Vikram Prakash <vikramp@broadcom.com> Reviewed-by: Scott Branden <sbranden@broadcom.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
* PCI: iproc: Add PAXC interface supportRay Jui2015-12-071-34/+168
| | | | | | | | | | | | | | | | Traditionally, all iProc PCIe root complexes use PAXB-based wrapper, with an integrated on-chip Serdes to support external endpoint devices. On newer iProc platforms, a PAXC-based wrapper is introduced, for connection with internally emulated PCIe endpoint devices in the ASIC. Add support for PAXC-based iProc PCIe root complex in the iProc PCIe core driver. This change factors out common logic between PAXB and PAXC, and uses tables to store register offsets that are different between PAXB and PAXC. This allows the driver to be scaled to support subsequent PAXC revisions in the future. Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Scott Branden <sbranden@broadcom.com>
* PCI: iproc: Do not use 0x in front of %papDmitry V. Krivenok2015-11-301-1/+1
| | | | | | | | | The "%pap" format adds a "0x" prefix, so using "0x%pap" results in output of "0x0x...". Drop the "0x" prefix in the format string. [bhelgaas: changelog] Signed-off-by: Dmitry V. Krivenok <krivenok.dmitry@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Ray Jui <rjui@broadcom.com>
* PCI: iproc: Fix header comment "Corporation" misspellingFlorian Fainelli2015-10-221-1/+1
| | | | | | | Fix an obvious "Broadcom Corporation" typo in a header comment. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Ray Jui <rjui@broadcom.com>
* PCI: iproc: Add outbound mapping supportRay Jui2015-10-161-0/+115
| | | | | | | | | | | | | Certain SoCs require the PCIe outbound mapping to be configured in software. Add support for those chips. [jonmason: Use %pap format when printing size_t to avoid warnings in 32-bit build.] [arnd: Use div64_u64() instead of "%" to avoid __aeabi_uldivmod link error in 32-bit build.] Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Jon Mason <jonmason@broadcom.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Improve link detection logicRay Jui2015-09-251-6/+23
| | | | | | | | | | | | Improve the link detection logic by explicitly querying the link status register to ensure link is active. Also force class to PCI_CLASS_BRIDGE_PCI (0x0604) through the host configuration space register. Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Anup Patel <anup.patel@broadcom.com> Reviewed-by: Scott Branden <sbranden@broadcom.com>
* PCI: iproc: Fix PCIe reset logicRay Jui2015-09-251-5/+10
| | | | | | | | | | | | | | | | | | | | The current reset logic does not always properly reset the device. For example, in the case when the perst_b signal is already de-asserted in the bootloader, the current reset logic fails to trigger a proper assert -> de-assert reset sequence. Fix the issue by always triggering the proper reset sequence. Also explicitly select the desired reset source, i.e., perst_b, and reduce the wait time after the device comes out of reset from 250 ms to 100 ms, based on recommendation from the ASIC team. Tested-by: Vladimir Dreizin <vdreizin@broadcom.com> Tested-by: Darren Edamura <dedamura@broadcom.com> Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vladimir Dreizin <vdreizin@broadcom.com> Reviewed-by: Trac Hoang <trhoang@broadcom.com> Reviewed-by: Scott Branden <sbranden@broadcom.com>
* PCI: iproc: Call pci_fixup_irqs() for ARM64 as well as ARMRay Jui2015-09-251-2/+0
| | | | | | | | | | | After 459a07721c11 ("PCI: Build setup-irq.o for arm64"), we build setup-irq.o for arm64, so we can use pci_fixup_irqs() on both arm and arm64. Remove the "#ifdef CONFIG_ARM" around the call to pci_fixup_irqs(). [bhelgaas: changelog] Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* PCI: iproc: Add arm64 supportRay Jui2015-07-221-6/+20
| | | | | | | | | | | | | | | Add arm64 support to the iProc PCIe driver. Note that on arm32, bus->sysdata points to the arm32-specific pci_sys_data struct, and pci_sys_data.private_data contains the iproc_pcie pointer. For arm64, there's nothing corresponding to pci_sys_data, so we keep the iproc_pcie pointer directly in bus->sysdata. In addition, arm64 does IRQ mapping in pcibios_add_device(), so it doesn't need pci_fixup_irqs() as arm32 does. Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Scott Branden <sbranden@broadcom.com>
* PCI: iproc: Delete unnecessary checks before phy callsMarkus Elfring2015-07-141-21/+13
| | | | | | | | | | | | | The functions phy_exit() and phy_power_off() test whether their argument is NULL and then return immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. [bhelgaas: also phy_init() and phy_power_on(), as Ray Jui suggested] [bhelgaas: also remove tests in iproc_pcie_remove()] Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ray Jui <rjui@broadcom.com>
* PCI: iproc: Directly add PCI resourcesHauke Mehrtens2015-05-271-2/+2
| | | | | | | | | | | The struct iproc_pcie.resources member was pointing to a stack variable and is invalid after the registration function returned. Remove this pointer and add a parameter to the function. Tested-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ray Jui <rjui@broadcom.com>
* PCI: iproc: Allow override of device tree IRQ mapping functionHauke Mehrtens2015-05-201-1/+1
| | | | | | | | | | | The iProc core PCIe driver defaults to using of_irq_parse_and_map_pci() for IRQ mapping. Add iproc_pcie.map_irq so bus interfaces that don't use device tree can override this by supplying their own IRQ mapping function. [bhelgaas: changelog] Posting: http://lkml.kernel.org/r/1431465781-10753-1-git-send-email-hauke@hauke-m.de Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ray Jui <rjui@broadcom.com.com>
* PCI: iproc: Add Broadcom iProc PCIe supportRay Jui2015-04-081-0/+268
Add support for the Broadcom iProc PCIe controller. pcie-iproc.c is the common core driver, and a front-end bus interface needs to be added to support different bus interfaces. pcie-iproc-platform.c contains the support for the platform bus interface. Signed-off-by: Ray Jui <rjui@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Scott Branden <sbranden@broadcom.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-23 06:09:05 +0000