| Age | Commit message (Collapse) | Author |
|---|
|
Make sure PCIe MPS settings are valid when we enumerate a new hierarchy.
[bhelgaas: changelog]
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
|
|
PAXC and PAXCv2 buses do not support legacy IRQs so there is no reason to
even try and map them. Without a change like this, one cannot create VFs
on Nitro ports since legacy interrupts are checked as part of the PCI
device creation process. Testing on PAXC hardware showed that VFs are
properly created with only the change to not set pcie->map_irq, but just to
be safe the change in iproc_pcie_setup() will ensure that pdev_fixup_irq()
will not panic.
Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ray Jui <ray.jui@broadcom.com>
|
|
In the code to handle PAXB v2 based MSI steering, the logic aligns the MSI
register address to the size of supported inbound mapping range. This is
incorrect since it rounds "up" the starting address to the next aligned
address, but what we want is the starting address to be rounded "down" to
the aligned address.
This patch fixes the issue and allows MSI writes to be properly steered to
the GIC.
Fixes: 4b073155fbd3 ("PCI: iproc: Add support for the next-gen PAXB controller")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Add support for the next generation of the iProc PAXB host controller, used
in Stingray.
Signed-off-by: Oza Oza <oza.oza@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
Add support for inbound DMA mapping. The range of the inbound mapping is
configured by the optional device tree property 'dma-ranges'.
While inbound mapping is done automatically in the ASIC on most iProc-based
SoCs, newer ASICs (e.g., Stingray) require inbound mapping to be configured
explicitly in software.
[bhelgaas: fold in fixes to avoid 32-bit division in iproc_pcie_ib_write()
and uninitialized return value in iproc_pcie_setup_ib() from Arnd Bergmann
<arnd@arndb.de>]
Signed-off-by: Oza Oza <oza.oza@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
Improve the iProc PCIe outbound mapping code by making it more generic and
removing redundant device tree properties 'brcm,pcie-ob-window-size' and
'brcm,pcie-ob-oarr-size'. The driver is still backward compatible to
device tree binaries with the two properties specified.
The driver now automatically configures the correct mapping window size and
number of mapping windows based on the value of device tree property
'ranges' and the capability of of the iProc PCIe controller.
Signed-off-by: Oza Oza <oza.oza@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
Add support for the second generation of the iProc PCIe PAXC host
controller.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
During enumeration with multi-function EP devices, access to the
configuration space of a non-existent function results in an unsupported
request being returned as expected. By default the PAXB-based iProc PCIe
controller forwards this as an APB error to the host system and that causes
an exception, which is undesired.
Disable this undesired behaviour and let the kernel PCI stack deal with an
access to the non-existent function, in which case a vendor ID of 0xffff is
returned and handled gracefully.
Reported-by: JD Zheng <jiandong.zheng@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: JD Zheng <jiandong.zheng@broadcom.com>
Reviewed-by: Oza Oza <oza.oza@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
The iProc PCIe driver is currently using type IPROC_PCIE_PAXB for the
following SoCs: NS, NSP, Cygnus, NS2, and Pegasus. In fact, the BCMA-based
NS uses a legacy PAXB controller that is slightly different from the PAXB
controller used in the rest of SoCs, e.g., some registers are missing and
it does not require software configuration of outbound/inbound address
mapping.
Add a new type, IPROC_PCIE_PAXB_BCMA, to allow us to properly support the
BCMA-based NS along with other iProc-based SoCs going forward.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
During initialization, the current iProc PCIe host driver resets PAXC and
the downstream internal endpoint device that PAXC connects to. If the
endpoint device is already loaded with firmware and has started running
from the bootloader stage, this downstream reset causes the endpoint device
to stop working.
Signed-off-by: Ray Jui <raj.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
As the number of iProc PCIe core registers starts to grow and differ
between different revisions of the iProc PCIe controllers, the
current way of populating each individual unsupported register with
value 'IPROC_PCIE_REG_INVALID' with a table entry has become a bit
messy and is difficult to scale up in the future.
Improve the current driver by populating the invalid entries with code
instead of through individual table entries. This helps to avoid a
significant number of invalid table entries when support for the next
revision of the iProc controller is added.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
