Skip to contentSkip to conversation

bcma: support for PCIe Gen 2 as host platform

PATCH New Rafał Miłecki 3 participants 5 messages Jul 6, 2014 – Jul 7, 2014 Broadcom specific amba driver (bcma)

lore
Share & tools
lore

Rafał Miłecki

author maintainer
#0 lore raw

PATCH 1/1 bcma: support for PCIe Gen 2 as host platform

---
I got reply from Bjorn, that we should *not* depend on PCI_EXP_LNKCAP:
http://marc.info/?l=linux-pci&m=140457671930896&w=2

So the change since RFC is adding a list of PCIe 1.0 and 2.0 devices. Use PCI_EXP_LNKCAP only as a fallback, in case someone tries sth like:
echo "14e4 4360" > /sys/bus/pci/drivers/bcma-pci-bridge/new_id

---
 drivers/bcma/host_pci.c        | 32 ++++++++++++++++++++++++++++++--
 include/linux/bcma/bcma.h      |  1 +
 include/linux/bcma/bcma_regs.h |  2 ++
 3 files changed, 33 insertions(+), 2 deletions(-)
drivers/bcma/host_pci.c +30 -2
index e3333053..df20a50 100644
@@ -13,10 +13,12 @@
 
 static void bcma_host_pci_switch_core(struct bcma_device *core)
 {
+	int win2 = core->bus->host_is_pcie2 ?
+		BCMA_PCIE2_BAR0_WIN2 : BCMA_PCI_BAR0_WIN2;
+
 	pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN,
 			       core->addr);
-	pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN2,
-			       core->wrap);
+	pci_write_config_dword(core->bus->host_pci, win2, core->wrap);
 	core->bus->mapped_core = core;
 	bcma_debug(core->bus, "Switched to core: 0x%X\n", core->id.id);
 }
@@ -194,6 +196,32 @@ static int bcma_host_pci_probe(struct pci_dev *dev,
 		goto err_pci_release_regions;
 	}
 
+	/* PCIe Gen 2 has some regs different */
+	switch (dev->device) {
+	case 0x0576:
+	case 0x4313:
+	case 43224:
+	case 0x4331:
+	case 0x4353:
+	case 0x4357:
+	case 0x4358:
+	case 0x4359:
+	case 0x4365:
+	case 0x4727:
+		bus->host_is_pcie2 = false;
+		break;
+	case 0x4360:
+	case 0x43a0:
+	case 0x43b1:
+		bus->host_is_pcie2 = true;
+		break;
+	default:
+		/* Fallback, e.g. if someone uses bcma-pci-bridge/new_id */
+		pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &val);
+		bus->host_is_pcie2 = !!(val & PCI_EXP_LNKCAP_SLS_5_0GB);
+		break;
+	}
+
 	/* Map MMIO */
 	err = -ENOMEM;
 	bus->mmio = pci_iomap(dev, 0, ~0UL);
include/linux/bcma/bcma.h +1 -0
index 452286a..9f98e2f 100644
@@ -315,6 +315,7 @@ struct bcma_bus {
 	const struct bcma_host_ops *ops;
 
 	enum bcma_hosttype hosttype;
+	bool host_is_pcie2; /* Valid for BCMA_HOSTTYPE_PCI only */
 	union {
 		/* Pointer to the PCI bus (only for BCMA_HOSTTYPE_PCI) */
 		struct pci_dev *host_pci;
include/linux/bcma/bcma_regs.h +2 -0
index 917dcd7..d02f8b5 100644
@@ -59,6 +59,8 @@
 #define  BCMA_PCI_GPIO_XTAL		0x40	/* PCI config space GPIO 14 for Xtal powerup */
 #define  BCMA_PCI_GPIO_PLL		0x80	/* PCI config space GPIO 15 for PLL powerdown */
 
+#define BCMA_PCIE2_BAR0_WIN2		0x70
+
 /* SiliconBackplane Address Map.
  * All regions may not exist on all chips.
  */
Signature · 1 line
1.8.4.5
#1 lore raw

PATCH 1/1 bcma: support for PCIe Gen 2 as host platform

Quoted 8 lines · Rafa? Mi?ecki

---
I got reply from Bjorn, that we should *not* depend on PCI_EXP_LNKCAP:
http://marc.info/?l=linux-pci&m=140457671930896&w=2

So the change since RFC is adding a list of PCIe 1.0 and 2.0 devices. Use PCI_EXP_LNKCAP only as a fallback, in case someone tries sth like:
echo "14e4 4360" > /sys/bus/pci/drivers/bcma-pci-bridge/new_id

Do you have to know this before or after enumerating the cores? They have a different core id, right?

Regards,
Arend

Quoted 84 lines
---
 drivers/bcma/host_pci.c        | 32 ++++++++++++++++++++++++++++++--
 include/linux/bcma/bcma.h      |  1 +
 include/linux/bcma/bcma_regs.h |  2 ++
 3 files changed, 33 insertions(+), 2 deletions(-)
drivers/bcma/host_pci.c +30 -2
index e3333053..df20a50 100644
@@ -13,10 +13,12 @@
 
 static void bcma_host_pci_switch_core(struct bcma_device *core)
 {
+	int win2 = core->bus->host_is_pcie2 ?
+		BCMA_PCIE2_BAR0_WIN2 : BCMA_PCI_BAR0_WIN2;
+
 	pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN,
 			       core->addr);
-	pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN2,
-			       core->wrap);
+	pci_write_config_dword(core->bus->host_pci, win2, core->wrap);
 	core->bus->mapped_core = core;
 	bcma_debug(core->bus, "Switched to core: 0x%X\n", core->id.id);
 }
@@ -194,6 +196,32 @@ static int bcma_host_pci_probe(struct pci_dev *dev,
 		goto err_pci_release_regions;
 	}
 
+	/* PCIe Gen 2 has some regs different */
+	switch (dev->device) {
+	case 0x0576:
+	case 0x4313:
+	case 43224:
+	case 0x4331:
+	case 0x4353:
+	case 0x4357:
+	case 0x4358:
+	case 0x4359:
+	case 0x4365:
+	case 0x4727:
+		bus->host_is_pcie2 = false;
+		break;
+	case 0x4360:
+	case 0x43a0:
+	case 0x43b1:
+		bus->host_is_pcie2 = true;
+		break;
+	default:
+		/* Fallback, e.g. if someone uses bcma-pci-bridge/new_id */
+		pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &val);
+		bus->host_is_pcie2 = !!(val & PCI_EXP_LNKCAP_SLS_5_0GB);
+		break;
+	}
+
 	/* Map MMIO */
 	err = -ENOMEM;
 	bus->mmio = pci_iomap(dev, 0, ~0UL);
include/linux/bcma/bcma.h +1 -0
index 452286a..9f98e2f 100644
@@ -315,6 +315,7 @@ struct bcma_bus {
 	const struct bcma_host_ops *ops;
 
 	enum bcma_hosttype hosttype;
+	bool host_is_pcie2; /* Valid for BCMA_HOSTTYPE_PCI only */
 	union {
 		/* Pointer to the PCI bus (only for BCMA_HOSTTYPE_PCI) */
 		struct pci_dev *host_pci;
include/linux/bcma/bcma_regs.h +2 -0
index 917dcd7..d02f8b5 100644
@@ -59,6 +59,8 @@
 #define  BCMA_PCI_GPIO_XTAL		0x40	/* PCI config space GPIO 14 for Xtal powerup */
 #define  BCMA_PCI_GPIO_PLL		0x80	/* PCI config space GPIO 15 for PLL powerdown */
 
+#define BCMA_PCIE2_BAR0_WIN2		0x70
+
 /* SiliconBackplane Address Map.
  * All regions may not exist on all chips.
  */
author maintainer
#2 lore raw

PATCH 1/1 bcma: support for PCIe Gen 2 as host platform

Quoted 6 lines · Arend van Spriel
Quoted 5 lines · Rafa? Mi?ecki

---
I got reply from Bjorn, that we should *not* depend on PCI_EXP_LNKCAP:
http://marc.info/?l=linux-pci&m=140457671930896&w=2

Quoted 6 lines
Quoted 3 lines

So the change since RFC is adding a list of PCIe 1.0 and 2.0 devices. Use PCI_EXP_LNKCAP only as a fallback, in case someone tries sth like:
echo "14e4 4360" > /sys/bus/pci/drivers/bcma-pci-bridge/new_id

Do you have to know this before or after enumerating the cores? They have a different core id, right?

Sure, having a list of cores would allow me to determine PCIe revision.

Unfortunately right now we have only this single bcma_bus_register call that does both: scanning and initialization. I'd need to first scan cores, then determine PCIe revision and finally initialize cores.

I wonder if I could try to use bcma_bus_scan_early that was developer for SoC needs...

author maintainer
#3 lore raw

PATCH 1/1 bcma: support for PCIe Gen 2 as host platform

Quoted 14 lines · Rafa? Mi?ecki
Quoted 6 lines · Arend van Spriel
Quoted 5 lines · Rafa? Mi?ecki

---
I got reply from Bjorn, that we should *not* depend on PCI_EXP_LNKCAP:
http://marc.info/?l=linux-pci&m=140457671930896&w=2

Quoted 6 lines
Quoted 3 lines

So the change since RFC is adding a list of PCIe 1.0 and 2.0 devices. Use PCI_EXP_LNKCAP only as a fallback, in case someone tries sth like:
echo "14e4 4360" > /sys/bus/pci/drivers/bcma-pci-bridge/new_id

Do you have to know this before or after enumerating the cores? They have a different core id, right?

Quoted 8 lines

Sure, having a list of cores would allow me to determine PCIe revision.

Unfortunately right now we have only this single bcma_bus_register call that does both: scanning and initialization. I'd need to first scan cores, then determine PCIe revision and finally initialize cores.

I wonder if I could try to use bcma_bus_scan_early that was developer for SoC needs...

John: please kindly drop this patch for now. All other bcma/b43 patches are unaffected.

Signature · 1 line
Rafa?
#4 lore raw

PATCH 1/1 bcma: support for PCIe Gen 2 as host platform

Quoted 21 lines · Rafa? Mi?ecki
Quoted 20 lines · Rafa? Mi?ecki
Quoted 6 lines · Arend van Spriel
Quoted 5 lines · Rafa? Mi?ecki

---
I got reply from Bjorn, that we should *not* depend on PCI_EXP_LNKCAP:
http://marc.info/?l=linux-pci&m=140457671930896&w=2

Quoted 6 lines
Quoted 3 lines

So the change since RFC is adding a list of PCIe 1.0 and 2.0 devices. Use PCI_EXP_LNKCAP only as a fallback, in case someone tries sth like:
echo "14e4 4360" > /sys/bus/pci/drivers/bcma-pci-bridge/new_id

Do you have to know this before or after enumerating the cores? They have a different core id, right?

Sure, having a list of cores would allow me to determine PCIe revision.

Unfortunately right now we have only this single bcma_bus_register call that does both: scanning and initialization. I'd need to first scan cores, then determine PCIe revision and finally initialize cores.

Quoted 5 lines
Quoted 2 lines

I wonder if I could try to use bcma_bus_scan_early that was developer for SoC needs...

John: please kindly drop this patch for now. All other bcma/b43 patches are unaffected.

OK

Signature · 2 lines
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.