Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/6/2015 10:18 AM, Bjorn Helgaas wrote:
On Wed, May 6, 2015 at 9:18 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@xxxxxxx> wrote:
On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
The current code in pci-host-generic.c uses pci_common_init_dev()
from the arch/arm/ to do a part of the PCI initialization, and this
prevents it from being used on arm64.

The initialization done by pci_common_init_dev() that is really
needed by pci-host-generic.c can be done in the same file without
using the hw_pci API of ARM.

The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
this is be handled by setting up 'struct gen_pci' to embed a
pci_sys_data variable as the first element on the ARM platform.

Signed-off-by: Jayachandran C <jchandra@xxxxxxxxxxxx>
---
Here's v2 of the patches, this enables use of pci-host-generic on
arm64.

This has been tested on both qemu and fast model for arm64, and on
qemu for arm32.

v1->v2
  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
     - move contents of gen_pci_init to gen_pci_probe
     - assign resources only when !probe_only
  - tested on ARM32 with qemu option -M virt

I tried this with an arm64 kernel running under kvmtool, but I get the
following errors (a 32-bit ARM kernel does seem to work):

   PCI host bridge /pci ranges:
      IO 0x00000000..0x0000ffff -> 0x00000000
     MEM 0x41000000..0x7fffffff -> 0x41000000
   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
   pci_bus 0000:00: root bus resource [bus 00-01]
   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
   pci_bus 0000:00: scanning bus
   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
   pci_bus 0000:00: fixups for bus
   pci_bus 0000:00: bus scan returning with max=00
   pci 0000:00:00.0: fixup irq: got 10
   pci 0000:00:00.0: assigning IRQ 10
   pci 0000:00:01.0: fixup irq: got 11
   pci 0000:00:01.0: assigning IRQ 11
   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
   virtio-pci: probe of 0000:00:00.0 failed with error -22
   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
   virtio-pci: probe of 0000:00:01.0 failed with error -22

Ok, had a further look.

Referring to this thread:

https://lkml.org/lkml/2014/9/29/557

By looking at other architectures code, resources should be claimed
(ie requested) even when PCI_PROBE_ONLY is set. Alpha, Sparc and PowerPC
seem to do that, in slightly different fashions.

I do not think, as Bjorn mentioned, that PCI_PROBE_ONLY should be used
to prevent enabling resources through a PCI command, which is what
pci_enable_resources does.

What we can do, is providing a generic PCI layer API that allows claiming
resources for a specific PCI bus, something similar if not identical
to what is done on alpha:

arch/alpha/kernel/pci.c pcibios_claim_one_bus()

that is not alpha specific at all. That way, we can use the API to claim
bus resources instead of assigning them on PCI_PROBE_ONLY (I *think*
that alpha calls pci_assign_unassigned_resources() even if
PCI_PROBE_ONLY is set, it should be safe since resources are claimed
first so IIUC the PCI layer would revert to FW BAR configuration on
assignment failure).

Bjorn, any opinion on this ? Putting together a patch is easy when
we agree on the solution.

I would like claiming resources, i.e., pci_claim_resource(), to happen
in the core instead of in arch code because it's not inherently
arch-specific.  I don't think it should depend on PCI_PROBE_ONLY.

Bjorn


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);
@@ -136,6 +148,36 @@ int pci_claim_resource(struct pci_dev *dev, int resource)
 }
 EXPORT_SYMBOL(pci_claim_resource);

+void pci_claim_one_bus(struct pci_bus *b)
+{
+	struct pci_dev *pdev;
+	struct pci_bus *child_bus;
+
+	list_for_each_entry(pdev, &b->devices, bus_list) {
+		int i;
+
+		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
+			struct resource *r = &pdev->resource[i];
+
+			if (r->parent || !r->start || !r->flags)
+				continue;
+
+			if (pci_has_flag(PCI_PROBE_ONLY) ||
+			    (r->flags & IORESOURCE_PCI_FIXED)) {
+				if (pci_claim_resource(pdev, i) == 0)
+					continue;
+
+				pci_claim_bridge_resource(pdev, i);
+			}
+		}
+	}
+
+	list_for_each_entry(child_bus, &b->children, node) {
+		pci_claim_one_bus(child_bus);
+	}
+}
+EXPORT_SYMBOL(pci_claim_one_bus);
+
 void pci_disable_bridge_window(struct pci_dev *dev)
 {
 	dev_info(&dev->dev, "disabling bridge mem windows\n");
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8d..b59ad4b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1085,6 +1085,7 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge);
 void pci_assign_unassigned_bus_resources(struct pci_bus *bus);
 void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus);
 void pdev_enable_device(struct pci_dev *);
+void pci_claim_one_bus(struct pci_bus *b);
 int pci_enable_resources(struct pci_dev *, int mask);
 void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
 		    int (*)(const struct pci_dev *, u8, u8));
-------- END PATCH ----

Thanks,

Suravee

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux