summaryrefslogtreecommitdiff
path: root/drivers/acpi/pci_mcfg.c
AgeCommit message (Collapse)Author
2017-04-24PCI/ACPI: Add ThunderX pass2.x 2nd node MCFG quirkTomasz Nowicki
Currently SoCs pass2.x do not emulate EA headers for ACPI boot method at all. However, for pass2.x some devices (like EDAC) advertise incorrect base addresses in their BARs which results in driver probe failure during resource request. Since all problematic blocks are on 2nd NUMA node under domain 10 add necessary quirk entry to obtain BAR addresses correction using EA header emulation. Fixes: 44f22bd91e88 ("PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller") Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Robert Richter <rrichter@cavium.com> CC: stable@vger.kernel.org # v4.10+
2017-04-21PCI/ACPI: Tidy up MCFG quirk whitespaceBjorn Helgaas
With no blank lines, it's not obvious where the macro definitions end and the uses begin. Add some blank lines and reorder the ThunderX definitions. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.10+
2017-01-12PCI/ACPI: Fix bus range comparison in pci_mcfg_lookup()Zhou Wang
The configuration data provided by an MCFG entry, i.e., PCI segment and bus range, may span multiple host bridges. pci_mcfg_lookup() previously required an exact match of the host bridge starting bus and the MCFG starting bus, which made the following configuration fail: MCFG region: segment: 0 bus range: 0x00-0xff host bridge segment: 0 bus range: 0x20-0x4f Relax the bus range check in pci_mcfg_lookup() so we can use any MCFG entry that contains the required bus range, as we do in pci_mmconfig_lookup(). [bhelgaas: changelog] Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tomasz Nowicki <tn@semihalf.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2016-12-06PCI: Add MCFG quirks for X-Gene host controllerDuc 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: Jon Masters <jcm@redhat.com> Signed-off-by: Duc Dang <dhdang@apm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: Add MCFG quirks for Cavium ThunderX pass1.x host controllerTomasz 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: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controllerTomasz 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: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: Add MCFG quirks for HiSilicon Hip05/06/07 host controllersDongdong Liu
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>
2016-12-06PCI: Add MCFG quirks for Qualcomm QDF2432 host controllerChristopher Covington
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>
2016-12-06PCI/ACPI: Check for platform-specific MCFG quirksTomasz Nowicki
The PCIe spec (r3.0, sec 7.2.2) specifies an "Enhanced Configuration Access Mechanism" (ECAM) for memory-mapped access to configuration space. ECAM is required for PCIe systems unless there's a standard firmware interface for config access. In the absence of a firmware interface, we use pci_generic_ecam_ops, and on ACPI systems, we discover the ECAM space via the MCFG table and/or the _CBA method. Unfortunately some systems provide MCFG but don't implement ECAM according to spec, so we need a mechanism for quirks to make those systems work. Add an MCFG quirk mechanism to override the config accessor functions and/or the memory-mapped address space. A quirk is selected if it matches all of the following: - OEM ID - OEM Table ID - OEM Revision - PCI segment (from _SEG) - PCI bus number range (from _CRS, wildcard allowed) If the quirk specifies config accessor functions or a memory-mapped address range, these override the defaults. [bhelgaas: changelog, reorder quirk matching, fix oem_revision typo per Duc, add under #ifdef CONFIG_PCI_QUIRKS] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI/ACPI: Extend pci_mcfg_lookup() to return ECAM config accessorsTomasz Nowicki
pci_mcfg_lookup() is the external interface to the generic MCFG code. Previously it merely looked up the ECAM base address for a given domain and bus range. We want a way to add MCFG quirks, some of which may require special config accessors and adjustments to the ECAM address range. Extend pci_mcfg_lookup() so it can return a pointer to a pci_ecam_ops structure and a struct resource for the ECAM address space. For now, it always returns &pci_generic_ecam_ops (the standard accessor) and the resource described by the MCFG. No functional changes intended. [bhelgaas: changelog] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-06-10PCI/ACPI: Add generic MCFG table handlingTomasz Nowicki
On ACPI systems that support memory-mapped config space access, i.e., ECAM, the PCI Firmware Specification says the OS can learn where the ECAM space is from either: - the static MCFG table (for non-hotpluggable bridges), or - the _CBA method (for hotpluggable bridges) The current MCFG table handling code cannot be easily generalized owing to x86-specific quirks, which makes it hard to reuse on other architectures. Implement generic MCFG handling from scratch, including: - Simple MCFG table parsing (via pci_mmcfg_late_init() as in current x86) - MCFG region lookup for a (domain, bus_start, bus_end) tuple [bhelgaas: changelog] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Jayachandran C <jchandra@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>