From mboxrd@z Thu Jan 1 00:00:00 1970 From: suravee.suthikulpanit@amd.com (Suravee Suthikulanit) Date: Wed, 13 May 2015 07:47:42 -0500 Subject: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci In-Reply-To: <554ADCE0.8020603@amd.com> References: <1430791333-26013-1-git-send-email-jchandra@broadcom.com> <20150505155346.GJ1550@arm.com> <20150506141859.GC26028@red-moon> <554ADCE0.8020603@amd.com> Message-ID: <555347EE.6050502@amd.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Bjorn, Somehow, I didn't get your reply email from the ML. So, I've captured your questions here, please see my reply below. On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote: > Hi All, > > I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode > and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the > resource not claimed issue (no surprise here). > > So, I tried porting the pcibios_claim_one_bus() from > arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in > pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please > see example patch below.) > > The additional while loop is needed in the pci_claim_resource() since I > need to reference back to the resource in the root bus, which are > defined from the DT node. Does this sounds like a reasonable approach? > > diff --git a/drivers/pci/host/pci-host-generic.c > b/drivers/pci/host/pci-host-generic.c > index e9cc559..0dfa23d 100644 > --- a/drivers/pci/host/pci-host-generic.c > +++ b/drivers/pci/host/pci-host-generic.c > @@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev) > if (!pci_has_flag(PCI_PROBE_ONLY)) { > pci_bus_size_bridges(bus); > pci_bus_assign_resources(bus); > + } else { > + pci_claim_one_bus(bus); > } > + > pci_bus_add_devices(bus); > > /* Configure PCI Express settings */ > diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c > index 232f925..d4b43b3 100644 > --- a/drivers/pci/setup-res.c > +++ b/drivers/pci/setup-res.c > @@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int > resource) > { > struct resource *res = &dev->resource[resource]; > struct resource *root, *conflict; > + struct pci_dev *pdev = dev; > > if (res->flags & IORESOURCE_UNSET) { > dev_info(&dev->dev, "can't claim BAR %d %pR: no address > assigned\n", > @@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int > resource) > return -EINVAL; > } > > - root = pci_find_parent_resource(dev, res); > + while (pdev) { > + root = pci_find_parent_resource(pdev, res); > + if (root) > + break; > + > + if (pci_has_flag(PCI_PROBE_ONLY) && > + !pci_is_root_bus(pdev->bus)) > + pdev = pdev->bus->self; > + else > + break; > + } > + > if (!root) { > dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible > bridge window\n", > resource, res); [From Bjorn] I don't understand this new loop. Apparently you have a device BAR, and the upstream bridge doesn't have a window that contains the BAR? That sounds like a problem with the upstream bridge resources. Do you have an example that would make this more concrete, e.g., a host bridge, P2P bridge(s), and endpoint with their resources? [Suravee] Here is the information you were asking for. This information is setup from the FW. In the PCI bridge (00:02.1), I see the prefetchable memory behind bridge is already setup. OUTPUT from lspci -tv: -[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Device 1a00 +-02.0 Advanced Micro Devices, Inc. [AMD] Device 1a01 \-02.1 PCI Bridge -[01]--+-00.0 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection \-00.1 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection OUTPUT from lspci -vvv: 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a00 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1a00 Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- ....... 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR-