Add Makefile comments to explain the Kconfig and build strategy for ARM64
drivers that work around not-quite-ECAM issues. No functional change
intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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: Jon Masters <jcm@redhat.com>
Signed-off-by: Duc Dang <dhdang@apm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
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: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Pull the register resource lookup out of thunder_pem_init() so we can
easily add a corresponding lookup using ACPI. No functional change
intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The PCIe controller in Hip05/Hip06/Hip07 SoCs is not completely
ECAM-compliant. It is non-ECAM only for the RC bus config space; for any
other bus underneath the root bus it does support ECAM access.
Add specific quirks for PCI config space accessors. This involves:
1. New initialization call hisi_pcie_init() to obtain RC base
addresses from PNP0C02 at the root of the ACPI namespace (under \_SB).
2. New entry in common quirk array.
[bhelgaas: move to pcie-hisi.c and change Makefile/ifdefs so quirk doesn't
depend on CONFIG_PCI_HISI]
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The Qualcomm Technologies QDF2432 SoC does not support accesses smaller
than 32 bits to the PCI configuration space. Register the appropriate
quirk.
[bhelgaas: add QCOM_ECAM32 macro, ifdef for ACPI and PCI_QUIRKS]
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The acpi_get_rc_resources() is used to get the RC register address that can
not be described in MCFG. It takes the _HID & segment to look for and
outputs the RC address resource. Use PNP0C02 devices to describe such RC
address resource. Use _UID to match segment to tell which root bus the
PNP0C02 resource belongs to.
[bhelgaas: add dev argument, wrap in #ifdef CONFIG_PCI_QUIRKS]
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Body of an "if" statement wasn't indented. Add a tab.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Only interfaces used from outside the driver, e.g., those called by the
DesignWare core, need to accept pointers to the generic struct pcie_port.
Internal interfaces can accept pointers to the device-specific struct,
which makes them more straightforward. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Include the PCIE_HIP06_CTRL_OFF block base in the PCIE_SYS_STATE4 register
address so reads of PCIE_SYS_STATE4 don't have to mention both. No
functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The xilinx-nwl driver never uses the platform drvdata pointer, so don't
bother setting it. 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>
xilinx_pcie_assign_msi() doesn't use the struct xilinx_pcie_port pointer
passed to it, so remove the argument completely. No functional change
intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The xilinx driver never uses the platform drvdata pointer, so don't
bother setting it. 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>
Pass the struct xgene_pcie_port pointer, not addresses, to setup functions.
This enables future simplifications. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The xgene driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The tegra driver never uses the platform drvdata pointer, so don't
bother setting it. 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>
The tegra_pcie_phy_disable() path called pads_writel() with arguments in
the wrong order. Swap them to be the "value, offset" order expected by
pads_writel().
Fixes: 6fe7c187e0 ("PCI: tegra: Support per-lane PHYs")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thierry Reding <treding@nvidia.com>
CC: stable@vger.kernel.org # v4.7+
The rockchip driver never uses the platform drvdata pointer, so don't
bother setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.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>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
The DRV_NAME macro is only used once, so there's no real advantage to
having the macro at all. Remove it and use the "rcar-pcie" name directly
in the struct platform_driver. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
rcar_pcie_get_resources() doesn't use the platform_device pointer passed to
it, so remove it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
The rcar driver never uses the platform drvdata pointer, so don't bother
setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Remove the struct qcom_pcie.dev member, which is a duplicate of the generic
pp.dev member. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Remove the struct qcom_pcie.dbi member, which is a duplicate of the generic
pp.dbi_base member. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The qcom driver never uses the platform drvdata pointer, so don't bother
setting it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Use the existing "np" pointer instead of looking up dev->of_node again. 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>
ls_add_pcie_port() doesn't use the platform_device pointer passed to it, so
remove it. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Do the basic pcie_port setup in the probe function for consistency with
other drivers. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Only interfaces used from outside the driver, e.g., those called by the
DesignWare core, need to accept pointers to the generic struct pcie_port.
Internal interfaces can accept pointers to the device-specific struct,
which makes them more straightforward. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Remove the struct ls_pcie.dbi member, which is a duplicate of the generic
pp.dbi_base member. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The layerscape driver never uses the platform drvdata pointer, so don't
bother setting it. 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>
Instead of passing ks_pcie->va_app_base to DBI mode functions,
pass the struct keystone_pcie. This will allow them to use register
accessors. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Instead of passing the application register base to IRQ functions,
pass the struct keystone_pcie. This will allow them to use register
accessors. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>