Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1227464 > unrolled thread

[PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs. David Daney <ddaney.cavm@gmail.com> - 2015-09-18 00:50 +0200
    Re: [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs. Arnd Bergmann <arnd@arndb.de> - 2015-09-18 09:30 +0200
      Re: [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs. Arnd Bergmann <arnd@arndb.de> - 2015-09-18 21:50 +0200

#1227464 — [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs.

From: David Daney <david.daney@cavium.com>

The on-chip devices all have fixed bars.  So, fix them up.

Signed-off-by: David Daney <david.daney@cavium.com>
---
 drivers/pci/host/Kconfig          |  6 +++
 drivers/pci/host/Makefile         |  1 +
 drivers/pci/host/quirks-thunder.c | 95 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+)
 create mode 100644 drivers/pci/host/quirks-thunder.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..20d700d 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,10 @@ config PCIE_IPROC_BCMA
 	  Say Y here if you want to use the Broadcom iProc PCIe controller
 	  through the BCMA bus interface
 
+config PCI_QUIRKS_THUNDER
+	bool "PCI quirks for Cavium ThunderX SoCs"
+	depends on ARM64
+	help
+	  Say Y here to support ThunderX SoCs
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..3ce7456 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
 obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCI_QUIRKS_THUNDER) += quirks-thunder.o
diff --git a/drivers/pci/host/quirks-thunder.c b/drivers/pci/host/quirks-thunder.c
new file mode 100644
index 0000000..d615fd8
--- /dev/null
+++ b/drivers/pci/host/quirks-thunder.c
@@ -0,0 +1,95 @@
+/*
+ * PCIe quirks for Cavium Thunder SOC
+ *
+ * Copyright (C) 2014, 2015 Cavium Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/pci.h>
+
+#define PCI_DEVICE_ID_THUNDER_BRIDGE		0xa002
+
+/*
+ * All PCIe devices in Thunder have fixed resources, shouldn't be
+ * reassigned.
+ */
+static void thunder_pci_fixup_header(struct pci_dev *dev)
+{
+	int resno;
+
+	/* Only fixup Thunder on-chip devices. */
+	if ((dev->device & 0xff00) != 0xa000)
+		return;
+
+	for (resno = 0; resno < PCI_NUM_RESOURCES; resno++)
+		if (dev->resource[resno].flags)
+			dev->resource[resno].flags |= IORESOURCE_PCI_FIXED;
+#ifdef CONFIG_PCI_IOV
+	if (dev->device == 0xa01e) {
+		dev->resource[PCI_IOV_RESOURCES + 0] = dev->resource[0];
+		dev->resource[PCI_IOV_RESOURCES + 0].start += 0xa0000000;
+		dev->resource[PCI_IOV_RESOURCES + 0].end =
+			dev->resource[PCI_IOV_RESOURCES + 0].start + 0x200000 - 1;
+		dev->resource[PCI_IOV_RESOURCES + 4] = dev->resource[0];
+		dev->resource[PCI_IOV_RESOURCES + 4].start += 0xe0000000;
+		dev->resource[PCI_IOV_RESOURCES + 4].end =
+			dev->resource[PCI_IOV_RESOURCES + 4].start + 0x200000 - 1;
+	}
+#endif
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, thunder_pci_fixup_header);
+
+static void thunder_pci_fixup_final(struct pci_dev *dev)
+{
+	struct resource *res;
+	int resno;
+
+	/* Only fixup Thunder on-chip devices. */
+	if ((dev->device & 0xff00) != 0xa000)
+		return;
+
+	if (dev->device == PCI_DEVICE_ID_THUNDER_BRIDGE) {
+		/*
+		 * This bridge is just for the sake of supporting ARI
+		 * for downstream devices. No resources are attached
+		 * to it.  Copy upstream root bus resources to bridge
+		 * which aide in resource claiming for downstream
+		 * devices
+		 */
+
+		struct pci_bus *bus;
+		int resno;
+
+		bus = dev->subordinate;
+		for (resno = 0; resno < PCI_BRIDGE_RESOURCE_NUM; resno++) {
+			bus->resource[resno] = pci_bus_resource_n(bus->parent,
+								  PCI_BRIDGE_RESOURCE_NUM + resno);
+		}
+
+		for (resno = PCI_BRIDGE_RESOURCES;
+		     resno <= PCI_BRIDGE_RESOURCE_END; resno++) {
+			dev->resource[resno].start = dev->resource[resno].end = 0;
+			dev->resource[resno].flags = 0;
+		}
+	} else {
+		/*
+		 * Claim the device's valid resources to set
+		 * 'res->parent' hierarchy.
+		 */
+		for (resno = 0; resno < PCI_BRIDGE_RESOURCES; resno++) {
+			res = &dev->resource[resno];
+			if (res->parent || !(res->flags & IORESOURCE_MEM))
+				continue;
+			pci_claim_resource(dev, resno);
+		}
+	}
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, thunder_pci_fixup_final);
+
+MODULE_DESCRIPTION("PCI quirks for Cavium Thunder ECAM based devices");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1227613

On Thursday 17 September 2015 15:41:33 David Daney wrote:
> From: David Daney <david.daney@cavium.com>
> 
> The on-chip devices all have fixed bars.  So, fix them up.
> 
> Signed-off-by: David Daney <david.daney@cavium.com>
> 

You should be able to just mark the BARs as fixed in DT and not need
this hack. If that doesn't work with current kernels, it would be
better to fix the kernel to respect the flags.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228250

On Friday 18 September 2015 10:00:32 David Daney wrote:
> On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
> > On Thursday 17 September 2015 15:41:33 David Daney wrote:
> >> From: David Daney <david.daney@cavium.com>
> >>
> >> The on-chip devices all have fixed bars.  So, fix them up.
> >>
> >> Signed-off-by: David Daney <david.daney@cavium.com>
> >>
> >
> > You should be able to just mark the BARs as fixed in DT
> 
> In the case of ACPI, there is no DT.  So we would need a different 
> solution for ACPI.  What would you recommend for ACPI?

I would expect that this does not matter at all on ACPI, because
the devices that need it are not hot-plugged, and all boot-time
devices are probed by the firmware: the ACPI PCI implementation
does not reassign any BARs, except for the hotplug case.

> Also, can you point me to the OF device tree specification where it 
> tells how to specify PCI BAR addresses, I would especially be interested 
> in knowing how to specify fixed SRIOV BAR addresses in the device tree.

This is the 'n' bit mentioned sections 2.1.3 and 2.2.1.1 of the
PCI binding. When it is set, the OS is not supposed to try to
reassign the BAR even on machines that otherwise do a complete
rescan.

The PCI binding traditionally requires you to list all PCI devices
in DT, Linux as an extension (for the flattened DT format) allows
leaving out the devices, but in this case you probably need to
list every device that has a fixed BAR.

> Yes, it is a bit of a hack.  That is why I put it in its own file, and 
> only try to hack up PCI devices that exactly match the vendor and device 
> ids that need fixing.
> 
> IMHO, putting infrastructure into drivers/pci/probe.c, et al. to handle 
> this would be much more intrusive.

My guess is that it's already there, but even if it's not, this is a
generic well-defined case that has a standardized binding, and we should
implement that.

> For the record:  The PCI Enhanced Allocation (EA) capability (approved 
> by PCI SIG on 23 October 2014) is the proper way to handle this going 
> forward.  However, this is not yet implemented in the SoCs that this 
> patch addresses.  Our plan is to implement the EA capability in the core 
> PCI code, so that we do not need to keep adding devices to this fixup code.

Good, but still this should only be required for the embedded case where
you don't have a firmware to probe the bus.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web