| Message ID | 1479201298-25494-2-git-send-email-tn@semihalf.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Tomasz, On Tue, Nov 15, 2016 at 10:14:57AM +0100, Tomasz Nowicki wrote: > 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 pci_thunder_pem_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. thunder_pem_init() ACPI extension so that we can probe PEM-specific > register ranges analogously to DT > 2. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk > code. > 3. New quirk entries for each PEM segment. Each contains platform IDs, > mentioned pci_thunder_pem_ops and CFG resources. > > Quirk is considered for ThunderX silicon pass2.x only which is identified > via MCFG revision 1. > > Signed-off-by: Tomasz Nowicki <tn@semihalf.com> > --- > drivers/acpi/pci_mcfg.c | 20 +++++++ > drivers/pci/host/pci-thunder-pem.c | 107 ++++++++++++++++++++++++++++++++----- > include/linux/pci-ecam.h | 4 ++ > 3 files changed, 117 insertions(+), 14 deletions(-) > > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c > index ac21db3..e4e2b9b 100644 > --- a/drivers/acpi/pci_mcfg.c > +++ b/drivers/acpi/pci_mcfg.c > @@ -57,6 +57,26 @@ static struct mcfg_fixup mcfg_quirks[] = { > { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops }, > { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops }, > { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops }, > +#ifdef CONFIG_PCI_HOST_THUNDER_PEM > +#define THUNDER_MCFG_RES(addr, node) \ > + DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M) > +#define THUNDER_MCFG_QUIRK(rev, node) \ > + { "CAVIUM", "THUNDERX", rev, 4 + (10 * node), MCFG_BUS_ANY, \ > + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88001f000000UL, node) }, \ > + { "CAVIUM", "THUNDERX", rev, 5 + (10 * node), MCFG_BUS_ANY, \ > + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x884057000000UL, node) }, \ > + { "CAVIUM", "THUNDERX", rev, 6 + (10 * node), MCFG_BUS_ANY, \ > + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88808f000000UL, node) }, \ > + { "CAVIUM", "THUNDERX", rev, 7 + (10 * node), MCFG_BUS_ANY, \ > + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89001f000000UL, node) }, \ > + { "CAVIUM", "THUNDERX", rev, 8 + (10 * node), MCFG_BUS_ANY, \ > + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x894057000000UL, node) }, \ > + { "CAVIUM", "THUNDERX", rev, 9 + (10 * node), MCFG_BUS_ANY, \ > + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89808f000000UL, node) } > + /* SoC pass2.x */ > + THUNDER_MCFG_QUIRK(1, 0UL), > + THUNDER_MCFG_QUIRK(1, 1UL), > +#endif I want all these quirks to work without having to enable device-specific config options like CONFIG_PCI_HOST_THUNDER_PEM. I tweaked the preceding MCFG quirk support to wrap it in CONFIG_PCI_QUIRKS. I also tweaked the qualcomm and hisi patches to move the meat of them to pci/quirks.c. My work-in-progress is on pci/ecam, but I can't easily build for arm64, so there are likely some issues to be resolved. I'm hoping to end up with something like this: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469 The problem with ThunderX is that the config accessors are much bigger and I don't really want to duplicate them in both pci/quirks.c and pci-thunder-pem.c. Actually, that raises a question for qualcomm and hisi: in the DT model, we use non-ECAM config accessors in the driver, but in the ACPI model, we use ECAM accessors. It seems like the accessors should be the same regardless of whether we discover the bridge via DT or ACPI. Anyway, it's almost like we want to build pci-thunder-pem.o if CONFIG_PCI_HOST_THUNDER_PEM || (CONFIG_PCI_QUIRKS && CONFIG_ARM64). I don't know how to express that nicely. I was trying to avoid adding an ecam-quirks.c, but maybe we need to add it and collect all the different accessors there and add #ifdefs inside. Sorry, this is only half-baked, but I just wanted to throw this out in case you have any ideas. > }; > > static char mcfg_oem_id[ACPI_OEM_ID_SIZE]; > diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c > index 6abaf80..7bdc4cd 100644 > --- a/drivers/pci/host/pci-thunder-pem.c > +++ b/drivers/pci/host/pci-thunder-pem.c > @@ -18,6 +18,7 @@ > #include <linux/init.h> > #include <linux/of_address.h> > #include <linux/of_pci.h> > +#include <linux/pci-acpi.h> > #include <linux/pci-ecam.h> > #include <linux/platform_device.h> > > @@ -284,6 +285,84 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn, > return pci_generic_config_write(bus, devfn, where, size, val); > } > > +#ifdef CONFIG_ACPI > + > +/* > + * Retrieve PEM bridge register base and size from PNP0C02 sub-device under > + * the RC. > + * > + * Device (RES0) > + * { > + * Name (_HID, "THRX0002") > + * Name (_CID, "PNP0C02") > + * Name (_CRS, ResourceTemplate () { > + * // Device specific registers range > + * QWordMemory(ResourceConsumer, PosDecode, MinFixed, > + * MaxFixed, Cacheable, ReadWrite, 0, > + * 0x87e0c2000000, 0x87E0C2FFFFFF, 0, 0x1000000) > + * }) > + * } > + */ > + > +static const struct acpi_device_id thunder_pem_reg_ids[] = { > + {"THRX0002", 0}, > + {"", 0}, > +}; > + > +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg) > +{ > + struct device *dev = cfg->parent; > + struct acpi_device *adev = to_acpi_device(dev); > + struct acpi_device *child_adev; > + struct resource *res_pem; > + > + res_pem = devm_kzalloc(dev, sizeof(*res_pem), GFP_KERNEL); > + if (!res_pem) { > + dev_err(dev, "failed to allocate PEM resource\n"); > + return NULL; > + } > + > + list_for_each_entry(child_adev, &adev->children, node) { > + struct resource_entry *entry; > + struct list_head list; > + unsigned long flags; > + int ret; > + > + ret = acpi_match_device_ids(child_adev, thunder_pem_reg_ids); > + if (ret) > + continue; > + > + INIT_LIST_HEAD(&list); > + flags = IORESOURCE_MEM; > + ret = acpi_dev_get_resources(child_adev, &list, > + acpi_dev_filter_resource_type_cb, > + (void *)flags); > + if (ret < 0) { > + dev_err(&child_adev->dev, > + "failed to parse _CRS method, error code %d\n", > + ret); > + return NULL; > + } else if (ret == 0) { > + dev_err(&child_adev->dev, > + "no memory resources present in _CRS\n"); > + return NULL; > + } > + > + entry = list_first_entry(&list, struct resource_entry, node); > + *res_pem = *entry->res; > + acpi_dev_free_resource_list(&list); > + return res_pem; > + } > + > + return NULL; > +} > +#else > +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg) > +{ > + return NULL; > +} > +#endif > + > static int thunder_pem_init(struct pci_config_window *cfg) > { > struct device *dev = cfg->parent; > @@ -292,24 +371,24 @@ static int thunder_pem_init(struct pci_config_window *cfg) > struct thunder_pem_pci *pem_pci; > struct platform_device *pdev; > > - /* Only OF support for now */ > - if (!dev->of_node) > - return -EINVAL; > - > pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL); > if (!pem_pci) > return -ENOMEM; > > - pdev = to_platform_device(dev); > - > - /* > - * The second register range is the PEM bridge to the PCIe > - * bus. It has a different config access method than those > - * devices behind the bridge. > - */ > - res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1); > + if (acpi_disabled) { > + pdev = to_platform_device(dev); > + > + /* > + * The second register range is the PEM bridge to the PCIe > + * bus. It has a different config access method than those > + * devices behind the bridge. > + */ > + res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1); > + } else { > + res_pem = thunder_pem_acpi_res(cfg); > + } > if (!res_pem) { > - dev_err(dev, "missing \"reg[1]\"property\n"); > + dev_err(dev, "missing configuration region\n"); > return -EINVAL; > } > > @@ -332,7 +411,7 @@ static int thunder_pem_init(struct pci_config_window *cfg) > return 0; > } > > -static struct pci_ecam_ops pci_thunder_pem_ops = { > +struct pci_ecam_ops pci_thunder_pem_ops = { > .bus_shift = 24, > .init = thunder_pem_init, > .pci_ops = { > diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h > index f5740b7..3f2a98f 100644 > --- a/include/linux/pci-ecam.h > +++ b/include/linux/pci-ecam.h > @@ -58,6 +58,10 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn, > int where); > /* default ECAM ops */ > extern struct pci_ecam_ops pci_generic_ecam_ops; > +/* ECAM ops for known quirks */ > +#ifdef CONFIG_PCI_HOST_THUNDER_PEM > +extern struct pci_ecam_ops pci_thunder_pem_ops; > +#endif > > /* ops for buggy ECAM that supports only 32-bit accesses */ > extern struct pci_ecam_ops pci_32b_ops; > -- > 2.7.4 >
Hi Bjorn, On 11/30/2016 7:28 PM, Bjorn Helgaas wrote: > Actually, that raises a question for qualcomm and hisi: in the DT > model, we use non-ECAM config accessors in the driver, but in the ACPI > model, we use ECAM accessors. It seems like the accessors should be > the same regardless of whether we discover the bridge via DT or ACPI. For servers, we are only setting up the PCIe controller in ECAM mode in FW. If somebody wants to use DT with QCOM Server (unsupported but possible), they need to use pci-host-ecam-generic driver. Here is an example: pcie3 { compatible = "pci-host-ecam-generic"; device_type = "pci"; #address-cells = <3>; #size-cells = <2>; bus-range = <0x0 0xff>; linux,pci-domain = <3>; // CPU_PHYSICAL(2) SIZE(2) reg = <0xC00 0x00000000 0x0 0x10000000>; ... } I think you are referring to this driver here. obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o This driver is only in use by the mobile products. Sinan
On Wed, Nov 30, 2016 at 08:00:12PM -0500, Sinan Kaya wrote: > Hi Bjorn, > > On 11/30/2016 7:28 PM, Bjorn Helgaas wrote: > > Actually, that raises a question for qualcomm and hisi: in the DT > > model, we use non-ECAM config accessors in the driver, but in the ACPI > > model, we use ECAM accessors. It seems like the accessors should be > > the same regardless of whether we discover the bridge via DT or ACPI. > > For servers, we are only setting up the PCIe controller in ECAM mode in FW. > If somebody wants to use DT with QCOM Server (unsupported but possible), > they need to use pci-host-ecam-generic driver. > > Here is an example: > > pcie3 { > compatible = "pci-host-ecam-generic"; > device_type = "pci"; > #address-cells = <3>; > #size-cells = <2>; > bus-range = <0x0 0xff>; > linux,pci-domain = <3>; > > // CPU_PHYSICAL(2) SIZE(2) > reg = <0xC00 0x00000000 0x0 0x10000000>; > ... > } > > I think you are referring to this driver here. > > obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o > > This driver is only in use by the mobile products. https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=2bb62a60711e says it's for the Qualcomm QDF2432. Is pcie-qcom for that same device, or is it for something different? I assume it's probably different because pci-host-ecam-generic uses the standard ECAM accessors (pci_generic_ecam_ops), while the quirk requires non-standard ones (pci_32b_ops). If these are two different controllers, that's fine. If it's the same controller in both cases, the controller should be configured the same way (either by FW or by the DT driver) and we should use the same accessors. If you have to use different accessors for the same controller, you would need some explanation for the difference because it's a maintenance headache to operate a device in different modes depending on the environment or which driver you're using. Bjorn
On 11/30/2016 10:48 PM, Bjorn Helgaas wrote: > On Wed, Nov 30, 2016 at 08:00:12PM -0500, Sinan Kaya wrote: >> Hi Bjorn, >> >> On 11/30/2016 7:28 PM, Bjorn Helgaas wrote: >>> Actually, that raises a question for qualcomm and hisi: in the DT >>> model, we use non-ECAM config accessors in the driver, but in the ACPI >>> model, we use ECAM accessors. It seems like the accessors should be >>> the same regardless of whether we discover the bridge via DT or ACPI. >> >> For servers, we are only setting up the PCIe controller in ECAM mode in FW. >> If somebody wants to use DT with QCOM Server (unsupported but possible), >> they need to use pci-host-ecam-generic driver. >> >> Here is an example: >> >> pcie3 { >> compatible = "pci-host-ecam-generic"; >> device_type = "pci"; >> #address-cells = <3>; >> #size-cells = <2>; >> bus-range = <0x0 0xff>; >> linux,pci-domain = <3>; >> >> // CPU_PHYSICAL(2) SIZE(2) >> reg = <0xC00 0x00000000 0x0 0x10000000>; >> ... >> } >> >> I think you are referring to this driver here. >> >> obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o >> >> This driver is only in use by the mobile products. > > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=2bb62a60711e > says it's for the Qualcomm QDF2432. Is pcie-qcom for that same > device, or is it for something different? They are different controllers. Qualcomm QDF2432 only supports ECAM mode only and is designed for ACPI based server products by the Data Center division. If somebody really needs device tree for QDF2432 server chip even though we don't officially support it, generic host driver with ECAM mode is the way to go. Even there, we need a small patch to pci_generic_ecam_ops as follows due to quirky HW. Generic host driver won't work out of the box. struct pci_ecam_ops pci_generic_ecam_ops = { .bus_shift = 20, .pci_ops = { .map_bus = pci_ecam_map_bus, - .read = pci_generic_config_read, + .read = pci_generic_config_read32, - .write = pci_generic_config_write, + .write = pci_generic_config_write32, } }; This is essentially what pci_32b_ops is. Since device-tree is not officially supported, we didn't bother making changes to the generic host bridge driver. https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=2bb62a60711e is the only thing needed for QDF2432. > > I assume it's probably different because pci-host-ecam-generic uses > the standard ECAM accessors (pci_generic_ecam_ops), while the quirk > requires non-standard ones (pci_32b_ops). > > If these are two different controllers, that's fine. If it's the same > controller in both cases, the controller should be configured the same > way (either by FW or by the DT driver) and we should use the same > accessors. > > If you have to use different accessors for the same controller, you > would need some explanation for the difference because it's a > maintenance headache to operate a device in different modes depending > on the environment or which driver you're using. > > Bjorn >
Hi Bjorn, On 01.12.2016 01:28, Bjorn Helgaas wrote: > Hi Tomasz, > > On Tue, Nov 15, 2016 at 10:14:57AM +0100, Tomasz Nowicki wrote: >> 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 pci_thunder_pem_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. thunder_pem_init() ACPI extension so that we can probe PEM-specific >> register ranges analogously to DT >> 2. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk >> code. >> 3. New quirk entries for each PEM segment. Each contains platform IDs, >> mentioned pci_thunder_pem_ops and CFG resources. >> >> Quirk is considered for ThunderX silicon pass2.x only which is identified >> via MCFG revision 1. >> >> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> >> --- >> drivers/acpi/pci_mcfg.c | 20 +++++++ >> drivers/pci/host/pci-thunder-pem.c | 107 ++++++++++++++++++++++++++++++++----- >> include/linux/pci-ecam.h | 4 ++ >> 3 files changed, 117 insertions(+), 14 deletions(-) >> >> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c >> index ac21db3..e4e2b9b 100644 >> --- a/drivers/acpi/pci_mcfg.c >> +++ b/drivers/acpi/pci_mcfg.c >> @@ -57,6 +57,26 @@ static struct mcfg_fixup mcfg_quirks[] = { >> { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops }, >> { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops }, >> { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops }, >> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM >> +#define THUNDER_MCFG_RES(addr, node) \ >> + DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M) >> +#define THUNDER_MCFG_QUIRK(rev, node) \ >> + { "CAVIUM", "THUNDERX", rev, 4 + (10 * node), MCFG_BUS_ANY, \ >> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88001f000000UL, node) }, \ >> + { "CAVIUM", "THUNDERX", rev, 5 + (10 * node), MCFG_BUS_ANY, \ >> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x884057000000UL, node) }, \ >> + { "CAVIUM", "THUNDERX", rev, 6 + (10 * node), MCFG_BUS_ANY, \ >> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88808f000000UL, node) }, \ >> + { "CAVIUM", "THUNDERX", rev, 7 + (10 * node), MCFG_BUS_ANY, \ >> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89001f000000UL, node) }, \ >> + { "CAVIUM", "THUNDERX", rev, 8 + (10 * node), MCFG_BUS_ANY, \ >> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x894057000000UL, node) }, \ >> + { "CAVIUM", "THUNDERX", rev, 9 + (10 * node), MCFG_BUS_ANY, \ >> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89808f000000UL, node) } >> + /* SoC pass2.x */ >> + THUNDER_MCFG_QUIRK(1, 0UL), >> + THUNDER_MCFG_QUIRK(1, 1UL), >> +#endif > > I want all these quirks to work without having to enable > device-specific config options like CONFIG_PCI_HOST_THUNDER_PEM. > > I tweaked the preceding MCFG quirk support to wrap it in > CONFIG_PCI_QUIRKS. I also tweaked the qualcomm and hisi patches to > move the meat of them to pci/quirks.c. My work-in-progress is on > pci/ecam, but I can't easily build for arm64, so there are likely some > issues to be resolved. Please see compilation fix patch in [1] for your series. > > I'm hoping to end up with something like this: > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469 > > The problem with ThunderX is that the config accessors are much bigger > and I don't really want to duplicate them in both pci/quirks.c and > pci-thunder-pem.c. > > Actually, that raises a question for qualcomm and hisi: in the DT > model, we use non-ECAM config accessors in the driver, but in the ACPI > model, we use ECAM accessors. It seems like the accessors should be > the same regardless of whether we discover the bridge via DT or ACPI. > > Anyway, it's almost like we want to build pci-thunder-pem.o if > CONFIG_PCI_HOST_THUNDER_PEM || (CONFIG_PCI_QUIRKS && CONFIG_ARM64). > I don't know how to express that nicely. > > I was trying to avoid adding an ecam-quirks.c, but maybe we need to > add it and collect all the different accessors there and add #ifdefs > inside. > > Sorry, this is only half-baked, but I just wanted to throw this out in > case you have any ideas. I agree that pci-thunder-pem.c and pci-thunder-ecam.c are too big to be duplicated. The same for new ecam-quirks.c container. So treating this as a necessary evil how about: config PCI_HOST_THUNDER_PEM bool "Cavium Thunder PCIe controller to off-chip devices" - depends on OF && ARM64 + depends on ARM64 + depends on OF || (ACPI && PCI_QUIRKS) select PCI_HOST_COMMON Moreover, IMO we should select PCI_QUIRKS for ARM64 && ACPI by default. Then it becomes: config PCI_HOST_THUNDER_PEM bool "Cavium Thunder PCIe controller to off-chip devices" - depends on OF && ARM64 + depends on ARM64 + depends on OF || ACPI select PCI_HOST_COMMON I put the picture together here (on top of your pci/ecam branch): [1] https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2 Thanks, Tomasz
Tomasz, Bjorn, On 01.12.16 09:49:51, Tomasz Nowicki wrote: > I put the picture together here (on top of your pci/ecam branch): > [1] https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2 please note that acpi_* functions must be protected with acpi_disabled or something else to make sure an acpi enabled kernel does not break dt. See the crash below with above branch. -Robert [ 12.493028] Unable to handle kernel NULL pointer dereference at virtual address 00000018 [ 12.501113] pgd = ffff0000090a0000 [ 12.504511] [00000018] *pgd=0000010fffef0003[ 12.508602] , *pud=0000010fffef0003 , *pmd=0000010fffee0003[ 12.514093] , *pte=0000000000000000 [ 12.517575] [ 12.519064] Internal error: Oops: 96000005 [#1] SMP [ 12.523933] Modules linked in: [ 12.526987] CPU: 73 PID: 1 Comm: swapper/0 Tainted: G W 4.9.0-rc6.0.vanilla10-00019-g09abd2b6bbeb #135 [ 12.537409] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012 [ 12.545748] task: ffff800fe85b8000 task.stack: ffff800ff4288000 [ 12.551674] PC is at acpi_ns_walk_namespace+0x68/0x1d4 [ 12.556803] LR is at acpi_get_devices+0x6c/0x94 ... [ 13.124920] [<ffff0000084dc5a0>] acpi_ns_walk_namespace+0x68/0x1d4 [ 13.131090] [<ffff0000084dcadc>] acpi_get_devices+0x6c/0x94 [ 13.136663] [<ffff0000084c0aec>] acpi_resource_consumer+0x34/0x44 [ 13.142752] [<ffff000008496bc0>] pci_ecam_create+0x80/0x228 [ 13.148314] [<ffff000008498e64>] pci_host_common_probe+0x294/0x348 [ 13.154486] [<ffff00000849bf3c>] thunder_ecam_probe+0x2c/0x38 [ 13.160226] [<ffff0000085880b8>] platform_drv_probe+0x60/0xc8 [ 13.165970] [<ffff000008585a04>] driver_probe_device+0x26c/0x420 [ 13.171966] [<ffff000008585cdc>] __driver_attach+0x124/0x128 [ 13.177615] [<ffff000008583238>] bus_for_each_dev+0x70/0xb0 [ 13.183177] [<ffff000008585060>] driver_attach+0x30/0x40 [ 13.188478] [<ffff000008584a98>] bus_add_driver+0x200/0x2b8 [ 13.194041] [<ffff000008586860>] driver_register+0x68/0x100 [ 13.199602] [<ffff000008587fdc>] __platform_driver_register+0x54/0x60 [ 13.206038] [<ffff000008c39b98>] thunder_ecam_driver_init+0x18/0x20 [ 13.212296] [<ffff000008082d94>] do_one_initcall+0x44/0x138 [ 13.217862] [<ffff000008c00d0c>] kernel_init_freeable+0x1ac/0x24c [ 13.223950] [<ffff0000088605f0>] kernel_init+0x18/0x110 [ 13.229165] [<ffff000008082b30>] ret_from_fork+0x10/0x20
On Thu, Dec 01, 2016 at 02:55:49PM +0100, Robert Richter wrote: > Tomasz, Bjorn, > > On 01.12.16 09:49:51, Tomasz Nowicki wrote: > > I put the picture together here (on top of your pci/ecam branch): > > [1] https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2 > > please note that acpi_* functions must be protected with acpi_disabled > or something else to make sure an acpi enabled kernel does not break > dt. See the crash below with above branch. You could use struct device.of_node, or just move the MCFG check to ACPI code that probes the root bus in arm64 before calling pci_ecam_create() which will save you some ifdeffery too while at it. Lorenzo > -Robert > > [ 12.493028] Unable to handle kernel NULL pointer dereference at virtual address 00000018 > [ 12.501113] pgd = ffff0000090a0000 > [ 12.504511] [00000018] *pgd=0000010fffef0003[ 12.508602] , *pud=0000010fffef0003 > , *pmd=0000010fffee0003[ 12.514093] , *pte=0000000000000000 > [ 12.517575] > [ 12.519064] Internal error: Oops: 96000005 [#1] SMP > [ 12.523933] Modules linked in: > [ 12.526987] CPU: 73 PID: 1 Comm: swapper/0 Tainted: G W 4.9.0-rc6.0.vanilla10-00019-g09abd2b6bbeb #135 > [ 12.537409] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012 > [ 12.545748] task: ffff800fe85b8000 task.stack: ffff800ff4288000 > [ 12.551674] PC is at acpi_ns_walk_namespace+0x68/0x1d4 > [ 12.556803] LR is at acpi_get_devices+0x6c/0x94 > ... > [ 13.124920] [<ffff0000084dc5a0>] acpi_ns_walk_namespace+0x68/0x1d4 > [ 13.131090] [<ffff0000084dcadc>] acpi_get_devices+0x6c/0x94 > [ 13.136663] [<ffff0000084c0aec>] acpi_resource_consumer+0x34/0x44 > [ 13.142752] [<ffff000008496bc0>] pci_ecam_create+0x80/0x228 > [ 13.148314] [<ffff000008498e64>] pci_host_common_probe+0x294/0x348 > [ 13.154486] [<ffff00000849bf3c>] thunder_ecam_probe+0x2c/0x38 > [ 13.160226] [<ffff0000085880b8>] platform_drv_probe+0x60/0xc8 > [ 13.165970] [<ffff000008585a04>] driver_probe_device+0x26c/0x420 > [ 13.171966] [<ffff000008585cdc>] __driver_attach+0x124/0x128 > [ 13.177615] [<ffff000008583238>] bus_for_each_dev+0x70/0xb0 > [ 13.183177] [<ffff000008585060>] driver_attach+0x30/0x40 > [ 13.188478] [<ffff000008584a98>] bus_add_driver+0x200/0x2b8 > [ 13.194041] [<ffff000008586860>] driver_register+0x68/0x100 > [ 13.199602] [<ffff000008587fdc>] __platform_driver_register+0x54/0x60 > [ 13.206038] [<ffff000008c39b98>] thunder_ecam_driver_init+0x18/0x20 > [ 13.212296] [<ffff000008082d94>] do_one_initcall+0x44/0x138 > [ 13.217862] [<ffff000008c00d0c>] kernel_init_freeable+0x1ac/0x24c > [ 13.223950] [<ffff0000088605f0>] kernel_init+0x18/0x110 > [ 13.229165] [<ffff000008082b30>] ret_from_fork+0x10/0x20
On Thu, Dec 01, 2016 at 09:49:51AM +0100, Tomasz Nowicki wrote: > Hi Bjorn, > > On 01.12.2016 01:28, Bjorn Helgaas wrote: > >Hi Tomasz, > > > >On Tue, Nov 15, 2016 at 10:14:57AM +0100, Tomasz Nowicki wrote: > >>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 pci_thunder_pem_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. thunder_pem_init() ACPI extension so that we can probe PEM-specific > >> register ranges analogously to DT > >>2. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk > >> code. > >>3. New quirk entries for each PEM segment. Each contains platform IDs, > >> mentioned pci_thunder_pem_ops and CFG resources. > >> > >>Quirk is considered for ThunderX silicon pass2.x only which is identified > >>via MCFG revision 1. > >> > >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com> > >>--- > >> drivers/acpi/pci_mcfg.c | 20 +++++++ > >> drivers/pci/host/pci-thunder-pem.c | 107 ++++++++++++++++++++++++++++++++----- > >> include/linux/pci-ecam.h | 4 ++ > >> 3 files changed, 117 insertions(+), 14 deletions(-) > >> > >>diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c > >>index ac21db3..e4e2b9b 100644 > >>--- a/drivers/acpi/pci_mcfg.c > >>+++ b/drivers/acpi/pci_mcfg.c > >>@@ -57,6 +57,26 @@ static struct mcfg_fixup mcfg_quirks[] = { > >> { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops }, > >> { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops }, > >> { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops }, > >>+#ifdef CONFIG_PCI_HOST_THUNDER_PEM > >>+#define THUNDER_MCFG_RES(addr, node) \ > >>+ DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M) > >>+#define THUNDER_MCFG_QUIRK(rev, node) \ > >>+ { "CAVIUM", "THUNDERX", rev, 4 + (10 * node), MCFG_BUS_ANY, \ > >>+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88001f000000UL, node) }, \ > >>+ { "CAVIUM", "THUNDERX", rev, 5 + (10 * node), MCFG_BUS_ANY, \ > >>+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x884057000000UL, node) }, \ > >>+ { "CAVIUM", "THUNDERX", rev, 6 + (10 * node), MCFG_BUS_ANY, \ > >>+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88808f000000UL, node) }, \ > >>+ { "CAVIUM", "THUNDERX", rev, 7 + (10 * node), MCFG_BUS_ANY, \ > >>+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89001f000000UL, node) }, \ > >>+ { "CAVIUM", "THUNDERX", rev, 8 + (10 * node), MCFG_BUS_ANY, \ > >>+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x894057000000UL, node) }, \ > >>+ { "CAVIUM", "THUNDERX", rev, 9 + (10 * node), MCFG_BUS_ANY, \ > >>+ &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89808f000000UL, node) } > >>+ /* SoC pass2.x */ > >>+ THUNDER_MCFG_QUIRK(1, 0UL), > >>+ THUNDER_MCFG_QUIRK(1, 1UL), > >>+#endif > > > >I want all these quirks to work without having to enable > >device-specific config options like CONFIG_PCI_HOST_THUNDER_PEM. > > > >I tweaked the preceding MCFG quirk support to wrap it in > >CONFIG_PCI_QUIRKS. I also tweaked the qualcomm and hisi patches to > >move the meat of them to pci/quirks.c. My work-in-progress is on > >pci/ecam, but I can't easily build for arm64, so there are likely some > >issues to be resolved. > > Please see compilation fix patch in [1] for your series. > > > > >I'm hoping to end up with something like this: > >https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469 > > > >The problem with ThunderX is that the config accessors are much bigger > >and I don't really want to duplicate them in both pci/quirks.c and > >pci-thunder-pem.c. > > > >Actually, that raises a question for qualcomm and hisi: in the DT > >model, we use non-ECAM config accessors in the driver, but in the ACPI > >model, we use ECAM accessors. It seems like the accessors should be > >the same regardless of whether we discover the bridge via DT or ACPI. > > > >Anyway, it's almost like we want to build pci-thunder-pem.o if > >CONFIG_PCI_HOST_THUNDER_PEM || (CONFIG_PCI_QUIRKS && CONFIG_ARM64). > >I don't know how to express that nicely. > > > >I was trying to avoid adding an ecam-quirks.c, but maybe we need to > >add it and collect all the different accessors there and add #ifdefs > >inside. > > > >Sorry, this is only half-baked, but I just wanted to throw this out in > >case you have any ideas. > > I agree that pci-thunder-pem.c and pci-thunder-ecam.c are too big to > be duplicated. The same for new ecam-quirks.c container. So treating > this as a necessary evil how about: I discarded my original half-baked ecam-quirks.c idea and instead tried changing the Makefile and adding some ifdefs in the individual drivers. It's not too pretty, but maybe better than ecam-quirks.c? > config PCI_HOST_THUNDER_PEM > bool "Cavium Thunder PCIe controller to off-chip devices" > - depends on OF && ARM64 > + depends on ARM64 > + depends on OF || (ACPI && PCI_QUIRKS) > select PCI_HOST_COMMON > > Moreover, IMO we should select PCI_QUIRKS for ARM64 && ACPI by > default. Then it becomes: > config PCI_HOST_THUNDER_PEM > bool "Cavium Thunder PCIe controller to off-chip devices" > - depends on OF && ARM64 > + depends on ARM64 > + depends on OF || ACPI > select PCI_HOST_COMMON Thanks, I think you're right about needing Kconfig changes here. I incorporated the first one (with "(ACPI && PCI_QUIRKS)") because we shouldn't offer this Kconfig choice when PCI_QUIRKS is not set. If we only depend on ACPI here and we decide that ARM64 should *not* automatically select PCI_QUIRKS, we'll offer this choice even when PCI_QUIRKS is not set, and that seems wrong. Making it explicit here removes the non-obvious connection with the PCI_QUIRKS selection strateg. Bjorn
On Thu, Dec 01, 2016 at 02:55:49PM +0100, Robert Richter wrote: > Tomasz, Bjorn, > > On 01.12.16 09:49:51, Tomasz Nowicki wrote: > > I put the picture together here (on top of your pci/ecam branch): > > [1] https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2 > > please note that acpi_* functions must be protected with acpi_disabled > or something else to make sure an acpi enabled kernel does not break > dt. See the crash below with above branch. Yes, thanks! I added if (acpi_disabled) return NULL; to acpi_resource_consumer(), which I think should fix this. > [ 12.493028] Unable to handle kernel NULL pointer dereference at virtual address 00000018 > [ 12.501113] pgd = ffff0000090a0000 > [ 12.504511] [00000018] *pgd=0000010fffef0003[ 12.508602] , *pud=0000010fffef0003 > , *pmd=0000010fffee0003[ 12.514093] , *pte=0000000000000000 > [ 12.517575] > [ 12.519064] Internal error: Oops: 96000005 [#1] SMP > [ 12.523933] Modules linked in: > [ 12.526987] CPU: 73 PID: 1 Comm: swapper/0 Tainted: G W 4.9.0-rc6.0.vanilla10-00019-g09abd2b6bbeb #135 > [ 12.537409] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012 > [ 12.545748] task: ffff800fe85b8000 task.stack: ffff800ff4288000 > [ 12.551674] PC is at acpi_ns_walk_namespace+0x68/0x1d4 > [ 12.556803] LR is at acpi_get_devices+0x6c/0x94 > ... > [ 13.124920] [<ffff0000084dc5a0>] acpi_ns_walk_namespace+0x68/0x1d4 > [ 13.131090] [<ffff0000084dcadc>] acpi_get_devices+0x6c/0x94 > [ 13.136663] [<ffff0000084c0aec>] acpi_resource_consumer+0x34/0x44 > [ 13.142752] [<ffff000008496bc0>] pci_ecam_create+0x80/0x228 > [ 13.148314] [<ffff000008498e64>] pci_host_common_probe+0x294/0x348 > [ 13.154486] [<ffff00000849bf3c>] thunder_ecam_probe+0x2c/0x38 > [ 13.160226] [<ffff0000085880b8>] platform_drv_probe+0x60/0xc8 > [ 13.165970] [<ffff000008585a04>] driver_probe_device+0x26c/0x420 > [ 13.171966] [<ffff000008585cdc>] __driver_attach+0x124/0x128 > [ 13.177615] [<ffff000008583238>] bus_for_each_dev+0x70/0xb0 > [ 13.183177] [<ffff000008585060>] driver_attach+0x30/0x40 > [ 13.188478] [<ffff000008584a98>] bus_add_driver+0x200/0x2b8 > [ 13.194041] [<ffff000008586860>] driver_register+0x68/0x100 > [ 13.199602] [<ffff000008587fdc>] __platform_driver_register+0x54/0x60 > [ 13.206038] [<ffff000008c39b98>] thunder_ecam_driver_init+0x18/0x20 > [ 13.212296] [<ffff000008082d94>] do_one_initcall+0x44/0x138 > [ 13.217862] [<ffff000008c00d0c>] kernel_init_freeable+0x1ac/0x24c > [ 13.223950] [<ffff0000088605f0>] kernel_init+0x18/0x110 > [ 13.229165] [<ffff000008082b30>] ret_from_fork+0x10/0x20 > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, Dec 01, 2016 at 02:54:50PM +0000, Lorenzo Pieralisi wrote: > On Thu, Dec 01, 2016 at 02:55:49PM +0100, Robert Richter wrote: > > Tomasz, Bjorn, > > > > On 01.12.16 09:49:51, Tomasz Nowicki wrote: > > > I put the picture together here (on top of your pci/ecam branch): > > > [1] https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2 > > > > please note that acpi_* functions must be protected with acpi_disabled > > or something else to make sure an acpi enabled kernel does not break > > dt. See the crash below with above branch. > > You could use struct device.of_node, or just move the MCFG check to ACPI > code that probes the root bus in arm64 before calling pci_ecam_create() > which will save you some ifdeffery too while at it. Oh, I like that idea even better! I took the acpi_disabled check back out of acpi_resource_consumer() and moved the call to pci_acpi_setup_ecam_mapping(). Thanks! > > [ 12.493028] Unable to handle kernel NULL pointer dereference at virtual address 00000018 > > [ 12.501113] pgd = ffff0000090a0000 > > [ 12.504511] [00000018] *pgd=0000010fffef0003[ 12.508602] , *pud=0000010fffef0003 > > , *pmd=0000010fffee0003[ 12.514093] , *pte=0000000000000000 > > [ 12.517575] > > [ 12.519064] Internal error: Oops: 96000005 [#1] SMP > > [ 12.523933] Modules linked in: > > [ 12.526987] CPU: 73 PID: 1 Comm: swapper/0 Tainted: G W 4.9.0-rc6.0.vanilla10-00019-g09abd2b6bbeb #135 > > [ 12.537409] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012 > > [ 12.545748] task: ffff800fe85b8000 task.stack: ffff800ff4288000 > > [ 12.551674] PC is at acpi_ns_walk_namespace+0x68/0x1d4 > > [ 12.556803] LR is at acpi_get_devices+0x6c/0x94 > > ... > > [ 13.124920] [<ffff0000084dc5a0>] acpi_ns_walk_namespace+0x68/0x1d4 > > [ 13.131090] [<ffff0000084dcadc>] acpi_get_devices+0x6c/0x94 > > [ 13.136663] [<ffff0000084c0aec>] acpi_resource_consumer+0x34/0x44 > > [ 13.142752] [<ffff000008496bc0>] pci_ecam_create+0x80/0x228 > > [ 13.148314] [<ffff000008498e64>] pci_host_common_probe+0x294/0x348 > > [ 13.154486] [<ffff00000849bf3c>] thunder_ecam_probe+0x2c/0x38 > > [ 13.160226] [<ffff0000085880b8>] platform_drv_probe+0x60/0xc8 > > [ 13.165970] [<ffff000008585a04>] driver_probe_device+0x26c/0x420 > > [ 13.171966] [<ffff000008585cdc>] __driver_attach+0x124/0x128 > > [ 13.177615] [<ffff000008583238>] bus_for_each_dev+0x70/0xb0 > > [ 13.183177] [<ffff000008585060>] driver_attach+0x30/0x40 > > [ 13.188478] [<ffff000008584a98>] bus_add_driver+0x200/0x2b8 > > [ 13.194041] [<ffff000008586860>] driver_register+0x68/0x100 > > [ 13.199602] [<ffff000008587fdc>] __platform_driver_register+0x54/0x60 > > [ 13.206038] [<ffff000008c39b98>] thunder_ecam_driver_init+0x18/0x20 > > [ 13.212296] [<ffff000008082d94>] do_one_initcall+0x44/0x138 > > [ 13.217862] [<ffff000008c00d0c>] kernel_init_freeable+0x1ac/0x24c > > [ 13.223950] [<ffff0000088605f0>] kernel_init+0x18/0x110 > > [ 13.229165] [<ffff000008082b30>] ret_from_fork+0x10/0x20
On 11/30/2016 07:28 PM, Bjorn Helgaas wrote: > I'm hoping to end up with something like this: > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469 The following build warnings happen using your branch on RHELSA7.3: drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */ ^ drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[44].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[44].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[45].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[45].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[46].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[46].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[47].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[47].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[48].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[48].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[49].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ‘mcfg_quirks[49].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */ ^ drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[50].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[50].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[51].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[51].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[52].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[52].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[53].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[53].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[54].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[54].cfgres.end’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[55].cfgres.start’) [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default] drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ‘mcfg_quirks[55].cfgres.end’) [enabled by default] Jon.
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c index ac21db3..e4e2b9b 100644 --- a/drivers/acpi/pci_mcfg.c +++ b/drivers/acpi/pci_mcfg.c @@ -57,6 +57,26 @@ static struct mcfg_fixup mcfg_quirks[] = { { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops }, { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops }, { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops }, +#ifdef CONFIG_PCI_HOST_THUNDER_PEM +#define THUNDER_MCFG_RES(addr, node) \ + DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M) +#define THUNDER_MCFG_QUIRK(rev, node) \ + { "CAVIUM", "THUNDERX", rev, 4 + (10 * node), MCFG_BUS_ANY, \ + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88001f000000UL, node) }, \ + { "CAVIUM", "THUNDERX", rev, 5 + (10 * node), MCFG_BUS_ANY, \ + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x884057000000UL, node) }, \ + { "CAVIUM", "THUNDERX", rev, 6 + (10 * node), MCFG_BUS_ANY, \ + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88808f000000UL, node) }, \ + { "CAVIUM", "THUNDERX", rev, 7 + (10 * node), MCFG_BUS_ANY, \ + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89001f000000UL, node) }, \ + { "CAVIUM", "THUNDERX", rev, 8 + (10 * node), MCFG_BUS_ANY, \ + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x894057000000UL, node) }, \ + { "CAVIUM", "THUNDERX", rev, 9 + (10 * node), MCFG_BUS_ANY, \ + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89808f000000UL, node) } + /* SoC pass2.x */ + THUNDER_MCFG_QUIRK(1, 0UL), + THUNDER_MCFG_QUIRK(1, 1UL), +#endif }; static char mcfg_oem_id[ACPI_OEM_ID_SIZE]; diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c index 6abaf80..7bdc4cd 100644 --- a/drivers/pci/host/pci-thunder-pem.c +++ b/drivers/pci/host/pci-thunder-pem.c @@ -18,6 +18,7 @@ #include <linux/init.h> #include <linux/of_address.h> #include <linux/of_pci.h> +#include <linux/pci-acpi.h> #include <linux/pci-ecam.h> #include <linux/platform_device.h> @@ -284,6 +285,84 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn, return pci_generic_config_write(bus, devfn, where, size, val); } +#ifdef CONFIG_ACPI + +/* + * Retrieve PEM bridge register base and size from PNP0C02 sub-device under + * the RC. + * + * Device (RES0) + * { + * Name (_HID, "THRX0002") + * Name (_CID, "PNP0C02") + * Name (_CRS, ResourceTemplate () { + * // Device specific registers range + * QWordMemory(ResourceConsumer, PosDecode, MinFixed, + * MaxFixed, Cacheable, ReadWrite, 0, + * 0x87e0c2000000, 0x87E0C2FFFFFF, 0, 0x1000000) + * }) + * } + */ + +static const struct acpi_device_id thunder_pem_reg_ids[] = { + {"THRX0002", 0}, + {"", 0}, +}; + +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg) +{ + struct device *dev = cfg->parent; + struct acpi_device *adev = to_acpi_device(dev); + struct acpi_device *child_adev; + struct resource *res_pem; + + res_pem = devm_kzalloc(dev, sizeof(*res_pem), GFP_KERNEL); + if (!res_pem) { + dev_err(dev, "failed to allocate PEM resource\n"); + return NULL; + } + + list_for_each_entry(child_adev, &adev->children, node) { + struct resource_entry *entry; + struct list_head list; + unsigned long flags; + int ret; + + ret = acpi_match_device_ids(child_adev, thunder_pem_reg_ids); + if (ret) + continue; + + INIT_LIST_HEAD(&list); + flags = IORESOURCE_MEM; + ret = acpi_dev_get_resources(child_adev, &list, + acpi_dev_filter_resource_type_cb, + (void *)flags); + if (ret < 0) { + dev_err(&child_adev->dev, + "failed to parse _CRS method, error code %d\n", + ret); + return NULL; + } else if (ret == 0) { + dev_err(&child_adev->dev, + "no memory resources present in _CRS\n"); + return NULL; + } + + entry = list_first_entry(&list, struct resource_entry, node); + *res_pem = *entry->res; + acpi_dev_free_resource_list(&list); + return res_pem; + } + + return NULL; +} +#else +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg) +{ + return NULL; +} +#endif + static int thunder_pem_init(struct pci_config_window *cfg) { struct device *dev = cfg->parent; @@ -292,24 +371,24 @@ static int thunder_pem_init(struct pci_config_window *cfg) struct thunder_pem_pci *pem_pci; struct platform_device *pdev; - /* Only OF support for now */ - if (!dev->of_node) - return -EINVAL; - pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL); if (!pem_pci) return -ENOMEM; - pdev = to_platform_device(dev); - - /* - * The second register range is the PEM bridge to the PCIe - * bus. It has a different config access method than those - * devices behind the bridge. - */ - res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1); + if (acpi_disabled) { + pdev = to_platform_device(dev); + + /* + * The second register range is the PEM bridge to the PCIe + * bus. It has a different config access method than those + * devices behind the bridge. + */ + res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1); + } else { + res_pem = thunder_pem_acpi_res(cfg); + } if (!res_pem) { - dev_err(dev, "missing \"reg[1]\"property\n"); + dev_err(dev, "missing configuration region\n"); return -EINVAL; } @@ -332,7 +411,7 @@ static int thunder_pem_init(struct pci_config_window *cfg) return 0; } -static struct pci_ecam_ops pci_thunder_pem_ops = { +struct pci_ecam_ops pci_thunder_pem_ops = { .bus_shift = 24, .init = thunder_pem_init, .pci_ops = { diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h index f5740b7..3f2a98f 100644 --- a/include/linux/pci-ecam.h +++ b/include/linux/pci-ecam.h @@ -58,6 +58,10 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn, int where); /* default ECAM ops */ extern struct pci_ecam_ops pci_generic_ecam_ops; +/* ECAM ops for known quirks */ +#ifdef CONFIG_PCI_HOST_THUNDER_PEM +extern struct pci_ecam_ops pci_thunder_pem_ops; +#endif /* ops for buggy ECAM that supports only 32-bit accesses */ extern struct pci_ecam_ops pci_32b_ops;
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 pci_thunder_pem_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. thunder_pem_init() ACPI extension so that we can probe PEM-specific register ranges analogously to DT 2. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk code. 3. New quirk entries for each PEM segment. Each contains platform IDs, mentioned pci_thunder_pem_ops and CFG resources. Quirk is considered for ThunderX silicon pass2.x only which is identified via MCFG revision 1. Signed-off-by: Tomasz Nowicki <tn@semihalf.com> --- drivers/acpi/pci_mcfg.c | 20 +++++++ drivers/pci/host/pci-thunder-pem.c | 107 ++++++++++++++++++++++++++++++++----- include/linux/pci-ecam.h | 4 ++ 3 files changed, 117 insertions(+), 14 deletions(-)