* PCI: brcmstb: Add Broadcom Settopbox PCIe support
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris
This patch series adds support for the Broadcom Settopbox PCIe host
controller. It is targeted to Broadcom Settopbox chips running on ARM,
ARM64, and MIPS platforms. As the HW of the controller is intimately
tied to the memory subsystem, there are some patches required that are
not typical of a PCIe host controller driver.
pci-brcmstb.c -- is the core functionality of the RC driver.
pci-brcmstb-msi.c -- provides the driver for the PCIe's built-in
MSI controller.
pci-brcmstb-dma.c -- provides the non-standard mapping between
system memory and the PCIe address space.
drivers/soc/bcm/brcmstb/memory.c -- provides a single call to inform
the PCIe controller about the size of populated memory in
the memory controllers.
^ permalink raw reply [flat|nested] 146+ messages in thread
* PCI: brcmstb: Add Broadcom Settopbox PCIe support
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
This patch series adds support for the Broadcom Settopbox PCIe host
controller. It is targeted to Broadcom Settopbox chips running on ARM,
ARM64, and MIPS platforms. As the HW of the controller is intimately
tied to the memory subsystem, there are some patches required that are
not typical of a PCIe host controller driver.
pci-brcmstb.c -- is the core functionality of the RC driver.
pci-brcmstb-msi.c -- provides the driver for the PCIe's built-in
MSI controller.
pci-brcmstb-dma.c -- provides the non-standard mapping between
system memory and the PCIe address space.
drivers/soc/bcm/brcmstb/memory.c -- provides a single call to inform
the PCIe controller about the size of populated memory in
the memory controllers.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* PCI: brcmstb: Add Broadcom Settopbox PCIe support
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the Broadcom Settopbox PCIe host
controller. It is targeted to Broadcom Settopbox chips running on ARM,
ARM64, and MIPS platforms. As the HW of the controller is intimately
tied to the memory subsystem, there are some patches required that are
not typical of a PCIe host controller driver.
pci-brcmstb.c -- is the core functionality of the RC driver.
pci-brcmstb-msi.c -- provides the driver for the PCIe's built-in
MSI controller.
pci-brcmstb-dma.c -- provides the non-standard mapping between
system memory and the PCIe address space.
drivers/soc/bcm/brcmstb/memory.c -- provides a single call to inform
the PCIe controller about the size of populated memory in
the memory controllers.
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
2017-10-11 22:34 ` Jim Quinlan
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
From: Florian Fainelli <f.fainelli@gmail.com>
This commit adds a memory API suitable for ascertaining the sizes of
each of the N memory controllers in a Broadcom STB chip. Its first
user will be the Broadcom STB PCIe root complex driver, which needs
to know these sizes to properly set up DMA mappings for inbound
regions.
We cannot use memblock here or anything like what Linux provides
because it collapses adjacent regions within a larger block, and here
we actually need per-memory controller addresses and sizes, which is
why we resort to manual DT parsing.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/soc/bcm/brcmstb/Makefile | 2 +-
drivers/soc/bcm/brcmstb/memory.c | 183 +++++++++++++++++++++++++++++++++++++++
include/soc/brcmstb/memory_api.h | 25 ++++++
3 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/bcm/brcmstb/memory.c
create mode 100644 include/soc/brcmstb/memory_api.h
diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
index 9120b27..4cea7b6 100644
--- a/drivers/soc/bcm/brcmstb/Makefile
+++ b/drivers/soc/bcm/brcmstb/Makefile
@@ -1 +1 @@
-obj-y += common.o biuctrl.o
+obj-y += common.o biuctrl.o memory.o
diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
new file mode 100644
index 0000000..cb6bf73
--- /dev/null
+++ b/drivers/soc/bcm/brcmstb/memory.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright © 2015-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * A copy of the GPL is available at
+ * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
+ * Foundation at https://www.gnu.org/licenses/ .
+ */
+
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/libfdt.h>
+#include <linux/of_address.h>
+#include <linux/of_fdt.h>
+#include <linux/sizes.h>
+#include <soc/brcmstb/memory_api.h>
+
+/* -------------------- Constants -------------------- */
+
+/* Macros to help extract property data */
+#define U8TOU32(b, offs) \
+ ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
+ (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
+ (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
+ (((u32)b[3 + offs] << 24) & 0xff000000))
+
+#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
+
+/* Constants used when retrieving memc info */
+#define NUM_BUS_RANGES 10
+#define BUS_RANGE_ULIMIT_SHIFT 4
+#define BUS_RANGE_LLIMIT_SHIFT 4
+#define BUS_RANGE_PA_SHIFT 12
+
+enum {
+ BUSNUM_MCP0 = 0x4,
+ BUSNUM_MCP1 = 0x5,
+ BUSNUM_MCP2 = 0x6,
+};
+
+/* -------------------- Functions -------------------- */
+
+/*
+ * If the DT nodes are handy, determine which MEMC holds the specified
+ * physical address.
+ */
+#ifdef CONFIG_ARCH_BRCMSTB
+int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
+{
+ int memc = -1;
+ int i;
+
+ for (i = 0; i < NUM_BUS_RANGES; i++, base += 8) {
+ const u64 ulimit_raw = readl(base);
+ const u64 llimit_raw = readl(base + 4);
+ const u64 ulimit =
+ ((ulimit_raw >> BUS_RANGE_ULIMIT_SHIFT)
+ << BUS_RANGE_PA_SHIFT) | 0xfff;
+ const u64 llimit = (llimit_raw >> BUS_RANGE_LLIMIT_SHIFT)
+ << BUS_RANGE_PA_SHIFT;
+ const u32 busnum = (u32)(ulimit_raw & 0xf);
+
+ if (pa >= llimit && pa <= ulimit) {
+ if (busnum >= BUSNUM_MCP0 && busnum <= BUSNUM_MCP2) {
+ memc = busnum - BUSNUM_MCP0;
+ break;
+ }
+ }
+ }
+
+ return memc;
+}
+
+int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
+{
+ int memc = -1;
+ struct device_node *np;
+ void __iomem *cpubiuctrl;
+
+ np = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
+ if (!np)
+ return memc;
+
+ cpubiuctrl = of_iomap(np, 0);
+ if (!cpubiuctrl)
+ goto cleanup;
+
+ memc = __brcmstb_memory_phys_addr_to_memc(pa, cpubiuctrl);
+ iounmap(cpubiuctrl);
+
+cleanup:
+ of_node_put(np);
+
+ return memc;
+}
+
+#elif defined(CONFIG_MIPS)
+int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
+{
+ /* The logic here is fairly simple and hardcoded: if pa <= 0x5000_0000,
+ * then this is MEMC0, else MEMC1.
+ *
+ * For systems with 2GB on MEMC0, MEMC1 starts at 9000_0000, with 1GB
+ * on MEMC0, MEMC1 starts at 6000_0000.
+ */
+ if (pa >= 0x50000000ULL)
+ return 1;
+ else
+ return 0;
+}
+#endif
+EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
+
+u64 brcmstb_memory_memc_size(int memc)
+{
+ const void *fdt = initial_boot_params;
+ const int mem_offset = fdt_path_offset(fdt, "/memory");
+ int addr_cells = 1, size_cells = 1;
+ const struct fdt_property *prop;
+ int proplen, cellslen;
+ u64 memc_size = 0;
+ int i;
+
+ /* Get root size and address cells if specified */
+ prop = fdt_get_property(fdt, 0, "#size-cells", &proplen);
+ if (prop)
+ size_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
+
+ prop = fdt_get_property(fdt, 0, "#address-cells", &proplen);
+ if (prop)
+ addr_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
+
+ if (mem_offset < 0)
+ return -1;
+
+ prop = fdt_get_property(fdt, mem_offset, "reg", &proplen);
+ cellslen = (int)sizeof(u32) * (addr_cells + size_cells);
+ if ((proplen % cellslen) != 0)
+ return -1;
+
+ for (i = 0; i < proplen / cellslen; ++i) {
+ u64 addr = 0;
+ u64 size = 0;
+ int memc_idx;
+ int j;
+
+ for (j = 0; j < addr_cells; ++j) {
+ int offset = (cellslen * i) + (sizeof(u32) * j);
+
+ addr |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
+ ((addr_cells - j - 1) * 32);
+ }
+ for (j = 0; j < size_cells; ++j) {
+ int offset = (cellslen * i) +
+ (sizeof(u32) * (j + addr_cells));
+
+ size |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
+ ((size_cells - j - 1) * 32);
+ }
+
+ if ((phys_addr_t)addr != addr) {
+ pr_err("phys_addr_t is smaller than provided address 0x%llx!\n",
+ addr);
+ return -1;
+ }
+
+ memc_idx = brcmstb_memory_phys_addr_to_memc((phys_addr_t)addr);
+ if (memc_idx == memc)
+ memc_size += size;
+ }
+
+ return memc_size;
+}
+EXPORT_SYMBOL(brcmstb_memory_memc_size);
+
diff --git a/include/soc/brcmstb/memory_api.h b/include/soc/brcmstb/memory_api.h
new file mode 100644
index 0000000..d922906
--- /dev/null
+++ b/include/soc/brcmstb/memory_api.h
@@ -0,0 +1,25 @@
+#ifndef __MEMORY_API_H
+#define __MEMORY_API_H
+
+/*
+ * Bus Interface Unit control register setup, must happen early during boot,
+ * before SMP is brought up, called by machine entry point.
+ */
+void brcmstb_biuctrl_init(void);
+
+#ifdef CONFIG_SOC_BRCMSTB
+int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa);
+u64 brcmstb_memory_memc_size(int memc);
+#else
+static inline int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
+{
+ return -EINVAL;
+}
+
+static inline u64 brcmstb_memory_memc_size(int memc)
+{
+ return -1;
+}
+#endif
+
+#endif /* __MEMORY_API_H */
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Florian Fainelli <f.fainelli@gmail.com>
This commit adds a memory API suitable for ascertaining the sizes of
each of the N memory controllers in a Broadcom STB chip. Its first
user will be the Broadcom STB PCIe root complex driver, which needs
to know these sizes to properly set up DMA mappings for inbound
regions.
We cannot use memblock here or anything like what Linux provides
because it collapses adjacent regions within a larger block, and here
we actually need per-memory controller addresses and sizes, which is
why we resort to manual DT parsing.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/soc/bcm/brcmstb/Makefile | 2 +-
drivers/soc/bcm/brcmstb/memory.c | 183 +++++++++++++++++++++++++++++++++++++++
include/soc/brcmstb/memory_api.h | 25 ++++++
3 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/bcm/brcmstb/memory.c
create mode 100644 include/soc/brcmstb/memory_api.h
diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
index 9120b27..4cea7b6 100644
--- a/drivers/soc/bcm/brcmstb/Makefile
+++ b/drivers/soc/bcm/brcmstb/Makefile
@@ -1 +1 @@
-obj-y += common.o biuctrl.o
+obj-y += common.o biuctrl.o memory.o
diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
new file mode 100644
index 0000000..cb6bf73
--- /dev/null
+++ b/drivers/soc/bcm/brcmstb/memory.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright ? 2015-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * A copy of the GPL is available at
+ * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
+ * Foundation at https://www.gnu.org/licenses/ .
+ */
+
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/libfdt.h>
+#include <linux/of_address.h>
+#include <linux/of_fdt.h>
+#include <linux/sizes.h>
+#include <soc/brcmstb/memory_api.h>
+
+/* -------------------- Constants -------------------- */
+
+/* Macros to help extract property data */
+#define U8TOU32(b, offs) \
+ ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
+ (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
+ (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
+ (((u32)b[3 + offs] << 24) & 0xff000000))
+
+#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
+
+/* Constants used when retrieving memc info */
+#define NUM_BUS_RANGES 10
+#define BUS_RANGE_ULIMIT_SHIFT 4
+#define BUS_RANGE_LLIMIT_SHIFT 4
+#define BUS_RANGE_PA_SHIFT 12
+
+enum {
+ BUSNUM_MCP0 = 0x4,
+ BUSNUM_MCP1 = 0x5,
+ BUSNUM_MCP2 = 0x6,
+};
+
+/* -------------------- Functions -------------------- */
+
+/*
+ * If the DT nodes are handy, determine which MEMC holds the specified
+ * physical address.
+ */
+#ifdef CONFIG_ARCH_BRCMSTB
+int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
+{
+ int memc = -1;
+ int i;
+
+ for (i = 0; i < NUM_BUS_RANGES; i++, base += 8) {
+ const u64 ulimit_raw = readl(base);
+ const u64 llimit_raw = readl(base + 4);
+ const u64 ulimit =
+ ((ulimit_raw >> BUS_RANGE_ULIMIT_SHIFT)
+ << BUS_RANGE_PA_SHIFT) | 0xfff;
+ const u64 llimit = (llimit_raw >> BUS_RANGE_LLIMIT_SHIFT)
+ << BUS_RANGE_PA_SHIFT;
+ const u32 busnum = (u32)(ulimit_raw & 0xf);
+
+ if (pa >= llimit && pa <= ulimit) {
+ if (busnum >= BUSNUM_MCP0 && busnum <= BUSNUM_MCP2) {
+ memc = busnum - BUSNUM_MCP0;
+ break;
+ }
+ }
+ }
+
+ return memc;
+}
+
+int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
+{
+ int memc = -1;
+ struct device_node *np;
+ void __iomem *cpubiuctrl;
+
+ np = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
+ if (!np)
+ return memc;
+
+ cpubiuctrl = of_iomap(np, 0);
+ if (!cpubiuctrl)
+ goto cleanup;
+
+ memc = __brcmstb_memory_phys_addr_to_memc(pa, cpubiuctrl);
+ iounmap(cpubiuctrl);
+
+cleanup:
+ of_node_put(np);
+
+ return memc;
+}
+
+#elif defined(CONFIG_MIPS)
+int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
+{
+ /* The logic here is fairly simple and hardcoded: if pa <= 0x5000_0000,
+ * then this is MEMC0, else MEMC1.
+ *
+ * For systems with 2GB on MEMC0, MEMC1 starts at 9000_0000, with 1GB
+ * on MEMC0, MEMC1 starts@6000_0000.
+ */
+ if (pa >= 0x50000000ULL)
+ return 1;
+ else
+ return 0;
+}
+#endif
+EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
+
+u64 brcmstb_memory_memc_size(int memc)
+{
+ const void *fdt = initial_boot_params;
+ const int mem_offset = fdt_path_offset(fdt, "/memory");
+ int addr_cells = 1, size_cells = 1;
+ const struct fdt_property *prop;
+ int proplen, cellslen;
+ u64 memc_size = 0;
+ int i;
+
+ /* Get root size and address cells if specified */
+ prop = fdt_get_property(fdt, 0, "#size-cells", &proplen);
+ if (prop)
+ size_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
+
+ prop = fdt_get_property(fdt, 0, "#address-cells", &proplen);
+ if (prop)
+ addr_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
+
+ if (mem_offset < 0)
+ return -1;
+
+ prop = fdt_get_property(fdt, mem_offset, "reg", &proplen);
+ cellslen = (int)sizeof(u32) * (addr_cells + size_cells);
+ if ((proplen % cellslen) != 0)
+ return -1;
+
+ for (i = 0; i < proplen / cellslen; ++i) {
+ u64 addr = 0;
+ u64 size = 0;
+ int memc_idx;
+ int j;
+
+ for (j = 0; j < addr_cells; ++j) {
+ int offset = (cellslen * i) + (sizeof(u32) * j);
+
+ addr |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
+ ((addr_cells - j - 1) * 32);
+ }
+ for (j = 0; j < size_cells; ++j) {
+ int offset = (cellslen * i) +
+ (sizeof(u32) * (j + addr_cells));
+
+ size |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
+ ((size_cells - j - 1) * 32);
+ }
+
+ if ((phys_addr_t)addr != addr) {
+ pr_err("phys_addr_t is smaller than provided address 0x%llx!\n",
+ addr);
+ return -1;
+ }
+
+ memc_idx = brcmstb_memory_phys_addr_to_memc((phys_addr_t)addr);
+ if (memc_idx == memc)
+ memc_size += size;
+ }
+
+ return memc_size;
+}
+EXPORT_SYMBOL(brcmstb_memory_memc_size);
+
diff --git a/include/soc/brcmstb/memory_api.h b/include/soc/brcmstb/memory_api.h
new file mode 100644
index 0000000..d922906
--- /dev/null
+++ b/include/soc/brcmstb/memory_api.h
@@ -0,0 +1,25 @@
+#ifndef __MEMORY_API_H
+#define __MEMORY_API_H
+
+/*
+ * Bus Interface Unit control register setup, must happen early during boot,
+ * before SMP is brought up, called by machine entry point.
+ */
+void brcmstb_biuctrl_init(void);
+
+#ifdef CONFIG_SOC_BRCMSTB
+int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa);
+u64 brcmstb_memory_memc_size(int memc);
+#else
+static inline int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
+{
+ return -EINVAL;
+}
+
+static inline u64 brcmstb_memory_memc_size(int memc)
+{
+ return -1;
+}
+#endif
+
+#endif /* __MEMORY_API_H */
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
2017-10-11 22:34 ` Jim Quinlan
(?)
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
The DT bindings description of the Brcmstb PCIe device is described. This
node can be used by almost all Broadcom settop box chips, using
ARM, ARM64, or MIPS CPU architectures.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
.../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
new file mode 100644
index 0000000..2f699da
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
@@ -0,0 +1,106 @@
+Brcmstb PCIe Host Controller Device Tree Bindings
+
+Introduction:
+ The brcmstb host controller closely follows the example set in
+
+ [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
+
+ The rest of this document explains some added customizations and
+ offers an example Brcmstb PCIe host controller DT node.
+
+Required Properties:
+ reg -- the register start address and length for the PCIe block.
+ Additional start,length pairs may be specified for clock addresses.
+ interrupts -- two interrupts are specified; the first interrupt is for
+ the PCI host controller and the second is for MSI if the built-in
+ MSI controller is to be used.
+ interrupt-names -- names of the interrupts (above): "pcie" and "msi".
+ compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
+ or "brcm,bcm7278-pcie".
+ #address-cells -- the number of address cells for PCI-space.
+ #size-cells -- the number of size cells for PCI-space.
+ ranges -- See [1]; a specification of the outbound windows for the host
+ controller. Each outbound window is described by a n-tuple:
+ (3 cells) -- PCIe space start address; one cell for attributes
+ and two cells for the 64-bit PCIe address.
+ (x cells) -- CPU/System start address, number of cells is determined
+ by the parent node's #address-cells.
+ (y cells) -- Size of region, number of cells determined by the
+ parent node's #size-cells.
+ Due to hardware limitations, there may be a maximum of four
+ non-contiguous ranges specified.
+ #interrupt-cells -- number of cells used to describe the interrupt.
+ interrupt-map-mask -- see [1]; four cells, the first three are zero
+ for our uses and the fourth cell is the mask (val = 0x7) for
+ the legacy interrupt number [1..4].
+ interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
+ INTC, and INTD) to be mapped; each interrupt requires 5 cells
+ plus the size of the interrupt specifier.
+ linux,pci-domain -- the domain of the host controller.
+
+Optional Properties:
+ clocks -- list of clock phandles. If specified, this should list one
+ clock.
+ clock-names -- the "local" names of the clocks specified in 'clocks'. Note
+ that if the 'clocks' property is given, 'clock-names' is mandatory,
+ and the name of the clock is expected to be "sw_pcie".
+ dma-ranges -- Similar in structure to ranges, each dma region is
+ specified with a n-tuple. Dma-regions describe the inbound
+ accesses from EP to RC; it translates the pci address that the
+ EP "sees" to the CPU address in memory. This property is needed
+ because the design of the Brcmstb memory subsystem often precludes
+ idenity-mapping between CPU address space and PCIe address space.
+ Each range is described by a n-tuple:
+ (3 cells) -- PCIe space start address; one cell for attributes
+ and two cells for the 64-bit PCIe address.
+ (x cells) -- CPU/System start address, number of cells is determined
+ by the parent node's #address-cells.
+ (y cells) -- Size of region, number of cells determined by the
+ parent node's #size-cells.
+ msi-parent -- if MSI is to be used, this must be a phandle to the
+ msi-parent. If this prop is set to the phandle of the PCIe
+ node, or if the msi-parent prop is missing, the PCIE controller
+ will attempt to use its built in MSI controller.
+ msi-controller -- this property should only be specified if the
+ PCIe controller is using its internal MSI controller.
+ brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
+ brcm,gen -- (integer) indicates desired generation of link:
+ 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
+ supply-names -- the names of voltage regulators that the root
+ complex should turn off/on/on on suspend/resume/boot. This
+ is a string list.
+ supplies -- A collection of phandles to a regulator nodes, see
+ Documentation/devicetree/bindings/regulator/ for specific
+ bindings. The number and order of phandles must match
+ exactly the number of strings in the "supply-names" property.
+
+Example Node:
+
+pcie0: pcie@f0460000 {
+ reg = <0x0 0xf0460000 0x0 0x9310>;
+ interrupts = <0x0 0x0 0x4>;
+ compatible = "brcm,pci-plat-dev";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
+ 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &intc 0 47 3
+ 0 0 0 2 &intc 0 48 3
+ 0 0 0 3 &intc 0 49 3
+ 0 0 0 4 &intc 0 50 3>;
+ interrupt-names = "pcie_0_inta",
+ "pcie_0_intb",
+ "pcie_0_intc",
+ "pcie_0_intd";
+ clocks = <&sw_pcie0>;
+ clock-names = "sw_pcie";
+ msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
+ msi-controller; /* use PCIe's internal MSI controller */
+ brcm,ssc;
+ brcm,gen = <1>;
+ supply-names = "vreg-wifi-pwr";
+ supplies = <&vreg-wifi-pwr>;
+ linux,pci-domain = <0>;
+ };
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Jim Quinlan, Brian Norris,
linux-arm-kernel
The DT bindings description of the Brcmstb PCIe device is described. This
node can be used by almost all Broadcom settop box chips, using
ARM, ARM64, or MIPS CPU architectures.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
.../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
new file mode 100644
index 0000000..2f699da
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
@@ -0,0 +1,106 @@
+Brcmstb PCIe Host Controller Device Tree Bindings
+
+Introduction:
+ The brcmstb host controller closely follows the example set in
+
+ [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
+
+ The rest of this document explains some added customizations and
+ offers an example Brcmstb PCIe host controller DT node.
+
+Required Properties:
+ reg -- the register start address and length for the PCIe block.
+ Additional start,length pairs may be specified for clock addresses.
+ interrupts -- two interrupts are specified; the first interrupt is for
+ the PCI host controller and the second is for MSI if the built-in
+ MSI controller is to be used.
+ interrupt-names -- names of the interrupts (above): "pcie" and "msi".
+ compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
+ or "brcm,bcm7278-pcie".
+ #address-cells -- the number of address cells for PCI-space.
+ #size-cells -- the number of size cells for PCI-space.
+ ranges -- See [1]; a specification of the outbound windows for the host
+ controller. Each outbound window is described by a n-tuple:
+ (3 cells) -- PCIe space start address; one cell for attributes
+ and two cells for the 64-bit PCIe address.
+ (x cells) -- CPU/System start address, number of cells is determined
+ by the parent node's #address-cells.
+ (y cells) -- Size of region, number of cells determined by the
+ parent node's #size-cells.
+ Due to hardware limitations, there may be a maximum of four
+ non-contiguous ranges specified.
+ #interrupt-cells -- number of cells used to describe the interrupt.
+ interrupt-map-mask -- see [1]; four cells, the first three are zero
+ for our uses and the fourth cell is the mask (val = 0x7) for
+ the legacy interrupt number [1..4].
+ interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
+ INTC, and INTD) to be mapped; each interrupt requires 5 cells
+ plus the size of the interrupt specifier.
+ linux,pci-domain -- the domain of the host controller.
+
+Optional Properties:
+ clocks -- list of clock phandles. If specified, this should list one
+ clock.
+ clock-names -- the "local" names of the clocks specified in 'clocks'. Note
+ that if the 'clocks' property is given, 'clock-names' is mandatory,
+ and the name of the clock is expected to be "sw_pcie".
+ dma-ranges -- Similar in structure to ranges, each dma region is
+ specified with a n-tuple. Dma-regions describe the inbound
+ accesses from EP to RC; it translates the pci address that the
+ EP "sees" to the CPU address in memory. This property is needed
+ because the design of the Brcmstb memory subsystem often precludes
+ idenity-mapping between CPU address space and PCIe address space.
+ Each range is described by a n-tuple:
+ (3 cells) -- PCIe space start address; one cell for attributes
+ and two cells for the 64-bit PCIe address.
+ (x cells) -- CPU/System start address, number of cells is determined
+ by the parent node's #address-cells.
+ (y cells) -- Size of region, number of cells determined by the
+ parent node's #size-cells.
+ msi-parent -- if MSI is to be used, this must be a phandle to the
+ msi-parent. If this prop is set to the phandle of the PCIe
+ node, or if the msi-parent prop is missing, the PCIE controller
+ will attempt to use its built in MSI controller.
+ msi-controller -- this property should only be specified if the
+ PCIe controller is using its internal MSI controller.
+ brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
+ brcm,gen -- (integer) indicates desired generation of link:
+ 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
+ supply-names -- the names of voltage regulators that the root
+ complex should turn off/on/on on suspend/resume/boot. This
+ is a string list.
+ supplies -- A collection of phandles to a regulator nodes, see
+ Documentation/devicetree/bindings/regulator/ for specific
+ bindings. The number and order of phandles must match
+ exactly the number of strings in the "supply-names" property.
+
+Example Node:
+
+pcie0: pcie@f0460000 {
+ reg = <0x0 0xf0460000 0x0 0x9310>;
+ interrupts = <0x0 0x0 0x4>;
+ compatible = "brcm,pci-plat-dev";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
+ 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &intc 0 47 3
+ 0 0 0 2 &intc 0 48 3
+ 0 0 0 3 &intc 0 49 3
+ 0 0 0 4 &intc 0 50 3>;
+ interrupt-names = "pcie_0_inta",
+ "pcie_0_intb",
+ "pcie_0_intc",
+ "pcie_0_intd";
+ clocks = <&sw_pcie0>;
+ clock-names = "sw_pcie";
+ msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
+ msi-controller; /* use PCIe's internal MSI controller */
+ brcm,ssc;
+ brcm,gen = <1>;
+ supply-names = "vreg-wifi-pwr";
+ supplies = <&vreg-wifi-pwr>;
+ linux,pci-domain = <0>;
+ };
--
1.9.0.138.g2de3478
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
The DT bindings description of the Brcmstb PCIe device is described. This
node can be used by almost all Broadcom settop box chips, using
ARM, ARM64, or MIPS CPU architectures.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
.../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
new file mode 100644
index 0000000..2f699da
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
@@ -0,0 +1,106 @@
+Brcmstb PCIe Host Controller Device Tree Bindings
+
+Introduction:
+ The brcmstb host controller closely follows the example set in
+
+ [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
+
+ The rest of this document explains some added customizations and
+ offers an example Brcmstb PCIe host controller DT node.
+
+Required Properties:
+ reg -- the register start address and length for the PCIe block.
+ Additional start,length pairs may be specified for clock addresses.
+ interrupts -- two interrupts are specified; the first interrupt is for
+ the PCI host controller and the second is for MSI if the built-in
+ MSI controller is to be used.
+ interrupt-names -- names of the interrupts (above): "pcie" and "msi".
+ compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
+ or "brcm,bcm7278-pcie".
+ #address-cells -- the number of address cells for PCI-space.
+ #size-cells -- the number of size cells for PCI-space.
+ ranges -- See [1]; a specification of the outbound windows for the host
+ controller. Each outbound window is described by a n-tuple:
+ (3 cells) -- PCIe space start address; one cell for attributes
+ and two cells for the 64-bit PCIe address.
+ (x cells) -- CPU/System start address, number of cells is determined
+ by the parent node's #address-cells.
+ (y cells) -- Size of region, number of cells determined by the
+ parent node's #size-cells.
+ Due to hardware limitations, there may be a maximum of four
+ non-contiguous ranges specified.
+ #interrupt-cells -- number of cells used to describe the interrupt.
+ interrupt-map-mask -- see [1]; four cells, the first three are zero
+ for our uses and the fourth cell is the mask (val = 0x7) for
+ the legacy interrupt number [1..4].
+ interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
+ INTC, and INTD) to be mapped; each interrupt requires 5 cells
+ plus the size of the interrupt specifier.
+ linux,pci-domain -- the domain of the host controller.
+
+Optional Properties:
+ clocks -- list of clock phandles. If specified, this should list one
+ clock.
+ clock-names -- the "local" names of the clocks specified in 'clocks'. Note
+ that if the 'clocks' property is given, 'clock-names' is mandatory,
+ and the name of the clock is expected to be "sw_pcie".
+ dma-ranges -- Similar in structure to ranges, each dma region is
+ specified with a n-tuple. Dma-regions describe the inbound
+ accesses from EP to RC; it translates the pci address that the
+ EP "sees" to the CPU address in memory. This property is needed
+ because the design of the Brcmstb memory subsystem often precludes
+ idenity-mapping between CPU address space and PCIe address space.
+ Each range is described by a n-tuple:
+ (3 cells) -- PCIe space start address; one cell for attributes
+ and two cells for the 64-bit PCIe address.
+ (x cells) -- CPU/System start address, number of cells is determined
+ by the parent node's #address-cells.
+ (y cells) -- Size of region, number of cells determined by the
+ parent node's #size-cells.
+ msi-parent -- if MSI is to be used, this must be a phandle to the
+ msi-parent. If this prop is set to the phandle of the PCIe
+ node, or if the msi-parent prop is missing, the PCIE controller
+ will attempt to use its built in MSI controller.
+ msi-controller -- this property should only be specified if the
+ PCIe controller is using its internal MSI controller.
+ brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
+ brcm,gen -- (integer) indicates desired generation of link:
+ 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
+ supply-names -- the names of voltage regulators that the root
+ complex should turn off/on/on on suspend/resume/boot. This
+ is a string list.
+ supplies -- A collection of phandles to a regulator nodes, see
+ Documentation/devicetree/bindings/regulator/ for specific
+ bindings. The number and order of phandles must match
+ exactly the number of strings in the "supply-names" property.
+
+Example Node:
+
+pcie0: pcie at f0460000 {
+ reg = <0x0 0xf0460000 0x0 0x9310>;
+ interrupts = <0x0 0x0 0x4>;
+ compatible = "brcm,pci-plat-dev";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
+ 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &intc 0 47 3
+ 0 0 0 2 &intc 0 48 3
+ 0 0 0 3 &intc 0 49 3
+ 0 0 0 4 &intc 0 50 3>;
+ interrupt-names = "pcie_0_inta",
+ "pcie_0_intb",
+ "pcie_0_intc",
+ "pcie_0_intd";
+ clocks = <&sw_pcie0>;
+ clock-names = "sw_pcie";
+ msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
+ msi-controller; /* use PCIe's internal MSI controller */
+ brcm,ssc;
+ brcm,gen = <1>;
+ supply-names = "vreg-wifi-pwr";
+ supplies = <&vreg-wifi-pwr>;
+ linux,pci-domain = <0>;
+ };
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 3/9] PCI: host: brcmstb: Broadcom PCIe Host Controller
2017-10-11 22:34 ` Jim Quinlan
(?)
(?)
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
This commit adds the basic Broadcom STB PCIe controller. Missing is
the ability to process MSI and also handle dma-ranges for inbound
memory accesses. These two functionalities are added in subsequent
commits.
The PCIe block contains an MDIO interface. This is a local interface
only accessible by the PCIe controller. It cannot be used or shared
by any other HW. As such, the small amount of code for this
controller is included in this driver as there is little upside to put
it elsewhere.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Kconfig | 8 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-brcmstb.c | 1191 ++++++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.h | 33 ++
4 files changed, 1233 insertions(+)
create mode 100644 drivers/pci/host/pci-brcmstb.c
create mode 100644 drivers/pci/host/pci-brcmstb.h
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b868803..b9b4f11 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -220,4 +220,12 @@ config VMD
To compile this driver as a module, choose M here: the
module will be called vmd.
+config PCI_BRCMSTB
+ tristate "Broadcom Brcmstb PCIe platform host driver"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ depends on OF
+ depends on SOC_BRCMSTB
+ default ARCH_BRCMSTB || BMIPS_GENERIC
+ help
+ Adds support for Broadcom Settop Box PCIe host controller.
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 1238278..4398d2c 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
+obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
new file mode 100644
index 0000000..f4cd6e7
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -0,0 +1,1191 @@
+/*
+ * Copyright (C) 2009 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/clk.h>
+#include <linux/compiler.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/log2.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/printk.h>
+#include <linux/regulator/consumer.h>
+#include <linux/sizes.h>
+#include <linux/slab.h>
+#include <soc/brcmstb/memory_api.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include "pci-brcmstb.h"
+
+/* Broadcom Settop Box PCIE Register Offsets. */
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY 0x00b8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL 0x00bc
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL 0x00c8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2 0x00dc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
+#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
+#define PCIE_RC_DL_MDIO_ADDR 0x1100
+#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
+#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
+#define PCIE_MISC_MISC_CTRL 0x4008
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
+#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
+#define PCIE_MISC_RC_BAR1_CONFIG_HI 0x4030
+#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
+#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
+#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
+#define PCIE_MISC_RC_BAR3_CONFIG_HI 0x4040
+#define PCIE_MISC_PCIE_CTRL 0x4064
+#define PCIE_MISC_PCIE_STATUS 0x4068
+#define PCIE_MISC_REVISION 0x406c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
+
+/* Broadcom Settop Box PCIE Register Field Shift, Mask Info. */
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_MASK 0x3f00000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_SHIFT 0x14
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_MASK 0xf0000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_SHIFT 0x10
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_MASK 0x10
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_SHIFT 0x4
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_MASK 0x3
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_MASK 0x30
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_SHIFT 0x4
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x7c00000
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_SHIFT 0x16
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x1f
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_SHIFT 0x2
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
+#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
+#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
+#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
+#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
+
+#define BRCM_NUM_PCI_OUT_WINS 0x4
+#define BRCM_MAX_SCB 0x4
+
+#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
+#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
+
+#define BURST_SIZE_128 0
+#define BURST_SIZE_256 1
+#define BURST_SIZE_512 2
+
+/* Offsets from PCIE_INTR2_CPU_BASE */
+#define STATUS 0x0
+#define SET 0x4
+#define CLR 0x8
+#define MASK_STATUS 0xc
+#define MASK_SET 0x10
+#define MASK_CLR 0x14
+
+#define PCI_BUSNUM_SHIFT 20
+#define PCI_SLOT_SHIFT 15
+#define PCI_FUNC_SHIFT 12
+
+#if defined(__BIG_ENDIAN)
+#define DATA_ENDIAN 2 /* PCI->DDR inbound accesses */
+#define MMIO_ENDIAN 2 /* CPU->PCI outbound accesses */
+#else
+#define DATA_ENDIAN 0
+#define MMIO_ENDIAN 0
+#endif
+
+#define MDIO_PORT0 0x0
+#define MDIO_DATA_MASK 0x7fffffff
+#define MDIO_DATA_SHIFT 0x0
+#define MDIO_PORT_MASK 0xf0000
+#define MDIO_PORT_SHIFT 0x16
+#define MDIO_REGAD_MASK 0xffff
+#define MDIO_REGAD_SHIFT 0x0
+#define MDIO_CMD_MASK 0xfff00000
+#define MDIO_CMD_SHIFT 0x14
+#define MDIO_CMD_READ 0x1
+#define MDIO_CMD_WRITE 0x0
+#define MDIO_DATA_DONE_MASK 0x80000000
+#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
+#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
+#define SSC_REGS_ADDR 0x1100
+#define SET_ADDR_OFFSET 0x1f
+#define SSC_CNTL_OFFSET 0x2
+#define SSC_CNTL_OVRD_EN_MASK 0x8000
+#define SSC_CNTL_OVRD_EN_SHIFT 0xf
+#define SSC_CNTL_OVRD_VAL_MASK 0x4000
+#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
+#define SSC_STATUS_OFFSET 0x1
+#define SSC_STATUS_SSC_MASK 0x400
+#define SSC_STATUS_SSC_SHIFT 0xa
+#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
+
+#define IDX_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_INDEX])
+#define DATA_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_DATA])
+#define PCIE_RGR1_SW_INIT_1(pcie) \
+ ((pcie)->reg_offsets[RGR1_SW_INIT_1])
+
+enum {
+ RGR1_SW_INIT_1,
+ EXT_CFG_INDEX,
+ EXT_CFG_DATA,
+};
+
+enum {
+ RGR1_SW_INIT_1_INIT_MASK,
+ RGR1_SW_INIT_1_INIT_SHIFT,
+ RGR1_SW_INIT_1_PERST_MASK,
+ RGR1_SW_INIT_1_PERST_SHIFT,
+};
+
+enum pcie_type {
+ BCM7425,
+ BCM7435,
+ GENERIC,
+ BCM7278,
+};
+
+#define RD_FLD(base, reg, field) \
+ rd_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT)
+#define WR_FLD(base, reg, field, val) \
+ wr_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_RB(base, reg, field, val) \
+ wr_fld_rb(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
+ wr_fld(base + reg + off, reg##_##field##_MASK, \
+ reg##_##field##_SHIFT, val)
+#define EXTRACT_FIELD(val, reg, field) \
+ ((val & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
+#define INSERT_FIELD(val, reg, field, field_val) \
+ ((val & ~reg##_##field##_MASK) | \
+ (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
+
+struct pcie_cfg_data {
+ const int *reg_field_info;
+ const int *offsets;
+ const enum pcie_type type;
+};
+
+static const int pcie_reg_field_info[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
+};
+
+static const int pcie_reg_field_info_bcm7278[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
+};
+
+static const int pcie_offset_bcm7425[] = {
+ [RGR1_SW_INIT_1] = 0x8010,
+ [EXT_CFG_INDEX] = 0x8300,
+ [EXT_CFG_DATA] = 0x8304,
+};
+
+static const struct pcie_cfg_data bcm7425_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offset_bcm7425,
+ .type = BCM7425,
+};
+
+static const int pcie_offsets[] = {
+ [RGR1_SW_INIT_1] = 0x9210,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7435_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = BCM7435,
+};
+
+static const struct pcie_cfg_data generic_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = GENERIC,
+};
+
+static const int pcie_offset_bcm7278[] = {
+ [RGR1_SW_INIT_1] = 0xc010,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7278_cfg = {
+ .reg_field_info = pcie_reg_field_info_bcm7278,
+ .offsets = pcie_offset_bcm7278,
+ .type = BCM7278,
+};
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where);
+
+static struct pci_ops brcm_pci_ops = {
+ .map_bus = brcm_pci_map_cfg,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+struct brcm_dev_pwr_supply {
+ struct list_head node;
+ char name[32];
+ struct regulator *regulator;
+};
+
+struct brcm_window {
+ dma_addr_t pci_addr;
+ phys_addr_t cpu_addr;
+ dma_addr_t size;
+};
+
+/* Internal Bus Controller Information.*/
+struct brcm_pcie {
+ struct list_head list;
+ void __iomem *base;
+ char name[BRCM_PCIE_NAME_SIZE];
+ bool suspended;
+ struct clk *clk;
+ struct device_node *dn;
+ int irq;
+ int num_out_wins;
+ bool ssc;
+ int gen;
+ struct brcm_window out_wins[BRCM_NUM_PCI_OUT_WINS];
+ struct list_head resources;
+ struct device *dev;
+ struct list_head pwr_supplies;
+ unsigned int rev;
+ unsigned int num;
+ bool bridge_setup_done;
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
+ struct pci_bus *root_bus;
+ int id;
+};
+
+static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
+static phys_addr_t scb_size[BRCM_MAX_SCB];
+static int num_memc;
+static DEFINE_MUTEX(brcm_pcie_lock);
+
+/*
+ * The roundup_pow_of_two() from log2.h invokes
+ * __roundup_pow_of_two(unsigned long), but we really need a
+ * such a function to take a native u64 since unsigned long
+ * is 32 bits on some configurations. So we provide this helper
+ * function below.
+ */
+static u64 roundup_pow_of_two_64(u64 n)
+{
+ return 1ULL << fls64(n - 1);
+}
+
+static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
+{
+ mutex_lock(&brcm_pcie_lock);
+ snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
+ list_add_tail(&pcie->list, &brcm_pcie);
+ mutex_unlock(&brcm_pcie_lock);
+
+ return 0;
+}
+
+static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
+{
+ struct list_head *pos, *q;
+ struct brcm_pcie *tmp;
+
+ mutex_lock(&brcm_pcie_lock);
+ list_for_each_safe(pos, q, &brcm_pcie) {
+ tmp = list_entry(pos, struct brcm_pcie, list);
+ if (tmp == pcie) {
+ list_del(pos);
+ if (list_empty(&brcm_pcie))
+ num_memc = 0;
+ break;
+ }
+ }
+ mutex_unlock(&brcm_pcie_lock);
+}
+
+/* This is to convert the size of the inbound bar region to the
+ * non-liniear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
+ */
+int encode_ibar_size(u64 size)
+{
+ int log2_in = ilog2(size);
+
+ if (log2_in >= 12 && log2_in <= 15)
+ /* Covers 4KB to 32KB (inclusive) */
+ return (log2_in - 12) + 0x1c;
+ else if (log2_in >= 16 && log2_in <= 37)
+ /* Covers 64KB to 32GB, (inclusive) */
+ return log2_in - 15;
+ /* Something is awry so disable */
+ return 0;
+}
+
+static u32 mdio_form_pkt(int port, int regad, int cmd)
+{
+ u32 pkt = 0;
+
+ pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
+ pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
+ pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
+
+ return pkt;
+}
+
+/* negative return value indicates error */
+static int mdio_read(void __iomem *base, u8 port, u8 regad)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_READ),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ }
+
+ return MDIO_RD_DONE(data)
+ ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
+ : -EIO;
+}
+
+/* negative return value indicates error */
+static int mdio_write(void __iomem *base, u8 port, u8 regad, u16 wrdata)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
+ base + PCIE_RC_DL_MDIO_WR_DATA);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ }
+
+ return MDIO_WT_DONE(data) ? 0 : -EIO;
+}
+
+static u32 rd_fld(void __iomem *p, u32 mask, int shift)
+{
+ return (bcm_readl(p) & mask) >> shift;
+}
+
+static void wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ u32 reg = bcm_readl(p);
+
+ reg = (reg & ~mask) | ((val << shift) & mask);
+ bcm_writel(reg, p);
+}
+
+static void wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ wr_fld(p, mask, shift, val);
+ (void)bcm_readl(p);
+}
+
+/* configures device for ssc mode; negative return value indicates error */
+static int set_ssc(void __iomem *base)
+{
+ int tmp;
+ u16 wrdata;
+ int pll, ssc;
+
+ tmp = mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET, SSC_REGS_ADDR);
+ if (tmp < 0)
+ return tmp;
+
+ tmp = mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
+ wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
+ tmp = mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
+ if (tmp < 0)
+ return tmp;
+
+ usleep_range(1000, 2000);
+ tmp = mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
+ pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
+
+ return (ssc && pll) ? 0 : -EIO;
+}
+
+/* limits operation to a specific generation (1, 2, or 3) */
+static void set_gen(void __iomem *base, int gen)
+{
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_CAPABILITY, MAX_LINK_SPEED, gen);
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2,
+ TARGET_LINK_SPEED, gen);
+}
+
+static void set_pcie_outbound_win(struct brcm_pcie *pcie, unsigned int win,
+ phys_addr_t cpu_addr, dma_addr_t pci_addr,
+ dma_addr_t size)
+{
+ void __iomem *base = pcie->base;
+ phys_addr_t cpu_addr_mb, limit_addr_mb;
+ u32 tmp;
+
+ /* Set the base of the pci_addr window */
+ bcm_writel(lower_32_bits(pci_addr) + MMIO_ENDIAN,
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
+ bcm_writel(upper_32_bits(pci_addr),
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
+
+ cpu_addr_mb = cpu_addr >> 20;
+ limit_addr_mb = (cpu_addr + size - 1) >> 20;
+
+ /* Write the addr base low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ BASE, cpu_addr_mb);
+ /* Write the addr limit low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ LIMIT, limit_addr_mb);
+
+ if (pcie->type != BCM7435 && pcie->type != BCM7425) {
+ /* Write the cpu addr high register */
+ tmp = (u32)(cpu_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
+ BASE, tmp);
+ /* Write the cpu limit high register */
+ tmp = (u32)(limit_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
+ LIMIT, tmp);
+ }
+}
+
+static int is_pcie_link_up(struct brcm_pcie *pcie, bool silent)
+{
+ void __iomem *base = pcie->base;
+ u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
+ u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
+ u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
+ u32 rc = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
+
+ if (!rc && !silent)
+ dev_err(pcie->dev, "controller configured in EP mode\n");
+
+ return (rc && dla && plu) ? 1 : 0;
+}
+
+static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ unsigned int offset;
+ unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
+ u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
+
+ if (pcie->type != BCM7278) {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ } else if (of_machine_is_compatible("brcm,bcm7278a0")) {
+ /* The two PCIE instance on 7278a0 are not even consistent with
+ * respect to each other for internal offsets, here we offset
+ * by 0x14000 + RGR1_SW_INIT_1's relative offset to account for
+ * that.
+ */
+ offset = pcie->id ? 0x14010 : pcie->reg_offsets[RGR1_SW_INIT_1];
+ wr_fld_rb(pcie->base + offset, mask, shift, val);
+ } else {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ }
+}
+
+static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ if (pcie->type != BCM7278)
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie),
+ PCIE_RGR1_SW_INIT_1_PERST_MASK,
+ PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
+ else
+ /* Assert = 0, de-assert = 1 on 7278 */
+ WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
+}
+
+static int brcm_parse_ranges(struct brcm_pcie *pcie)
+{
+ struct resource_entry *win;
+ int ret;
+
+ ret = of_pci_get_host_bridge_resources(pcie->dn, 0, 0xff,
+ &pcie->resources, NULL);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get host resources\n");
+ return ret;
+ }
+
+ resource_list_for_each_entry(win, &pcie->resources) {
+ struct resource *parent, *res = win->res;
+ dma_addr_t offset = (dma_addr_t)win->offset;
+
+ if (resource_type(res) == IORESOURCE_IO) {
+ parent = &ioport_resource;
+ } else if (resource_type(res) == IORESOURCE_MEM) {
+ if (pcie->num_out_wins >= BRCM_NUM_PCI_OUT_WINS) {
+ dev_err(pcie->dev, "too many outbound wins\n");
+ return -EINVAL;
+ }
+ pcie->out_wins[pcie->num_out_wins].cpu_addr
+ = (phys_addr_t)res->start;
+ pcie->out_wins[pcie->num_out_wins].pci_addr
+ = (dma_addr_t)(res->start
+ - (phys_addr_t)offset);
+ pcie->out_wins[pcie->num_out_wins].size
+ = (dma_addr_t)(res->end - res->start + 1);
+ pcie->num_out_wins++;
+ parent = &iomem_resource;
+ } else {
+ continue;
+ }
+
+ ret = devm_request_resource(pcie->dev, parent, res);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get res %pR\n", res);
+ return ret;
+ }
+ }
+ return 0;
+}
+
+static void set_regulators(struct brcm_pcie *pcie, bool on)
+{
+ struct list_head *pos;
+
+ list_for_each(pos, &pcie->pwr_supplies) {
+ struct brcm_dev_pwr_supply *supply
+ = list_entry(pos, struct brcm_dev_pwr_supply, node);
+
+ if (on && regulator_enable(supply->regulator))
+ pr_debug("Unable to turn on %s supply.\n",
+ supply->name);
+ else if (!on && regulator_disable(supply->regulator))
+ pr_debug("Unable to turn off %s supply.\n",
+ supply->name);
+ }
+}
+
+static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ unsigned int scb_size_val;
+ u64 rc_bar2_size = 0, rc_bar2_offset = 0, total_mem_size = 0;
+ u32 tmp, burst;
+ int i;
+
+ /* reset the bridge and the endpoint device */
+ /* field: PCIE_BRIDGE_SW_INIT = 1 */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+
+ /* field: PCIE_SW_PERST = 1, on 7278, we start de-asserted already */
+ if (pcie->type != BCM7278)
+ brcm_pcie_perst_set(pcie, 1);
+
+ usleep_range(100, 200);
+
+ /* take the bridge out of reset */
+ /* field: PCIE_BRIDGE_SW_INIT = 0 */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ /* Grab the PCIe hw revision number */
+ tmp = bcm_readl(base + PCIE_MISC_REVISION);
+ pcie->rev = EXTRACT_FIELD(tmp, PCIE_MISC_REVISION, MAJMIN);
+
+ /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
+ tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
+ burst = (pcie->type == GENERIC || pcie->type == BCM7278)
+ ? BURST_SIZE_512 : BURST_SIZE_256;
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE, burst);
+ bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
+
+ /* Set up inbound memory view for the EP (called RC_BAR2,
+ * not to be confused with the BARs that are advertised by
+ * the EP).
+ */
+ for (i = 0; i < num_memc; i++)
+ total_mem_size += scb_size[i];
+
+ /* The PCI host controller by design must set the inbound
+ * viewport to be a contiguous arrangement of all of the
+ * system's memory. In addition, its size mut be a power of
+ * two. To further complicate matters, the viewport must
+ * start on a pci-address that is aligned on a multiple of its
+ * size. If a portion of the viewport does not represent
+ * system memory -- e.g. 3GB of memory requires a 4GB viewport
+ * -- we can map the outbound memory in or after 3GB and even
+ * though the viewport will overlap the outbound memory the
+ * controller will know to send outbound memory downstream and
+ * everything else upstream.
+ */
+ rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
+
+ /* Set simple configuration based on memory sizes
+ * only. We always start the viewport at address 0.
+ */
+ rc_bar2_offset = 0;
+
+ tmp = lower_32_bits(rc_bar2_offset);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
+ encode_ibar_size(rc_bar2_size));
+ bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
+ bcm_writel(upper_32_bits(rc_bar2_offset),
+ base + PCIE_MISC_RC_BAR2_CONFIG_HI);
+
+ /* field: SCB0_SIZE, default = 0xf (1 GB) */
+ scb_size_val = scb_size[0]
+ ? ilog2(scb_size[0]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
+
+ /* field: SCB1_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 1) {
+ scb_size_val = scb_size[1]
+ ? ilog2(scb_size[1]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB1_SIZE, scb_size_val);
+ }
+
+ /* field: SCB2_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 2) {
+ scb_size_val = scb_size[2]
+ ? ilog2(scb_size[2]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB2_SIZE, scb_size_val);
+ }
+
+ /* disable the PCIE->GISB memory window (RC_BAR1) */
+ WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
+
+ /* disable the PCIE->SCB memory window (RC_BAR3) */
+ WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
+
+ if (!pcie->suspended) {
+ /* clear any interrupts we find on boot */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
+ }
+
+ /* Mask all interrupts since we are not handling any yet */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
+
+ if (pcie->gen)
+ set_gen(base, pcie->gen);
+
+ /* take the EP device out of reset */
+ /* field: PCIE_SW_PERST = 0 */
+ brcm_pcie_perst_set(pcie, 0);
+}
+
+static const char *link_speed_to_str(int s)
+{
+ switch (s) {
+ case 1:
+ return "2.5";
+ case 2:
+ return "5.0";
+ case 3:
+ return "8.0";
+ default:
+ break;
+ }
+ return "???";
+}
+
+static int brcm_pcie_setup_bridge(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ const int limit = pcie->suspended ? 1000 : 100;
+ unsigned int status;
+ int i, j, ret;
+ u32 neg_width, neg_speed;
+ bool ssc_good = false;
+
+ /* Give the RC/EP time to wake up, before trying to configure RC.
+ * Intermittently check status for link-up, up to a total of 100ms
+ * when we don't know if the device is there, and up to 1000ms if
+ * we do know the device is there.
+ */
+ for (i = 1, j = 0; j < limit && !is_pcie_link_up(pcie, true);
+ j += i, i = i * 2)
+ msleep(i + j > limit ? limit - j : i);
+
+ if (!is_pcie_link_up(pcie, false)) {
+ dev_info(pcie->dev, "link down\n");
+ return -ENODEV;
+ }
+
+ for (i = 0; i < pcie->num_out_wins; i++)
+ set_pcie_outbound_win(pcie, i, pcie->out_wins[i].cpu_addr,
+ pcie->out_wins[i].pci_addr,
+ pcie->out_wins[i].size);
+
+ /* For config space accesses on the RC, show the right class for
+ * a PCI-PCI bridge
+ */
+ WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
+
+ if (pcie->ssc) {
+ ret = set_ssc(base);
+ if (ret == 0)
+ ssc_good = true;
+ else
+ dev_err(pcie->dev,
+ "failed attempt to enter ssc mode\n");
+ }
+
+ status = bcm_readl(base + PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL);
+ neg_width = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_WIDTH);
+ neg_speed = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_SPEED);
+ dev_info(pcie->dev, "link up, %s Gbps x%u %s\n",
+ link_speed_to_str(neg_speed), neg_width,
+ ssc_good ? "(SSC)" : "(!SSC)");
+
+ /* Enable configuration request retry (see pci_scan_device()) */
+ /* field RC_CRS_EN = 1 */
+ WR_FLD(base, PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL, RC_CRS_EN, 1);
+
+ /* PCIE->SCB endian mode for BAR */
+ /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
+ WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
+ ENDIAN_MODE_BAR2, DATA_ENDIAN);
+
+ /* Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
+ * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
+ */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
+
+ pcie->bridge_setup_done = true;
+
+ return 0;
+}
+
+static void enter_l23(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ int tries, l23;
+
+ /* assert request for L23 */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
+ /* poll L23 status */
+ for (tries = 0, l23 = 0; tries < 1000 && !l23; tries++)
+ l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
+ if (!l23)
+ dev_err(pcie->dev, "failed to enter L23\n");
+}
+
+static void turn_off(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+
+ if (is_pcie_link_up(pcie, true))
+ enter_l23(pcie);
+ /* Reset endpoint device */
+ brcm_pcie_perst_set(pcie, 1);
+ /* deassert request for L23 in case it was asserted */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
+ /* SERDES_IDDQ = 1 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
+ /* Shutdown PCIe bridge */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+}
+
+static int brcm_pcie_suspend(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ set_regulators(pcie, false);
+ pcie->suspended = true;
+
+ return 0;
+}
+
+static int brcm_pcie_resume(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ void __iomem *base;
+ int ret;
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ base = pcie->base;
+ set_regulators(pcie, true);
+ clk_prepare_enable(pcie->clk);
+
+ /* Take bridge out of reset so we can access the SERDES reg */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ /* SERDES_IDDQ = 0 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ brcm_pcie_setup_prep(pcie);
+
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ return ret;
+
+ pcie->suspended = false;
+
+ return 0;
+}
+
+/* Configuration space read/write support */
+static int cfg_index(int busnr, int devfn, int reg)
+{
+ return ((PCI_SLOT(devfn) & 0x1f) << PCI_SLOT_SHIFT)
+ | ((PCI_FUNC(devfn) & 0x07) << PCI_FUNC_SHIFT)
+ | (busnr << PCI_BUSNUM_SHIFT)
+ | (reg & ~3);
+}
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ struct brcm_pcie *pcie = bus->sysdata;
+ void __iomem *base = pcie->base;
+ bool rc_access = pci_is_root_bus(bus);
+ int idx;
+
+ if (!is_pcie_link_up(pcie, true))
+ return NULL;
+
+ base = pcie->base;
+ idx = cfg_index(bus->number, devfn, where);
+
+ bcm_writel(idx, pcie->base + IDX_ADDR(pcie));
+
+ if (rc_access) {
+ if (PCI_SLOT(devfn))
+ return NULL;
+ return base + (where & ~3);
+ }
+
+ return pcie->base + DATA_ADDR(pcie);
+}
+
+static void __attribute__((__section__("pci_fixup_early")))
+brcm_pcibios_fixup(struct pci_dev *dev)
+{
+ struct brcm_pcie *pcie = dev->bus->sysdata;
+ u8 slot = PCI_SLOT(dev->devfn);
+
+ dev_info(pcie->dev,
+ "found device %04x:%04x on bus %d (%s), slot %d (irq %d)\n",
+ dev->vendor, dev->device, dev->bus->number, pcie->name,
+ slot, of_irq_parse_and_map_pci(dev, slot, 1));
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, brcm_pcibios_fixup);
+
+static const struct of_device_id brcm_pci_match[] = {
+ { .compatible = "brcm,bcm7425-pcie", .data = &bcm7425_cfg },
+ { .compatible = "brcm,bcm7435-pcie", .data = &bcm7435_cfg },
+ { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,pci-plat-dev", .data = &generic_cfg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, brcm_pci_match);
+
+static void _brcm_pcie_remove(struct brcm_pcie *pcie)
+{
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ clk_put(pcie->clk);
+ set_regulators(pcie, false);
+ brcm_pcie_remove_controller(pcie);
+}
+
+static int brcm_pcie_probe(struct platform_device *pdev)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ const struct of_device_id *of_id;
+ const struct pcie_cfg_data *data;
+ int i, ret;
+ struct brcm_pcie *pcie;
+ struct resource *res;
+ void __iomem *base;
+ u32 tmp;
+ int supplies;
+ const char *name;
+ struct brcm_dev_pwr_supply *supply;
+ struct pci_host_bridge *bridge;
+ struct pci_bus *child;
+ u32 domain;
+
+ bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
+ if (!bridge)
+ return -ENOMEM;
+
+ pcie = pci_host_bridge_priv(bridge);
+ INIT_LIST_HEAD(&pcie->resources);
+
+ of_id = of_match_node(brcm_pci_match, dn);
+ if (!of_id) {
+ pr_err("failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
+ pr_err("cannot yet handle dma-ranges\n");
+ return -EINVAL;
+ }
+
+ data = of_id->data;
+ pcie->reg_offsets = data->offsets;
+ pcie->reg_field_info = data->reg_field_info;
+ pcie->type = data->type;
+ pcie->dn = dn;
+ pcie->dev = &pdev->dev;
+
+ if (of_property_read_u32(dn, "linux,pci-domain", &domain) == 0) {
+ pcie->id = (int)domain;
+ } else {
+ dev_err(pcie->dev, "linux,pci-domain prop missing\n");
+ return -EINVAL;
+ }
+
+ INIT_LIST_HEAD(&pcie->pwr_supplies);
+ supplies = of_property_count_strings(dn, "supply-names");
+ if (supplies <= 0)
+ supplies = 0;
+
+ for (i = 0; i < supplies; i++) {
+ if (of_property_read_string_index(dn, "supply-names", i,
+ &name))
+ continue;
+ supply = devm_kzalloc(&pdev->dev, sizeof(*supply), GFP_KERNEL);
+ if (!supply)
+ return -ENOMEM;
+ strncpy(supply->name, name, sizeof(supply->name));
+ supply->name[sizeof(supply->name) - 1] = '\0';
+ supply->regulator = devm_regulator_get(&pdev->dev, name);
+ if (IS_ERR(supply->regulator)) {
+ dev_err(&pdev->dev, "Unable to get %s supply, err=%d\n",
+ name, (int)PTR_ERR(supply->regulator));
+ continue;
+ }
+ list_add_tail(&supply->node, &pcie->pwr_supplies);
+ }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pcie->clk = of_clk_get_by_name(dn, "sw_pcie");
+ if (IS_ERR(pcie->clk)) {
+ dev_err(&pdev->dev, "could not get clock\n");
+ pcie->clk = NULL;
+ }
+ pcie->base = base;
+ pcie->gen = 0;
+
+ if (of_property_read_u32(dn, "brcm,gen", &tmp) == 0)
+ pcie->gen = tmp;
+
+ pcie->ssc = of_property_read_bool(dn, "brcm,ssc");
+
+ ret = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ if (ret == 0)
+ /* keep going, as we don't use this intr yet */
+ dev_warn(pcie->dev, "cannot get pcie interrupt\n");
+ else
+ pcie->irq = ret;
+
+ ret = brcm_parse_ranges(pcie);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(pcie->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "could not enable clock\n");
+ return ret;
+ }
+
+ ret = brcm_pcie_add_controller(pcie);
+ if (ret)
+ return ret;
+
+ set_regulators(pcie, true);
+ brcm_pcie_setup_prep(pcie);
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ goto fail;
+
+ list_splice_init(&pcie->resources, &bridge->windows);
+ bridge->dev.parent = &pdev->dev;
+ bridge->busnr = 0;
+ bridge->ops = &brcm_pci_ops;
+ bridge->sysdata = pcie;
+ bridge->map_irq = of_irq_parse_and_map_pci;
+ bridge->swizzle_irq = pci_common_swizzle;
+
+ ret = pci_scan_root_bus_bridge(bridge);
+ if (ret < 0) {
+ dev_err(pcie->dev, "Scanning root bridge failed");
+ goto fail;
+ }
+
+ pci_assign_unassigned_bus_resources(bridge->bus);
+ list_for_each_entry(child, &bridge->bus->children, node)
+ pcie_bus_configure_settings(child);
+ pci_bus_add_devices(bridge->bus);
+ platform_set_drvdata(pdev, pcie);
+ pcie->root_bus = bridge->bus;
+
+ return 0;
+
+fail:
+ _brcm_pcie_remove(pcie);
+ return ret;
+}
+
+static int brcm_pcie_remove(struct platform_device *pdev)
+{
+ struct brcm_pcie *pcie = platform_get_drvdata(pdev);
+
+ pci_stop_root_bus(pcie->root_bus);
+ pci_remove_root_bus(pcie->root_bus);
+ _brcm_pcie_remove(pcie);
+
+ return 0;
+}
+
+static const struct dev_pm_ops brcm_pcie_pm_ops = {
+ .suspend_noirq = brcm_pcie_suspend,
+ .resume_noirq = brcm_pcie_resume,
+};
+
+static struct platform_driver __refdata brcm_pci_driver = {
+ .probe = brcm_pcie_probe,
+ .remove = brcm_pcie_remove,
+ .driver = {
+ .name = "brcm-pci",
+ .owner = THIS_MODULE,
+ .of_match_table = brcm_pci_match,
+ .pm = &brcm_pcie_pm_ops,
+ },
+};
+
+module_platform_driver(brcm_pci_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Broadcom STB PCIE RC driver");
+MODULE_AUTHOR("Broadcom");
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
new file mode 100644
index 0000000..86f9cd1
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -0,0 +1,33 @@
+#ifndef __BRCMSTB_PCI_H
+#define __BRCMSTB_PCI_H
+
+/*
+ * Copyright (C) 2015 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define BRCM_PCIE_NAME_SIZE 8
+#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_PCIE_HW_REV_33 0x0303
+
+/* Broadcom PCIE Offsets */
+#define PCIE_INTR2_CPU_BASE 0x4300
+
+#if defined(CONFIG_MIPS)
+/* Broadcom MIPs HW implicitly does the swapping if necessary */
+#define bcm_readl(a) __raw_readl(a)
+#define bcm_writel(d, a) __raw_writel(d, a)
+#else
+#define bcm_readl(a) readl(a)
+#define bcm_writel(d, a) writel(d, a)
+#endif
+
+#endif /* __BRCMSTB_PCI_H */
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 3/9] PCI: host: brcmstb: Broadcom PCIe Host Controller
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Jim Quinlan, Brian Norris,
linux-arm-kernel
This commit adds the basic Broadcom STB PCIe controller. Missing is
the ability to process MSI and also handle dma-ranges for inbound
memory accesses. These two functionalities are added in subsequent
commits.
The PCIe block contains an MDIO interface. This is a local interface
only accessible by the PCIe controller. It cannot be used or shared
by any other HW. As such, the small amount of code for this
controller is included in this driver as there is little upside to put
it elsewhere.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Kconfig | 8 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-brcmstb.c | 1191 ++++++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.h | 33 ++
4 files changed, 1233 insertions(+)
create mode 100644 drivers/pci/host/pci-brcmstb.c
create mode 100644 drivers/pci/host/pci-brcmstb.h
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b868803..b9b4f11 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -220,4 +220,12 @@ config VMD
To compile this driver as a module, choose M here: the
module will be called vmd.
+config PCI_BRCMSTB
+ tristate "Broadcom Brcmstb PCIe platform host driver"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ depends on OF
+ depends on SOC_BRCMSTB
+ default ARCH_BRCMSTB || BMIPS_GENERIC
+ help
+ Adds support for Broadcom Settop Box PCIe host controller.
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 1238278..4398d2c 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
+obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
new file mode 100644
index 0000000..f4cd6e7
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -0,0 +1,1191 @@
+/*
+ * Copyright (C) 2009 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/clk.h>
+#include <linux/compiler.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/log2.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/printk.h>
+#include <linux/regulator/consumer.h>
+#include <linux/sizes.h>
+#include <linux/slab.h>
+#include <soc/brcmstb/memory_api.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include "pci-brcmstb.h"
+
+/* Broadcom Settop Box PCIE Register Offsets. */
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY 0x00b8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL 0x00bc
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL 0x00c8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2 0x00dc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
+#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
+#define PCIE_RC_DL_MDIO_ADDR 0x1100
+#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
+#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
+#define PCIE_MISC_MISC_CTRL 0x4008
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
+#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
+#define PCIE_MISC_RC_BAR1_CONFIG_HI 0x4030
+#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
+#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
+#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
+#define PCIE_MISC_RC_BAR3_CONFIG_HI 0x4040
+#define PCIE_MISC_PCIE_CTRL 0x4064
+#define PCIE_MISC_PCIE_STATUS 0x4068
+#define PCIE_MISC_REVISION 0x406c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
+
+/* Broadcom Settop Box PCIE Register Field Shift, Mask Info. */
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_MASK 0x3f00000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_SHIFT 0x14
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_MASK 0xf0000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_SHIFT 0x10
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_MASK 0x10
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_SHIFT 0x4
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_MASK 0x3
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_MASK 0x30
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_SHIFT 0x4
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x7c00000
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_SHIFT 0x16
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x1f
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_SHIFT 0x2
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
+#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
+#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
+#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
+#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
+
+#define BRCM_NUM_PCI_OUT_WINS 0x4
+#define BRCM_MAX_SCB 0x4
+
+#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
+#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
+
+#define BURST_SIZE_128 0
+#define BURST_SIZE_256 1
+#define BURST_SIZE_512 2
+
+/* Offsets from PCIE_INTR2_CPU_BASE */
+#define STATUS 0x0
+#define SET 0x4
+#define CLR 0x8
+#define MASK_STATUS 0xc
+#define MASK_SET 0x10
+#define MASK_CLR 0x14
+
+#define PCI_BUSNUM_SHIFT 20
+#define PCI_SLOT_SHIFT 15
+#define PCI_FUNC_SHIFT 12
+
+#if defined(__BIG_ENDIAN)
+#define DATA_ENDIAN 2 /* PCI->DDR inbound accesses */
+#define MMIO_ENDIAN 2 /* CPU->PCI outbound accesses */
+#else
+#define DATA_ENDIAN 0
+#define MMIO_ENDIAN 0
+#endif
+
+#define MDIO_PORT0 0x0
+#define MDIO_DATA_MASK 0x7fffffff
+#define MDIO_DATA_SHIFT 0x0
+#define MDIO_PORT_MASK 0xf0000
+#define MDIO_PORT_SHIFT 0x16
+#define MDIO_REGAD_MASK 0xffff
+#define MDIO_REGAD_SHIFT 0x0
+#define MDIO_CMD_MASK 0xfff00000
+#define MDIO_CMD_SHIFT 0x14
+#define MDIO_CMD_READ 0x1
+#define MDIO_CMD_WRITE 0x0
+#define MDIO_DATA_DONE_MASK 0x80000000
+#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
+#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
+#define SSC_REGS_ADDR 0x1100
+#define SET_ADDR_OFFSET 0x1f
+#define SSC_CNTL_OFFSET 0x2
+#define SSC_CNTL_OVRD_EN_MASK 0x8000
+#define SSC_CNTL_OVRD_EN_SHIFT 0xf
+#define SSC_CNTL_OVRD_VAL_MASK 0x4000
+#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
+#define SSC_STATUS_OFFSET 0x1
+#define SSC_STATUS_SSC_MASK 0x400
+#define SSC_STATUS_SSC_SHIFT 0xa
+#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
+
+#define IDX_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_INDEX])
+#define DATA_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_DATA])
+#define PCIE_RGR1_SW_INIT_1(pcie) \
+ ((pcie)->reg_offsets[RGR1_SW_INIT_1])
+
+enum {
+ RGR1_SW_INIT_1,
+ EXT_CFG_INDEX,
+ EXT_CFG_DATA,
+};
+
+enum {
+ RGR1_SW_INIT_1_INIT_MASK,
+ RGR1_SW_INIT_1_INIT_SHIFT,
+ RGR1_SW_INIT_1_PERST_MASK,
+ RGR1_SW_INIT_1_PERST_SHIFT,
+};
+
+enum pcie_type {
+ BCM7425,
+ BCM7435,
+ GENERIC,
+ BCM7278,
+};
+
+#define RD_FLD(base, reg, field) \
+ rd_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT)
+#define WR_FLD(base, reg, field, val) \
+ wr_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_RB(base, reg, field, val) \
+ wr_fld_rb(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
+ wr_fld(base + reg + off, reg##_##field##_MASK, \
+ reg##_##field##_SHIFT, val)
+#define EXTRACT_FIELD(val, reg, field) \
+ ((val & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
+#define INSERT_FIELD(val, reg, field, field_val) \
+ ((val & ~reg##_##field##_MASK) | \
+ (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
+
+struct pcie_cfg_data {
+ const int *reg_field_info;
+ const int *offsets;
+ const enum pcie_type type;
+};
+
+static const int pcie_reg_field_info[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
+};
+
+static const int pcie_reg_field_info_bcm7278[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
+};
+
+static const int pcie_offset_bcm7425[] = {
+ [RGR1_SW_INIT_1] = 0x8010,
+ [EXT_CFG_INDEX] = 0x8300,
+ [EXT_CFG_DATA] = 0x8304,
+};
+
+static const struct pcie_cfg_data bcm7425_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offset_bcm7425,
+ .type = BCM7425,
+};
+
+static const int pcie_offsets[] = {
+ [RGR1_SW_INIT_1] = 0x9210,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7435_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = BCM7435,
+};
+
+static const struct pcie_cfg_data generic_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = GENERIC,
+};
+
+static const int pcie_offset_bcm7278[] = {
+ [RGR1_SW_INIT_1] = 0xc010,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7278_cfg = {
+ .reg_field_info = pcie_reg_field_info_bcm7278,
+ .offsets = pcie_offset_bcm7278,
+ .type = BCM7278,
+};
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where);
+
+static struct pci_ops brcm_pci_ops = {
+ .map_bus = brcm_pci_map_cfg,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+struct brcm_dev_pwr_supply {
+ struct list_head node;
+ char name[32];
+ struct regulator *regulator;
+};
+
+struct brcm_window {
+ dma_addr_t pci_addr;
+ phys_addr_t cpu_addr;
+ dma_addr_t size;
+};
+
+/* Internal Bus Controller Information.*/
+struct brcm_pcie {
+ struct list_head list;
+ void __iomem *base;
+ char name[BRCM_PCIE_NAME_SIZE];
+ bool suspended;
+ struct clk *clk;
+ struct device_node *dn;
+ int irq;
+ int num_out_wins;
+ bool ssc;
+ int gen;
+ struct brcm_window out_wins[BRCM_NUM_PCI_OUT_WINS];
+ struct list_head resources;
+ struct device *dev;
+ struct list_head pwr_supplies;
+ unsigned int rev;
+ unsigned int num;
+ bool bridge_setup_done;
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
+ struct pci_bus *root_bus;
+ int id;
+};
+
+static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
+static phys_addr_t scb_size[BRCM_MAX_SCB];
+static int num_memc;
+static DEFINE_MUTEX(brcm_pcie_lock);
+
+/*
+ * The roundup_pow_of_two() from log2.h invokes
+ * __roundup_pow_of_two(unsigned long), but we really need a
+ * such a function to take a native u64 since unsigned long
+ * is 32 bits on some configurations. So we provide this helper
+ * function below.
+ */
+static u64 roundup_pow_of_two_64(u64 n)
+{
+ return 1ULL << fls64(n - 1);
+}
+
+static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
+{
+ mutex_lock(&brcm_pcie_lock);
+ snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
+ list_add_tail(&pcie->list, &brcm_pcie);
+ mutex_unlock(&brcm_pcie_lock);
+
+ return 0;
+}
+
+static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
+{
+ struct list_head *pos, *q;
+ struct brcm_pcie *tmp;
+
+ mutex_lock(&brcm_pcie_lock);
+ list_for_each_safe(pos, q, &brcm_pcie) {
+ tmp = list_entry(pos, struct brcm_pcie, list);
+ if (tmp == pcie) {
+ list_del(pos);
+ if (list_empty(&brcm_pcie))
+ num_memc = 0;
+ break;
+ }
+ }
+ mutex_unlock(&brcm_pcie_lock);
+}
+
+/* This is to convert the size of the inbound bar region to the
+ * non-liniear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
+ */
+int encode_ibar_size(u64 size)
+{
+ int log2_in = ilog2(size);
+
+ if (log2_in >= 12 && log2_in <= 15)
+ /* Covers 4KB to 32KB (inclusive) */
+ return (log2_in - 12) + 0x1c;
+ else if (log2_in >= 16 && log2_in <= 37)
+ /* Covers 64KB to 32GB, (inclusive) */
+ return log2_in - 15;
+ /* Something is awry so disable */
+ return 0;
+}
+
+static u32 mdio_form_pkt(int port, int regad, int cmd)
+{
+ u32 pkt = 0;
+
+ pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
+ pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
+ pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
+
+ return pkt;
+}
+
+/* negative return value indicates error */
+static int mdio_read(void __iomem *base, u8 port, u8 regad)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_READ),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ }
+
+ return MDIO_RD_DONE(data)
+ ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
+ : -EIO;
+}
+
+/* negative return value indicates error */
+static int mdio_write(void __iomem *base, u8 port, u8 regad, u16 wrdata)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
+ base + PCIE_RC_DL_MDIO_WR_DATA);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ }
+
+ return MDIO_WT_DONE(data) ? 0 : -EIO;
+}
+
+static u32 rd_fld(void __iomem *p, u32 mask, int shift)
+{
+ return (bcm_readl(p) & mask) >> shift;
+}
+
+static void wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ u32 reg = bcm_readl(p);
+
+ reg = (reg & ~mask) | ((val << shift) & mask);
+ bcm_writel(reg, p);
+}
+
+static void wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ wr_fld(p, mask, shift, val);
+ (void)bcm_readl(p);
+}
+
+/* configures device for ssc mode; negative return value indicates error */
+static int set_ssc(void __iomem *base)
+{
+ int tmp;
+ u16 wrdata;
+ int pll, ssc;
+
+ tmp = mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET, SSC_REGS_ADDR);
+ if (tmp < 0)
+ return tmp;
+
+ tmp = mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
+ wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
+ tmp = mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
+ if (tmp < 0)
+ return tmp;
+
+ usleep_range(1000, 2000);
+ tmp = mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
+ pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
+
+ return (ssc && pll) ? 0 : -EIO;
+}
+
+/* limits operation to a specific generation (1, 2, or 3) */
+static void set_gen(void __iomem *base, int gen)
+{
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_CAPABILITY, MAX_LINK_SPEED, gen);
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2,
+ TARGET_LINK_SPEED, gen);
+}
+
+static void set_pcie_outbound_win(struct brcm_pcie *pcie, unsigned int win,
+ phys_addr_t cpu_addr, dma_addr_t pci_addr,
+ dma_addr_t size)
+{
+ void __iomem *base = pcie->base;
+ phys_addr_t cpu_addr_mb, limit_addr_mb;
+ u32 tmp;
+
+ /* Set the base of the pci_addr window */
+ bcm_writel(lower_32_bits(pci_addr) + MMIO_ENDIAN,
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
+ bcm_writel(upper_32_bits(pci_addr),
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
+
+ cpu_addr_mb = cpu_addr >> 20;
+ limit_addr_mb = (cpu_addr + size - 1) >> 20;
+
+ /* Write the addr base low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ BASE, cpu_addr_mb);
+ /* Write the addr limit low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ LIMIT, limit_addr_mb);
+
+ if (pcie->type != BCM7435 && pcie->type != BCM7425) {
+ /* Write the cpu addr high register */
+ tmp = (u32)(cpu_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
+ BASE, tmp);
+ /* Write the cpu limit high register */
+ tmp = (u32)(limit_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
+ LIMIT, tmp);
+ }
+}
+
+static int is_pcie_link_up(struct brcm_pcie *pcie, bool silent)
+{
+ void __iomem *base = pcie->base;
+ u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
+ u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
+ u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
+ u32 rc = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
+
+ if (!rc && !silent)
+ dev_err(pcie->dev, "controller configured in EP mode\n");
+
+ return (rc && dla && plu) ? 1 : 0;
+}
+
+static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ unsigned int offset;
+ unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
+ u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
+
+ if (pcie->type != BCM7278) {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ } else if (of_machine_is_compatible("brcm,bcm7278a0")) {
+ /* The two PCIE instance on 7278a0 are not even consistent with
+ * respect to each other for internal offsets, here we offset
+ * by 0x14000 + RGR1_SW_INIT_1's relative offset to account for
+ * that.
+ */
+ offset = pcie->id ? 0x14010 : pcie->reg_offsets[RGR1_SW_INIT_1];
+ wr_fld_rb(pcie->base + offset, mask, shift, val);
+ } else {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ }
+}
+
+static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ if (pcie->type != BCM7278)
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie),
+ PCIE_RGR1_SW_INIT_1_PERST_MASK,
+ PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
+ else
+ /* Assert = 0, de-assert = 1 on 7278 */
+ WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
+}
+
+static int brcm_parse_ranges(struct brcm_pcie *pcie)
+{
+ struct resource_entry *win;
+ int ret;
+
+ ret = of_pci_get_host_bridge_resources(pcie->dn, 0, 0xff,
+ &pcie->resources, NULL);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get host resources\n");
+ return ret;
+ }
+
+ resource_list_for_each_entry(win, &pcie->resources) {
+ struct resource *parent, *res = win->res;
+ dma_addr_t offset = (dma_addr_t)win->offset;
+
+ if (resource_type(res) == IORESOURCE_IO) {
+ parent = &ioport_resource;
+ } else if (resource_type(res) == IORESOURCE_MEM) {
+ if (pcie->num_out_wins >= BRCM_NUM_PCI_OUT_WINS) {
+ dev_err(pcie->dev, "too many outbound wins\n");
+ return -EINVAL;
+ }
+ pcie->out_wins[pcie->num_out_wins].cpu_addr
+ = (phys_addr_t)res->start;
+ pcie->out_wins[pcie->num_out_wins].pci_addr
+ = (dma_addr_t)(res->start
+ - (phys_addr_t)offset);
+ pcie->out_wins[pcie->num_out_wins].size
+ = (dma_addr_t)(res->end - res->start + 1);
+ pcie->num_out_wins++;
+ parent = &iomem_resource;
+ } else {
+ continue;
+ }
+
+ ret = devm_request_resource(pcie->dev, parent, res);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get res %pR\n", res);
+ return ret;
+ }
+ }
+ return 0;
+}
+
+static void set_regulators(struct brcm_pcie *pcie, bool on)
+{
+ struct list_head *pos;
+
+ list_for_each(pos, &pcie->pwr_supplies) {
+ struct brcm_dev_pwr_supply *supply
+ = list_entry(pos, struct brcm_dev_pwr_supply, node);
+
+ if (on && regulator_enable(supply->regulator))
+ pr_debug("Unable to turn on %s supply.\n",
+ supply->name);
+ else if (!on && regulator_disable(supply->regulator))
+ pr_debug("Unable to turn off %s supply.\n",
+ supply->name);
+ }
+}
+
+static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ unsigned int scb_size_val;
+ u64 rc_bar2_size = 0, rc_bar2_offset = 0, total_mem_size = 0;
+ u32 tmp, burst;
+ int i;
+
+ /* reset the bridge and the endpoint device */
+ /* field: PCIE_BRIDGE_SW_INIT = 1 */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+
+ /* field: PCIE_SW_PERST = 1, on 7278, we start de-asserted already */
+ if (pcie->type != BCM7278)
+ brcm_pcie_perst_set(pcie, 1);
+
+ usleep_range(100, 200);
+
+ /* take the bridge out of reset */
+ /* field: PCIE_BRIDGE_SW_INIT = 0 */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ /* Grab the PCIe hw revision number */
+ tmp = bcm_readl(base + PCIE_MISC_REVISION);
+ pcie->rev = EXTRACT_FIELD(tmp, PCIE_MISC_REVISION, MAJMIN);
+
+ /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
+ tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
+ burst = (pcie->type == GENERIC || pcie->type == BCM7278)
+ ? BURST_SIZE_512 : BURST_SIZE_256;
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE, burst);
+ bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
+
+ /* Set up inbound memory view for the EP (called RC_BAR2,
+ * not to be confused with the BARs that are advertised by
+ * the EP).
+ */
+ for (i = 0; i < num_memc; i++)
+ total_mem_size += scb_size[i];
+
+ /* The PCI host controller by design must set the inbound
+ * viewport to be a contiguous arrangement of all of the
+ * system's memory. In addition, its size mut be a power of
+ * two. To further complicate matters, the viewport must
+ * start on a pci-address that is aligned on a multiple of its
+ * size. If a portion of the viewport does not represent
+ * system memory -- e.g. 3GB of memory requires a 4GB viewport
+ * -- we can map the outbound memory in or after 3GB and even
+ * though the viewport will overlap the outbound memory the
+ * controller will know to send outbound memory downstream and
+ * everything else upstream.
+ */
+ rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
+
+ /* Set simple configuration based on memory sizes
+ * only. We always start the viewport at address 0.
+ */
+ rc_bar2_offset = 0;
+
+ tmp = lower_32_bits(rc_bar2_offset);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
+ encode_ibar_size(rc_bar2_size));
+ bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
+ bcm_writel(upper_32_bits(rc_bar2_offset),
+ base + PCIE_MISC_RC_BAR2_CONFIG_HI);
+
+ /* field: SCB0_SIZE, default = 0xf (1 GB) */
+ scb_size_val = scb_size[0]
+ ? ilog2(scb_size[0]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
+
+ /* field: SCB1_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 1) {
+ scb_size_val = scb_size[1]
+ ? ilog2(scb_size[1]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB1_SIZE, scb_size_val);
+ }
+
+ /* field: SCB2_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 2) {
+ scb_size_val = scb_size[2]
+ ? ilog2(scb_size[2]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB2_SIZE, scb_size_val);
+ }
+
+ /* disable the PCIE->GISB memory window (RC_BAR1) */
+ WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
+
+ /* disable the PCIE->SCB memory window (RC_BAR3) */
+ WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
+
+ if (!pcie->suspended) {
+ /* clear any interrupts we find on boot */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
+ }
+
+ /* Mask all interrupts since we are not handling any yet */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
+
+ if (pcie->gen)
+ set_gen(base, pcie->gen);
+
+ /* take the EP device out of reset */
+ /* field: PCIE_SW_PERST = 0 */
+ brcm_pcie_perst_set(pcie, 0);
+}
+
+static const char *link_speed_to_str(int s)
+{
+ switch (s) {
+ case 1:
+ return "2.5";
+ case 2:
+ return "5.0";
+ case 3:
+ return "8.0";
+ default:
+ break;
+ }
+ return "???";
+}
+
+static int brcm_pcie_setup_bridge(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ const int limit = pcie->suspended ? 1000 : 100;
+ unsigned int status;
+ int i, j, ret;
+ u32 neg_width, neg_speed;
+ bool ssc_good = false;
+
+ /* Give the RC/EP time to wake up, before trying to configure RC.
+ * Intermittently check status for link-up, up to a total of 100ms
+ * when we don't know if the device is there, and up to 1000ms if
+ * we do know the device is there.
+ */
+ for (i = 1, j = 0; j < limit && !is_pcie_link_up(pcie, true);
+ j += i, i = i * 2)
+ msleep(i + j > limit ? limit - j : i);
+
+ if (!is_pcie_link_up(pcie, false)) {
+ dev_info(pcie->dev, "link down\n");
+ return -ENODEV;
+ }
+
+ for (i = 0; i < pcie->num_out_wins; i++)
+ set_pcie_outbound_win(pcie, i, pcie->out_wins[i].cpu_addr,
+ pcie->out_wins[i].pci_addr,
+ pcie->out_wins[i].size);
+
+ /* For config space accesses on the RC, show the right class for
+ * a PCI-PCI bridge
+ */
+ WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
+
+ if (pcie->ssc) {
+ ret = set_ssc(base);
+ if (ret == 0)
+ ssc_good = true;
+ else
+ dev_err(pcie->dev,
+ "failed attempt to enter ssc mode\n");
+ }
+
+ status = bcm_readl(base + PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL);
+ neg_width = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_WIDTH);
+ neg_speed = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_SPEED);
+ dev_info(pcie->dev, "link up, %s Gbps x%u %s\n",
+ link_speed_to_str(neg_speed), neg_width,
+ ssc_good ? "(SSC)" : "(!SSC)");
+
+ /* Enable configuration request retry (see pci_scan_device()) */
+ /* field RC_CRS_EN = 1 */
+ WR_FLD(base, PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL, RC_CRS_EN, 1);
+
+ /* PCIE->SCB endian mode for BAR */
+ /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
+ WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
+ ENDIAN_MODE_BAR2, DATA_ENDIAN);
+
+ /* Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
+ * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
+ */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
+
+ pcie->bridge_setup_done = true;
+
+ return 0;
+}
+
+static void enter_l23(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ int tries, l23;
+
+ /* assert request for L23 */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
+ /* poll L23 status */
+ for (tries = 0, l23 = 0; tries < 1000 && !l23; tries++)
+ l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
+ if (!l23)
+ dev_err(pcie->dev, "failed to enter L23\n");
+}
+
+static void turn_off(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+
+ if (is_pcie_link_up(pcie, true))
+ enter_l23(pcie);
+ /* Reset endpoint device */
+ brcm_pcie_perst_set(pcie, 1);
+ /* deassert request for L23 in case it was asserted */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
+ /* SERDES_IDDQ = 1 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
+ /* Shutdown PCIe bridge */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+}
+
+static int brcm_pcie_suspend(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ set_regulators(pcie, false);
+ pcie->suspended = true;
+
+ return 0;
+}
+
+static int brcm_pcie_resume(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ void __iomem *base;
+ int ret;
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ base = pcie->base;
+ set_regulators(pcie, true);
+ clk_prepare_enable(pcie->clk);
+
+ /* Take bridge out of reset so we can access the SERDES reg */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ /* SERDES_IDDQ = 0 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ brcm_pcie_setup_prep(pcie);
+
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ return ret;
+
+ pcie->suspended = false;
+
+ return 0;
+}
+
+/* Configuration space read/write support */
+static int cfg_index(int busnr, int devfn, int reg)
+{
+ return ((PCI_SLOT(devfn) & 0x1f) << PCI_SLOT_SHIFT)
+ | ((PCI_FUNC(devfn) & 0x07) << PCI_FUNC_SHIFT)
+ | (busnr << PCI_BUSNUM_SHIFT)
+ | (reg & ~3);
+}
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ struct brcm_pcie *pcie = bus->sysdata;
+ void __iomem *base = pcie->base;
+ bool rc_access = pci_is_root_bus(bus);
+ int idx;
+
+ if (!is_pcie_link_up(pcie, true))
+ return NULL;
+
+ base = pcie->base;
+ idx = cfg_index(bus->number, devfn, where);
+
+ bcm_writel(idx, pcie->base + IDX_ADDR(pcie));
+
+ if (rc_access) {
+ if (PCI_SLOT(devfn))
+ return NULL;
+ return base + (where & ~3);
+ }
+
+ return pcie->base + DATA_ADDR(pcie);
+}
+
+static void __attribute__((__section__("pci_fixup_early")))
+brcm_pcibios_fixup(struct pci_dev *dev)
+{
+ struct brcm_pcie *pcie = dev->bus->sysdata;
+ u8 slot = PCI_SLOT(dev->devfn);
+
+ dev_info(pcie->dev,
+ "found device %04x:%04x on bus %d (%s), slot %d (irq %d)\n",
+ dev->vendor, dev->device, dev->bus->number, pcie->name,
+ slot, of_irq_parse_and_map_pci(dev, slot, 1));
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, brcm_pcibios_fixup);
+
+static const struct of_device_id brcm_pci_match[] = {
+ { .compatible = "brcm,bcm7425-pcie", .data = &bcm7425_cfg },
+ { .compatible = "brcm,bcm7435-pcie", .data = &bcm7435_cfg },
+ { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,pci-plat-dev", .data = &generic_cfg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, brcm_pci_match);
+
+static void _brcm_pcie_remove(struct brcm_pcie *pcie)
+{
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ clk_put(pcie->clk);
+ set_regulators(pcie, false);
+ brcm_pcie_remove_controller(pcie);
+}
+
+static int brcm_pcie_probe(struct platform_device *pdev)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ const struct of_device_id *of_id;
+ const struct pcie_cfg_data *data;
+ int i, ret;
+ struct brcm_pcie *pcie;
+ struct resource *res;
+ void __iomem *base;
+ u32 tmp;
+ int supplies;
+ const char *name;
+ struct brcm_dev_pwr_supply *supply;
+ struct pci_host_bridge *bridge;
+ struct pci_bus *child;
+ u32 domain;
+
+ bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
+ if (!bridge)
+ return -ENOMEM;
+
+ pcie = pci_host_bridge_priv(bridge);
+ INIT_LIST_HEAD(&pcie->resources);
+
+ of_id = of_match_node(brcm_pci_match, dn);
+ if (!of_id) {
+ pr_err("failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
+ pr_err("cannot yet handle dma-ranges\n");
+ return -EINVAL;
+ }
+
+ data = of_id->data;
+ pcie->reg_offsets = data->offsets;
+ pcie->reg_field_info = data->reg_field_info;
+ pcie->type = data->type;
+ pcie->dn = dn;
+ pcie->dev = &pdev->dev;
+
+ if (of_property_read_u32(dn, "linux,pci-domain", &domain) == 0) {
+ pcie->id = (int)domain;
+ } else {
+ dev_err(pcie->dev, "linux,pci-domain prop missing\n");
+ return -EINVAL;
+ }
+
+ INIT_LIST_HEAD(&pcie->pwr_supplies);
+ supplies = of_property_count_strings(dn, "supply-names");
+ if (supplies <= 0)
+ supplies = 0;
+
+ for (i = 0; i < supplies; i++) {
+ if (of_property_read_string_index(dn, "supply-names", i,
+ &name))
+ continue;
+ supply = devm_kzalloc(&pdev->dev, sizeof(*supply), GFP_KERNEL);
+ if (!supply)
+ return -ENOMEM;
+ strncpy(supply->name, name, sizeof(supply->name));
+ supply->name[sizeof(supply->name) - 1] = '\0';
+ supply->regulator = devm_regulator_get(&pdev->dev, name);
+ if (IS_ERR(supply->regulator)) {
+ dev_err(&pdev->dev, "Unable to get %s supply, err=%d\n",
+ name, (int)PTR_ERR(supply->regulator));
+ continue;
+ }
+ list_add_tail(&supply->node, &pcie->pwr_supplies);
+ }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pcie->clk = of_clk_get_by_name(dn, "sw_pcie");
+ if (IS_ERR(pcie->clk)) {
+ dev_err(&pdev->dev, "could not get clock\n");
+ pcie->clk = NULL;
+ }
+ pcie->base = base;
+ pcie->gen = 0;
+
+ if (of_property_read_u32(dn, "brcm,gen", &tmp) == 0)
+ pcie->gen = tmp;
+
+ pcie->ssc = of_property_read_bool(dn, "brcm,ssc");
+
+ ret = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ if (ret == 0)
+ /* keep going, as we don't use this intr yet */
+ dev_warn(pcie->dev, "cannot get pcie interrupt\n");
+ else
+ pcie->irq = ret;
+
+ ret = brcm_parse_ranges(pcie);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(pcie->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "could not enable clock\n");
+ return ret;
+ }
+
+ ret = brcm_pcie_add_controller(pcie);
+ if (ret)
+ return ret;
+
+ set_regulators(pcie, true);
+ brcm_pcie_setup_prep(pcie);
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ goto fail;
+
+ list_splice_init(&pcie->resources, &bridge->windows);
+ bridge->dev.parent = &pdev->dev;
+ bridge->busnr = 0;
+ bridge->ops = &brcm_pci_ops;
+ bridge->sysdata = pcie;
+ bridge->map_irq = of_irq_parse_and_map_pci;
+ bridge->swizzle_irq = pci_common_swizzle;
+
+ ret = pci_scan_root_bus_bridge(bridge);
+ if (ret < 0) {
+ dev_err(pcie->dev, "Scanning root bridge failed");
+ goto fail;
+ }
+
+ pci_assign_unassigned_bus_resources(bridge->bus);
+ list_for_each_entry(child, &bridge->bus->children, node)
+ pcie_bus_configure_settings(child);
+ pci_bus_add_devices(bridge->bus);
+ platform_set_drvdata(pdev, pcie);
+ pcie->root_bus = bridge->bus;
+
+ return 0;
+
+fail:
+ _brcm_pcie_remove(pcie);
+ return ret;
+}
+
+static int brcm_pcie_remove(struct platform_device *pdev)
+{
+ struct brcm_pcie *pcie = platform_get_drvdata(pdev);
+
+ pci_stop_root_bus(pcie->root_bus);
+ pci_remove_root_bus(pcie->root_bus);
+ _brcm_pcie_remove(pcie);
+
+ return 0;
+}
+
+static const struct dev_pm_ops brcm_pcie_pm_ops = {
+ .suspend_noirq = brcm_pcie_suspend,
+ .resume_noirq = brcm_pcie_resume,
+};
+
+static struct platform_driver __refdata brcm_pci_driver = {
+ .probe = brcm_pcie_probe,
+ .remove = brcm_pcie_remove,
+ .driver = {
+ .name = "brcm-pci",
+ .owner = THIS_MODULE,
+ .of_match_table = brcm_pci_match,
+ .pm = &brcm_pcie_pm_ops,
+ },
+};
+
+module_platform_driver(brcm_pci_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Broadcom STB PCIE RC driver");
+MODULE_AUTHOR("Broadcom");
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
new file mode 100644
index 0000000..86f9cd1
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -0,0 +1,33 @@
+#ifndef __BRCMSTB_PCI_H
+#define __BRCMSTB_PCI_H
+
+/*
+ * Copyright (C) 2015 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define BRCM_PCIE_NAME_SIZE 8
+#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_PCIE_HW_REV_33 0x0303
+
+/* Broadcom PCIE Offsets */
+#define PCIE_INTR2_CPU_BASE 0x4300
+
+#if defined(CONFIG_MIPS)
+/* Broadcom MIPs HW implicitly does the swapping if necessary */
+#define bcm_readl(a) __raw_readl(a)
+#define bcm_writel(d, a) __raw_writel(d, a)
+#else
+#define bcm_readl(a) readl(a)
+#define bcm_writel(d, a) writel(d, a)
+#endif
+
+#endif /* __BRCMSTB_PCI_H */
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 3/9] PCI: host: brcmstb: Broadcom PCIe Host Controller
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Jim Quinlan, Brian Norris,
linux-arm-kernel
This commit adds the basic Broadcom STB PCIe controller. Missing is
the ability to process MSI and also handle dma-ranges for inbound
memory accesses. These two functionalities are added in subsequent
commits.
The PCIe block contains an MDIO interface. This is a local interface
only accessible by the PCIe controller. It cannot be used or shared
by any other HW. As such, the small amount of code for this
controller is included in this driver as there is little upside to put
it elsewhere.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Kconfig | 8 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-brcmstb.c | 1191 ++++++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.h | 33 ++
4 files changed, 1233 insertions(+)
create mode 100644 drivers/pci/host/pci-brcmstb.c
create mode 100644 drivers/pci/host/pci-brcmstb.h
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b868803..b9b4f11 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -220,4 +220,12 @@ config VMD
To compile this driver as a module, choose M here: the
module will be called vmd.
+config PCI_BRCMSTB
+ tristate "Broadcom Brcmstb PCIe platform host driver"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ depends on OF
+ depends on SOC_BRCMSTB
+ default ARCH_BRCMSTB || BMIPS_GENERIC
+ help
+ Adds support for Broadcom Settop Box PCIe host controller.
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 1238278..4398d2c 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
+obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
new file mode 100644
index 0000000..f4cd6e7
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -0,0 +1,1191 @@
+/*
+ * Copyright (C) 2009 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/clk.h>
+#include <linux/compiler.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/log2.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/printk.h>
+#include <linux/regulator/consumer.h>
+#include <linux/sizes.h>
+#include <linux/slab.h>
+#include <soc/brcmstb/memory_api.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include "pci-brcmstb.h"
+
+/* Broadcom Settop Box PCIE Register Offsets. */
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY 0x00b8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL 0x00bc
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL 0x00c8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2 0x00dc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
+#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
+#define PCIE_RC_DL_MDIO_ADDR 0x1100
+#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
+#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
+#define PCIE_MISC_MISC_CTRL 0x4008
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
+#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
+#define PCIE_MISC_RC_BAR1_CONFIG_HI 0x4030
+#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
+#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
+#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
+#define PCIE_MISC_RC_BAR3_CONFIG_HI 0x4040
+#define PCIE_MISC_PCIE_CTRL 0x4064
+#define PCIE_MISC_PCIE_STATUS 0x4068
+#define PCIE_MISC_REVISION 0x406c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
+
+/* Broadcom Settop Box PCIE Register Field Shift, Mask Info. */
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_MASK 0x3f00000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_SHIFT 0x14
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_MASK 0xf0000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_SHIFT 0x10
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_MASK 0x10
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_SHIFT 0x4
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_MASK 0x3
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_MASK 0x30
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_SHIFT 0x4
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x7c00000
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_SHIFT 0x16
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x1f
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_SHIFT 0x2
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
+#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
+#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
+#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
+#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
+
+#define BRCM_NUM_PCI_OUT_WINS 0x4
+#define BRCM_MAX_SCB 0x4
+
+#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
+#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
+
+#define BURST_SIZE_128 0
+#define BURST_SIZE_256 1
+#define BURST_SIZE_512 2
+
+/* Offsets from PCIE_INTR2_CPU_BASE */
+#define STATUS 0x0
+#define SET 0x4
+#define CLR 0x8
+#define MASK_STATUS 0xc
+#define MASK_SET 0x10
+#define MASK_CLR 0x14
+
+#define PCI_BUSNUM_SHIFT 20
+#define PCI_SLOT_SHIFT 15
+#define PCI_FUNC_SHIFT 12
+
+#if defined(__BIG_ENDIAN)
+#define DATA_ENDIAN 2 /* PCI->DDR inbound accesses */
+#define MMIO_ENDIAN 2 /* CPU->PCI outbound accesses */
+#else
+#define DATA_ENDIAN 0
+#define MMIO_ENDIAN 0
+#endif
+
+#define MDIO_PORT0 0x0
+#define MDIO_DATA_MASK 0x7fffffff
+#define MDIO_DATA_SHIFT 0x0
+#define MDIO_PORT_MASK 0xf0000
+#define MDIO_PORT_SHIFT 0x16
+#define MDIO_REGAD_MASK 0xffff
+#define MDIO_REGAD_SHIFT 0x0
+#define MDIO_CMD_MASK 0xfff00000
+#define MDIO_CMD_SHIFT 0x14
+#define MDIO_CMD_READ 0x1
+#define MDIO_CMD_WRITE 0x0
+#define MDIO_DATA_DONE_MASK 0x80000000
+#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
+#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
+#define SSC_REGS_ADDR 0x1100
+#define SET_ADDR_OFFSET 0x1f
+#define SSC_CNTL_OFFSET 0x2
+#define SSC_CNTL_OVRD_EN_MASK 0x8000
+#define SSC_CNTL_OVRD_EN_SHIFT 0xf
+#define SSC_CNTL_OVRD_VAL_MASK 0x4000
+#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
+#define SSC_STATUS_OFFSET 0x1
+#define SSC_STATUS_SSC_MASK 0x400
+#define SSC_STATUS_SSC_SHIFT 0xa
+#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
+
+#define IDX_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_INDEX])
+#define DATA_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_DATA])
+#define PCIE_RGR1_SW_INIT_1(pcie) \
+ ((pcie)->reg_offsets[RGR1_SW_INIT_1])
+
+enum {
+ RGR1_SW_INIT_1,
+ EXT_CFG_INDEX,
+ EXT_CFG_DATA,
+};
+
+enum {
+ RGR1_SW_INIT_1_INIT_MASK,
+ RGR1_SW_INIT_1_INIT_SHIFT,
+ RGR1_SW_INIT_1_PERST_MASK,
+ RGR1_SW_INIT_1_PERST_SHIFT,
+};
+
+enum pcie_type {
+ BCM7425,
+ BCM7435,
+ GENERIC,
+ BCM7278,
+};
+
+#define RD_FLD(base, reg, field) \
+ rd_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT)
+#define WR_FLD(base, reg, field, val) \
+ wr_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_RB(base, reg, field, val) \
+ wr_fld_rb(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
+ wr_fld(base + reg + off, reg##_##field##_MASK, \
+ reg##_##field##_SHIFT, val)
+#define EXTRACT_FIELD(val, reg, field) \
+ ((val & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
+#define INSERT_FIELD(val, reg, field, field_val) \
+ ((val & ~reg##_##field##_MASK) | \
+ (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
+
+struct pcie_cfg_data {
+ const int *reg_field_info;
+ const int *offsets;
+ const enum pcie_type type;
+};
+
+static const int pcie_reg_field_info[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
+};
+
+static const int pcie_reg_field_info_bcm7278[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
+};
+
+static const int pcie_offset_bcm7425[] = {
+ [RGR1_SW_INIT_1] = 0x8010,
+ [EXT_CFG_INDEX] = 0x8300,
+ [EXT_CFG_DATA] = 0x8304,
+};
+
+static const struct pcie_cfg_data bcm7425_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offset_bcm7425,
+ .type = BCM7425,
+};
+
+static const int pcie_offsets[] = {
+ [RGR1_SW_INIT_1] = 0x9210,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7435_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = BCM7435,
+};
+
+static const struct pcie_cfg_data generic_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = GENERIC,
+};
+
+static const int pcie_offset_bcm7278[] = {
+ [RGR1_SW_INIT_1] = 0xc010,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7278_cfg = {
+ .reg_field_info = pcie_reg_field_info_bcm7278,
+ .offsets = pcie_offset_bcm7278,
+ .type = BCM7278,
+};
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where);
+
+static struct pci_ops brcm_pci_ops = {
+ .map_bus = brcm_pci_map_cfg,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+struct brcm_dev_pwr_supply {
+ struct list_head node;
+ char name[32];
+ struct regulator *regulator;
+};
+
+struct brcm_window {
+ dma_addr_t pci_addr;
+ phys_addr_t cpu_addr;
+ dma_addr_t size;
+};
+
+/* Internal Bus Controller Information.*/
+struct brcm_pcie {
+ struct list_head list;
+ void __iomem *base;
+ char name[BRCM_PCIE_NAME_SIZE];
+ bool suspended;
+ struct clk *clk;
+ struct device_node *dn;
+ int irq;
+ int num_out_wins;
+ bool ssc;
+ int gen;
+ struct brcm_window out_wins[BRCM_NUM_PCI_OUT_WINS];
+ struct list_head resources;
+ struct device *dev;
+ struct list_head pwr_supplies;
+ unsigned int rev;
+ unsigned int num;
+ bool bridge_setup_done;
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
+ struct pci_bus *root_bus;
+ int id;
+};
+
+static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
+static phys_addr_t scb_size[BRCM_MAX_SCB];
+static int num_memc;
+static DEFINE_MUTEX(brcm_pcie_lock);
+
+/*
+ * The roundup_pow_of_two() from log2.h invokes
+ * __roundup_pow_of_two(unsigned long), but we really need a
+ * such a function to take a native u64 since unsigned long
+ * is 32 bits on some configurations. So we provide this helper
+ * function below.
+ */
+static u64 roundup_pow_of_two_64(u64 n)
+{
+ return 1ULL << fls64(n - 1);
+}
+
+static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
+{
+ mutex_lock(&brcm_pcie_lock);
+ snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
+ list_add_tail(&pcie->list, &brcm_pcie);
+ mutex_unlock(&brcm_pcie_lock);
+
+ return 0;
+}
+
+static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
+{
+ struct list_head *pos, *q;
+ struct brcm_pcie *tmp;
+
+ mutex_lock(&brcm_pcie_lock);
+ list_for_each_safe(pos, q, &brcm_pcie) {
+ tmp = list_entry(pos, struct brcm_pcie, list);
+ if (tmp == pcie) {
+ list_del(pos);
+ if (list_empty(&brcm_pcie))
+ num_memc = 0;
+ break;
+ }
+ }
+ mutex_unlock(&brcm_pcie_lock);
+}
+
+/* This is to convert the size of the inbound bar region to the
+ * non-liniear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
+ */
+int encode_ibar_size(u64 size)
+{
+ int log2_in = ilog2(size);
+
+ if (log2_in >= 12 && log2_in <= 15)
+ /* Covers 4KB to 32KB (inclusive) */
+ return (log2_in - 12) + 0x1c;
+ else if (log2_in >= 16 && log2_in <= 37)
+ /* Covers 64KB to 32GB, (inclusive) */
+ return log2_in - 15;
+ /* Something is awry so disable */
+ return 0;
+}
+
+static u32 mdio_form_pkt(int port, int regad, int cmd)
+{
+ u32 pkt = 0;
+
+ pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
+ pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
+ pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
+
+ return pkt;
+}
+
+/* negative return value indicates error */
+static int mdio_read(void __iomem *base, u8 port, u8 regad)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_READ),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ }
+
+ return MDIO_RD_DONE(data)
+ ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
+ : -EIO;
+}
+
+/* negative return value indicates error */
+static int mdio_write(void __iomem *base, u8 port, u8 regad, u16 wrdata)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
+ base + PCIE_RC_DL_MDIO_WR_DATA);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ }
+
+ return MDIO_WT_DONE(data) ? 0 : -EIO;
+}
+
+static u32 rd_fld(void __iomem *p, u32 mask, int shift)
+{
+ return (bcm_readl(p) & mask) >> shift;
+}
+
+static void wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ u32 reg = bcm_readl(p);
+
+ reg = (reg & ~mask) | ((val << shift) & mask);
+ bcm_writel(reg, p);
+}
+
+static void wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ wr_fld(p, mask, shift, val);
+ (void)bcm_readl(p);
+}
+
+/* configures device for ssc mode; negative return value indicates error */
+static int set_ssc(void __iomem *base)
+{
+ int tmp;
+ u16 wrdata;
+ int pll, ssc;
+
+ tmp = mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET, SSC_REGS_ADDR);
+ if (tmp < 0)
+ return tmp;
+
+ tmp = mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
+ wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
+ tmp = mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
+ if (tmp < 0)
+ return tmp;
+
+ usleep_range(1000, 2000);
+ tmp = mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
+ pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
+
+ return (ssc && pll) ? 0 : -EIO;
+}
+
+/* limits operation to a specific generation (1, 2, or 3) */
+static void set_gen(void __iomem *base, int gen)
+{
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_CAPABILITY, MAX_LINK_SPEED, gen);
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2,
+ TARGET_LINK_SPEED, gen);
+}
+
+static void set_pcie_outbound_win(struct brcm_pcie *pcie, unsigned int win,
+ phys_addr_t cpu_addr, dma_addr_t pci_addr,
+ dma_addr_t size)
+{
+ void __iomem *base = pcie->base;
+ phys_addr_t cpu_addr_mb, limit_addr_mb;
+ u32 tmp;
+
+ /* Set the base of the pci_addr window */
+ bcm_writel(lower_32_bits(pci_addr) + MMIO_ENDIAN,
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
+ bcm_writel(upper_32_bits(pci_addr),
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
+
+ cpu_addr_mb = cpu_addr >> 20;
+ limit_addr_mb = (cpu_addr + size - 1) >> 20;
+
+ /* Write the addr base low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ BASE, cpu_addr_mb);
+ /* Write the addr limit low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ LIMIT, limit_addr_mb);
+
+ if (pcie->type != BCM7435 && pcie->type != BCM7425) {
+ /* Write the cpu addr high register */
+ tmp = (u32)(cpu_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
+ BASE, tmp);
+ /* Write the cpu limit high register */
+ tmp = (u32)(limit_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
+ LIMIT, tmp);
+ }
+}
+
+static int is_pcie_link_up(struct brcm_pcie *pcie, bool silent)
+{
+ void __iomem *base = pcie->base;
+ u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
+ u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
+ u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
+ u32 rc = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
+
+ if (!rc && !silent)
+ dev_err(pcie->dev, "controller configured in EP mode\n");
+
+ return (rc && dla && plu) ? 1 : 0;
+}
+
+static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ unsigned int offset;
+ unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
+ u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
+
+ if (pcie->type != BCM7278) {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ } else if (of_machine_is_compatible("brcm,bcm7278a0")) {
+ /* The two PCIE instance on 7278a0 are not even consistent with
+ * respect to each other for internal offsets, here we offset
+ * by 0x14000 + RGR1_SW_INIT_1's relative offset to account for
+ * that.
+ */
+ offset = pcie->id ? 0x14010 : pcie->reg_offsets[RGR1_SW_INIT_1];
+ wr_fld_rb(pcie->base + offset, mask, shift, val);
+ } else {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ }
+}
+
+static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ if (pcie->type != BCM7278)
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie),
+ PCIE_RGR1_SW_INIT_1_PERST_MASK,
+ PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
+ else
+ /* Assert = 0, de-assert = 1 on 7278 */
+ WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
+}
+
+static int brcm_parse_ranges(struct brcm_pcie *pcie)
+{
+ struct resource_entry *win;
+ int ret;
+
+ ret = of_pci_get_host_bridge_resources(pcie->dn, 0, 0xff,
+ &pcie->resources, NULL);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get host resources\n");
+ return ret;
+ }
+
+ resource_list_for_each_entry(win, &pcie->resources) {
+ struct resource *parent, *res = win->res;
+ dma_addr_t offset = (dma_addr_t)win->offset;
+
+ if (resource_type(res) == IORESOURCE_IO) {
+ parent = &ioport_resource;
+ } else if (resource_type(res) == IORESOURCE_MEM) {
+ if (pcie->num_out_wins >= BRCM_NUM_PCI_OUT_WINS) {
+ dev_err(pcie->dev, "too many outbound wins\n");
+ return -EINVAL;
+ }
+ pcie->out_wins[pcie->num_out_wins].cpu_addr
+ = (phys_addr_t)res->start;
+ pcie->out_wins[pcie->num_out_wins].pci_addr
+ = (dma_addr_t)(res->start
+ - (phys_addr_t)offset);
+ pcie->out_wins[pcie->num_out_wins].size
+ = (dma_addr_t)(res->end - res->start + 1);
+ pcie->num_out_wins++;
+ parent = &iomem_resource;
+ } else {
+ continue;
+ }
+
+ ret = devm_request_resource(pcie->dev, parent, res);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get res %pR\n", res);
+ return ret;
+ }
+ }
+ return 0;
+}
+
+static void set_regulators(struct brcm_pcie *pcie, bool on)
+{
+ struct list_head *pos;
+
+ list_for_each(pos, &pcie->pwr_supplies) {
+ struct brcm_dev_pwr_supply *supply
+ = list_entry(pos, struct brcm_dev_pwr_supply, node);
+
+ if (on && regulator_enable(supply->regulator))
+ pr_debug("Unable to turn on %s supply.\n",
+ supply->name);
+ else if (!on && regulator_disable(supply->regulator))
+ pr_debug("Unable to turn off %s supply.\n",
+ supply->name);
+ }
+}
+
+static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ unsigned int scb_size_val;
+ u64 rc_bar2_size = 0, rc_bar2_offset = 0, total_mem_size = 0;
+ u32 tmp, burst;
+ int i;
+
+ /* reset the bridge and the endpoint device */
+ /* field: PCIE_BRIDGE_SW_INIT = 1 */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+
+ /* field: PCIE_SW_PERST = 1, on 7278, we start de-asserted already */
+ if (pcie->type != BCM7278)
+ brcm_pcie_perst_set(pcie, 1);
+
+ usleep_range(100, 200);
+
+ /* take the bridge out of reset */
+ /* field: PCIE_BRIDGE_SW_INIT = 0 */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ /* Grab the PCIe hw revision number */
+ tmp = bcm_readl(base + PCIE_MISC_REVISION);
+ pcie->rev = EXTRACT_FIELD(tmp, PCIE_MISC_REVISION, MAJMIN);
+
+ /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
+ tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
+ burst = (pcie->type == GENERIC || pcie->type == BCM7278)
+ ? BURST_SIZE_512 : BURST_SIZE_256;
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE, burst);
+ bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
+
+ /* Set up inbound memory view for the EP (called RC_BAR2,
+ * not to be confused with the BARs that are advertised by
+ * the EP).
+ */
+ for (i = 0; i < num_memc; i++)
+ total_mem_size += scb_size[i];
+
+ /* The PCI host controller by design must set the inbound
+ * viewport to be a contiguous arrangement of all of the
+ * system's memory. In addition, its size mut be a power of
+ * two. To further complicate matters, the viewport must
+ * start on a pci-address that is aligned on a multiple of its
+ * size. If a portion of the viewport does not represent
+ * system memory -- e.g. 3GB of memory requires a 4GB viewport
+ * -- we can map the outbound memory in or after 3GB and even
+ * though the viewport will overlap the outbound memory the
+ * controller will know to send outbound memory downstream and
+ * everything else upstream.
+ */
+ rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
+
+ /* Set simple configuration based on memory sizes
+ * only. We always start the viewport at address 0.
+ */
+ rc_bar2_offset = 0;
+
+ tmp = lower_32_bits(rc_bar2_offset);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
+ encode_ibar_size(rc_bar2_size));
+ bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
+ bcm_writel(upper_32_bits(rc_bar2_offset),
+ base + PCIE_MISC_RC_BAR2_CONFIG_HI);
+
+ /* field: SCB0_SIZE, default = 0xf (1 GB) */
+ scb_size_val = scb_size[0]
+ ? ilog2(scb_size[0]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
+
+ /* field: SCB1_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 1) {
+ scb_size_val = scb_size[1]
+ ? ilog2(scb_size[1]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB1_SIZE, scb_size_val);
+ }
+
+ /* field: SCB2_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 2) {
+ scb_size_val = scb_size[2]
+ ? ilog2(scb_size[2]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB2_SIZE, scb_size_val);
+ }
+
+ /* disable the PCIE->GISB memory window (RC_BAR1) */
+ WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
+
+ /* disable the PCIE->SCB memory window (RC_BAR3) */
+ WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
+
+ if (!pcie->suspended) {
+ /* clear any interrupts we find on boot */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
+ }
+
+ /* Mask all interrupts since we are not handling any yet */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
+
+ if (pcie->gen)
+ set_gen(base, pcie->gen);
+
+ /* take the EP device out of reset */
+ /* field: PCIE_SW_PERST = 0 */
+ brcm_pcie_perst_set(pcie, 0);
+}
+
+static const char *link_speed_to_str(int s)
+{
+ switch (s) {
+ case 1:
+ return "2.5";
+ case 2:
+ return "5.0";
+ case 3:
+ return "8.0";
+ default:
+ break;
+ }
+ return "???";
+}
+
+static int brcm_pcie_setup_bridge(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ const int limit = pcie->suspended ? 1000 : 100;
+ unsigned int status;
+ int i, j, ret;
+ u32 neg_width, neg_speed;
+ bool ssc_good = false;
+
+ /* Give the RC/EP time to wake up, before trying to configure RC.
+ * Intermittently check status for link-up, up to a total of 100ms
+ * when we don't know if the device is there, and up to 1000ms if
+ * we do know the device is there.
+ */
+ for (i = 1, j = 0; j < limit && !is_pcie_link_up(pcie, true);
+ j += i, i = i * 2)
+ msleep(i + j > limit ? limit - j : i);
+
+ if (!is_pcie_link_up(pcie, false)) {
+ dev_info(pcie->dev, "link down\n");
+ return -ENODEV;
+ }
+
+ for (i = 0; i < pcie->num_out_wins; i++)
+ set_pcie_outbound_win(pcie, i, pcie->out_wins[i].cpu_addr,
+ pcie->out_wins[i].pci_addr,
+ pcie->out_wins[i].size);
+
+ /* For config space accesses on the RC, show the right class for
+ * a PCI-PCI bridge
+ */
+ WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
+
+ if (pcie->ssc) {
+ ret = set_ssc(base);
+ if (ret == 0)
+ ssc_good = true;
+ else
+ dev_err(pcie->dev,
+ "failed attempt to enter ssc mode\n");
+ }
+
+ status = bcm_readl(base + PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL);
+ neg_width = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_WIDTH);
+ neg_speed = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_SPEED);
+ dev_info(pcie->dev, "link up, %s Gbps x%u %s\n",
+ link_speed_to_str(neg_speed), neg_width,
+ ssc_good ? "(SSC)" : "(!SSC)");
+
+ /* Enable configuration request retry (see pci_scan_device()) */
+ /* field RC_CRS_EN = 1 */
+ WR_FLD(base, PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL, RC_CRS_EN, 1);
+
+ /* PCIE->SCB endian mode for BAR */
+ /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
+ WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
+ ENDIAN_MODE_BAR2, DATA_ENDIAN);
+
+ /* Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
+ * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
+ */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
+
+ pcie->bridge_setup_done = true;
+
+ return 0;
+}
+
+static void enter_l23(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ int tries, l23;
+
+ /* assert request for L23 */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
+ /* poll L23 status */
+ for (tries = 0, l23 = 0; tries < 1000 && !l23; tries++)
+ l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
+ if (!l23)
+ dev_err(pcie->dev, "failed to enter L23\n");
+}
+
+static void turn_off(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+
+ if (is_pcie_link_up(pcie, true))
+ enter_l23(pcie);
+ /* Reset endpoint device */
+ brcm_pcie_perst_set(pcie, 1);
+ /* deassert request for L23 in case it was asserted */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
+ /* SERDES_IDDQ = 1 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
+ /* Shutdown PCIe bridge */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+}
+
+static int brcm_pcie_suspend(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ set_regulators(pcie, false);
+ pcie->suspended = true;
+
+ return 0;
+}
+
+static int brcm_pcie_resume(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ void __iomem *base;
+ int ret;
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ base = pcie->base;
+ set_regulators(pcie, true);
+ clk_prepare_enable(pcie->clk);
+
+ /* Take bridge out of reset so we can access the SERDES reg */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ /* SERDES_IDDQ = 0 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ brcm_pcie_setup_prep(pcie);
+
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ return ret;
+
+ pcie->suspended = false;
+
+ return 0;
+}
+
+/* Configuration space read/write support */
+static int cfg_index(int busnr, int devfn, int reg)
+{
+ return ((PCI_SLOT(devfn) & 0x1f) << PCI_SLOT_SHIFT)
+ | ((PCI_FUNC(devfn) & 0x07) << PCI_FUNC_SHIFT)
+ | (busnr << PCI_BUSNUM_SHIFT)
+ | (reg & ~3);
+}
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ struct brcm_pcie *pcie = bus->sysdata;
+ void __iomem *base = pcie->base;
+ bool rc_access = pci_is_root_bus(bus);
+ int idx;
+
+ if (!is_pcie_link_up(pcie, true))
+ return NULL;
+
+ base = pcie->base;
+ idx = cfg_index(bus->number, devfn, where);
+
+ bcm_writel(idx, pcie->base + IDX_ADDR(pcie));
+
+ if (rc_access) {
+ if (PCI_SLOT(devfn))
+ return NULL;
+ return base + (where & ~3);
+ }
+
+ return pcie->base + DATA_ADDR(pcie);
+}
+
+static void __attribute__((__section__("pci_fixup_early")))
+brcm_pcibios_fixup(struct pci_dev *dev)
+{
+ struct brcm_pcie *pcie = dev->bus->sysdata;
+ u8 slot = PCI_SLOT(dev->devfn);
+
+ dev_info(pcie->dev,
+ "found device %04x:%04x on bus %d (%s), slot %d (irq %d)\n",
+ dev->vendor, dev->device, dev->bus->number, pcie->name,
+ slot, of_irq_parse_and_map_pci(dev, slot, 1));
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, brcm_pcibios_fixup);
+
+static const struct of_device_id brcm_pci_match[] = {
+ { .compatible = "brcm,bcm7425-pcie", .data = &bcm7425_cfg },
+ { .compatible = "brcm,bcm7435-pcie", .data = &bcm7435_cfg },
+ { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,pci-plat-dev", .data = &generic_cfg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, brcm_pci_match);
+
+static void _brcm_pcie_remove(struct brcm_pcie *pcie)
+{
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ clk_put(pcie->clk);
+ set_regulators(pcie, false);
+ brcm_pcie_remove_controller(pcie);
+}
+
+static int brcm_pcie_probe(struct platform_device *pdev)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ const struct of_device_id *of_id;
+ const struct pcie_cfg_data *data;
+ int i, ret;
+ struct brcm_pcie *pcie;
+ struct resource *res;
+ void __iomem *base;
+ u32 tmp;
+ int supplies;
+ const char *name;
+ struct brcm_dev_pwr_supply *supply;
+ struct pci_host_bridge *bridge;
+ struct pci_bus *child;
+ u32 domain;
+
+ bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
+ if (!bridge)
+ return -ENOMEM;
+
+ pcie = pci_host_bridge_priv(bridge);
+ INIT_LIST_HEAD(&pcie->resources);
+
+ of_id = of_match_node(brcm_pci_match, dn);
+ if (!of_id) {
+ pr_err("failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
+ pr_err("cannot yet handle dma-ranges\n");
+ return -EINVAL;
+ }
+
+ data = of_id->data;
+ pcie->reg_offsets = data->offsets;
+ pcie->reg_field_info = data->reg_field_info;
+ pcie->type = data->type;
+ pcie->dn = dn;
+ pcie->dev = &pdev->dev;
+
+ if (of_property_read_u32(dn, "linux,pci-domain", &domain) == 0) {
+ pcie->id = (int)domain;
+ } else {
+ dev_err(pcie->dev, "linux,pci-domain prop missing\n");
+ return -EINVAL;
+ }
+
+ INIT_LIST_HEAD(&pcie->pwr_supplies);
+ supplies = of_property_count_strings(dn, "supply-names");
+ if (supplies <= 0)
+ supplies = 0;
+
+ for (i = 0; i < supplies; i++) {
+ if (of_property_read_string_index(dn, "supply-names", i,
+ &name))
+ continue;
+ supply = devm_kzalloc(&pdev->dev, sizeof(*supply), GFP_KERNEL);
+ if (!supply)
+ return -ENOMEM;
+ strncpy(supply->name, name, sizeof(supply->name));
+ supply->name[sizeof(supply->name) - 1] = '\0';
+ supply->regulator = devm_regulator_get(&pdev->dev, name);
+ if (IS_ERR(supply->regulator)) {
+ dev_err(&pdev->dev, "Unable to get %s supply, err=%d\n",
+ name, (int)PTR_ERR(supply->regulator));
+ continue;
+ }
+ list_add_tail(&supply->node, &pcie->pwr_supplies);
+ }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pcie->clk = of_clk_get_by_name(dn, "sw_pcie");
+ if (IS_ERR(pcie->clk)) {
+ dev_err(&pdev->dev, "could not get clock\n");
+ pcie->clk = NULL;
+ }
+ pcie->base = base;
+ pcie->gen = 0;
+
+ if (of_property_read_u32(dn, "brcm,gen", &tmp) == 0)
+ pcie->gen = tmp;
+
+ pcie->ssc = of_property_read_bool(dn, "brcm,ssc");
+
+ ret = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ if (ret == 0)
+ /* keep going, as we don't use this intr yet */
+ dev_warn(pcie->dev, "cannot get pcie interrupt\n");
+ else
+ pcie->irq = ret;
+
+ ret = brcm_parse_ranges(pcie);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(pcie->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "could not enable clock\n");
+ return ret;
+ }
+
+ ret = brcm_pcie_add_controller(pcie);
+ if (ret)
+ return ret;
+
+ set_regulators(pcie, true);
+ brcm_pcie_setup_prep(pcie);
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ goto fail;
+
+ list_splice_init(&pcie->resources, &bridge->windows);
+ bridge->dev.parent = &pdev->dev;
+ bridge->busnr = 0;
+ bridge->ops = &brcm_pci_ops;
+ bridge->sysdata = pcie;
+ bridge->map_irq = of_irq_parse_and_map_pci;
+ bridge->swizzle_irq = pci_common_swizzle;
+
+ ret = pci_scan_root_bus_bridge(bridge);
+ if (ret < 0) {
+ dev_err(pcie->dev, "Scanning root bridge failed");
+ goto fail;
+ }
+
+ pci_assign_unassigned_bus_resources(bridge->bus);
+ list_for_each_entry(child, &bridge->bus->children, node)
+ pcie_bus_configure_settings(child);
+ pci_bus_add_devices(bridge->bus);
+ platform_set_drvdata(pdev, pcie);
+ pcie->root_bus = bridge->bus;
+
+ return 0;
+
+fail:
+ _brcm_pcie_remove(pcie);
+ return ret;
+}
+
+static int brcm_pcie_remove(struct platform_device *pdev)
+{
+ struct brcm_pcie *pcie = platform_get_drvdata(pdev);
+
+ pci_stop_root_bus(pcie->root_bus);
+ pci_remove_root_bus(pcie->root_bus);
+ _brcm_pcie_remove(pcie);
+
+ return 0;
+}
+
+static const struct dev_pm_ops brcm_pcie_pm_ops = {
+ .suspend_noirq = brcm_pcie_suspend,
+ .resume_noirq = brcm_pcie_resume,
+};
+
+static struct platform_driver __refdata brcm_pci_driver = {
+ .probe = brcm_pcie_probe,
+ .remove = brcm_pcie_remove,
+ .driver = {
+ .name = "brcm-pci",
+ .owner = THIS_MODULE,
+ .of_match_table = brcm_pci_match,
+ .pm = &brcm_pcie_pm_ops,
+ },
+};
+
+module_platform_driver(brcm_pci_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Broadcom STB PCIE RC driver");
+MODULE_AUTHOR("Broadcom");
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
new file mode 100644
index 0000000..86f9cd1
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -0,0 +1,33 @@
+#ifndef __BRCMSTB_PCI_H
+#define __BRCMSTB_PCI_H
+
+/*
+ * Copyright (C) 2015 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define BRCM_PCIE_NAME_SIZE 8
+#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_PCIE_HW_REV_33 0x0303
+
+/* Broadcom PCIE Offsets */
+#define PCIE_INTR2_CPU_BASE 0x4300
+
+#if defined(CONFIG_MIPS)
+/* Broadcom MIPs HW implicitly does the swapping if necessary */
+#define bcm_readl(a) __raw_readl(a)
+#define bcm_writel(d, a) __raw_writel(d, a)
+#else
+#define bcm_readl(a) readl(a)
+#define bcm_writel(d, a) writel(d, a)
+#endif
+
+#endif /* __BRCMSTB_PCI_H */
--
1.9.0.138.g2de3478
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 3/9] PCI: host: brcmstb: Broadcom PCIe Host Controller
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds the basic Broadcom STB PCIe controller. Missing is
the ability to process MSI and also handle dma-ranges for inbound
memory accesses. These two functionalities are added in subsequent
commits.
The PCIe block contains an MDIO interface. This is a local interface
only accessible by the PCIe controller. It cannot be used or shared
by any other HW. As such, the small amount of code for this
controller is included in this driver as there is little upside to put
it elsewhere.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Kconfig | 8 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-brcmstb.c | 1191 ++++++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.h | 33 ++
4 files changed, 1233 insertions(+)
create mode 100644 drivers/pci/host/pci-brcmstb.c
create mode 100644 drivers/pci/host/pci-brcmstb.h
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b868803..b9b4f11 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -220,4 +220,12 @@ config VMD
To compile this driver as a module, choose M here: the
module will be called vmd.
+config PCI_BRCMSTB
+ tristate "Broadcom Brcmstb PCIe platform host driver"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ depends on OF
+ depends on SOC_BRCMSTB
+ default ARCH_BRCMSTB || BMIPS_GENERIC
+ help
+ Adds support for Broadcom Settop Box PCIe host controller.
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 1238278..4398d2c 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
+obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
new file mode 100644
index 0000000..f4cd6e7
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -0,0 +1,1191 @@
+/*
+ * Copyright (C) 2009 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/clk.h>
+#include <linux/compiler.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/log2.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/printk.h>
+#include <linux/regulator/consumer.h>
+#include <linux/sizes.h>
+#include <linux/slab.h>
+#include <soc/brcmstb/memory_api.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include "pci-brcmstb.h"
+
+/* Broadcom Settop Box PCIE Register Offsets. */
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY 0x00b8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL 0x00bc
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL 0x00c8
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2 0x00dc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
+#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
+#define PCIE_RC_DL_MDIO_ADDR 0x1100
+#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
+#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
+#define PCIE_MISC_MISC_CTRL 0x4008
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
+#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
+#define PCIE_MISC_RC_BAR1_CONFIG_HI 0x4030
+#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
+#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
+#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
+#define PCIE_MISC_RC_BAR3_CONFIG_HI 0x4040
+#define PCIE_MISC_PCIE_CTRL 0x4064
+#define PCIE_MISC_PCIE_STATUS 0x4068
+#define PCIE_MISC_REVISION 0x406c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
+
+/* Broadcom Settop Box PCIE Register Field Shift, Mask Info. */
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_MASK 0x3f00000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_WIDTH_SHIFT 0x14
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_MASK 0xf0000
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_NEG_LINK_SPEED_SHIFT 0x10
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_CAPABILITY_MAX_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_MASK 0x10
+#define PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL_RC_CRS_EN_SHIFT 0x4
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_MASK 0xf
+#define PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2_TARGET_LINK_SPEED_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_MASK 0x3
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR1_SHIFT 0x0
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_MASK 0x30
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR3_SHIFT 0x4
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x7c00000
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_SHIFT 0x16
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x1f
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_MASK 0xfffff000
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_MATCH_ADDRESS_SHIFT 0xc
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_SHIFT 0x2
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
+#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
+#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
+#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
+#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
+
+#define BRCM_NUM_PCI_OUT_WINS 0x4
+#define BRCM_MAX_SCB 0x4
+
+#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
+#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
+
+#define BURST_SIZE_128 0
+#define BURST_SIZE_256 1
+#define BURST_SIZE_512 2
+
+/* Offsets from PCIE_INTR2_CPU_BASE */
+#define STATUS 0x0
+#define SET 0x4
+#define CLR 0x8
+#define MASK_STATUS 0xc
+#define MASK_SET 0x10
+#define MASK_CLR 0x14
+
+#define PCI_BUSNUM_SHIFT 20
+#define PCI_SLOT_SHIFT 15
+#define PCI_FUNC_SHIFT 12
+
+#if defined(__BIG_ENDIAN)
+#define DATA_ENDIAN 2 /* PCI->DDR inbound accesses */
+#define MMIO_ENDIAN 2 /* CPU->PCI outbound accesses */
+#else
+#define DATA_ENDIAN 0
+#define MMIO_ENDIAN 0
+#endif
+
+#define MDIO_PORT0 0x0
+#define MDIO_DATA_MASK 0x7fffffff
+#define MDIO_DATA_SHIFT 0x0
+#define MDIO_PORT_MASK 0xf0000
+#define MDIO_PORT_SHIFT 0x16
+#define MDIO_REGAD_MASK 0xffff
+#define MDIO_REGAD_SHIFT 0x0
+#define MDIO_CMD_MASK 0xfff00000
+#define MDIO_CMD_SHIFT 0x14
+#define MDIO_CMD_READ 0x1
+#define MDIO_CMD_WRITE 0x0
+#define MDIO_DATA_DONE_MASK 0x80000000
+#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
+#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
+#define SSC_REGS_ADDR 0x1100
+#define SET_ADDR_OFFSET 0x1f
+#define SSC_CNTL_OFFSET 0x2
+#define SSC_CNTL_OVRD_EN_MASK 0x8000
+#define SSC_CNTL_OVRD_EN_SHIFT 0xf
+#define SSC_CNTL_OVRD_VAL_MASK 0x4000
+#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
+#define SSC_STATUS_OFFSET 0x1
+#define SSC_STATUS_SSC_MASK 0x400
+#define SSC_STATUS_SSC_SHIFT 0xa
+#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
+
+#define IDX_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_INDEX])
+#define DATA_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_DATA])
+#define PCIE_RGR1_SW_INIT_1(pcie) \
+ ((pcie)->reg_offsets[RGR1_SW_INIT_1])
+
+enum {
+ RGR1_SW_INIT_1,
+ EXT_CFG_INDEX,
+ EXT_CFG_DATA,
+};
+
+enum {
+ RGR1_SW_INIT_1_INIT_MASK,
+ RGR1_SW_INIT_1_INIT_SHIFT,
+ RGR1_SW_INIT_1_PERST_MASK,
+ RGR1_SW_INIT_1_PERST_SHIFT,
+};
+
+enum pcie_type {
+ BCM7425,
+ BCM7435,
+ GENERIC,
+ BCM7278,
+};
+
+#define RD_FLD(base, reg, field) \
+ rd_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT)
+#define WR_FLD(base, reg, field, val) \
+ wr_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_RB(base, reg, field, val) \
+ wr_fld_rb(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
+#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
+ wr_fld(base + reg + off, reg##_##field##_MASK, \
+ reg##_##field##_SHIFT, val)
+#define EXTRACT_FIELD(val, reg, field) \
+ ((val & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
+#define INSERT_FIELD(val, reg, field, field_val) \
+ ((val & ~reg##_##field##_MASK) | \
+ (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
+
+struct pcie_cfg_data {
+ const int *reg_field_info;
+ const int *offsets;
+ const enum pcie_type type;
+};
+
+static const int pcie_reg_field_info[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
+};
+
+static const int pcie_reg_field_info_bcm7278[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
+};
+
+static const int pcie_offset_bcm7425[] = {
+ [RGR1_SW_INIT_1] = 0x8010,
+ [EXT_CFG_INDEX] = 0x8300,
+ [EXT_CFG_DATA] = 0x8304,
+};
+
+static const struct pcie_cfg_data bcm7425_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offset_bcm7425,
+ .type = BCM7425,
+};
+
+static const int pcie_offsets[] = {
+ [RGR1_SW_INIT_1] = 0x9210,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7435_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = BCM7435,
+};
+
+static const struct pcie_cfg_data generic_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = GENERIC,
+};
+
+static const int pcie_offset_bcm7278[] = {
+ [RGR1_SW_INIT_1] = 0xc010,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7278_cfg = {
+ .reg_field_info = pcie_reg_field_info_bcm7278,
+ .offsets = pcie_offset_bcm7278,
+ .type = BCM7278,
+};
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where);
+
+static struct pci_ops brcm_pci_ops = {
+ .map_bus = brcm_pci_map_cfg,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+struct brcm_dev_pwr_supply {
+ struct list_head node;
+ char name[32];
+ struct regulator *regulator;
+};
+
+struct brcm_window {
+ dma_addr_t pci_addr;
+ phys_addr_t cpu_addr;
+ dma_addr_t size;
+};
+
+/* Internal Bus Controller Information.*/
+struct brcm_pcie {
+ struct list_head list;
+ void __iomem *base;
+ char name[BRCM_PCIE_NAME_SIZE];
+ bool suspended;
+ struct clk *clk;
+ struct device_node *dn;
+ int irq;
+ int num_out_wins;
+ bool ssc;
+ int gen;
+ struct brcm_window out_wins[BRCM_NUM_PCI_OUT_WINS];
+ struct list_head resources;
+ struct device *dev;
+ struct list_head pwr_supplies;
+ unsigned int rev;
+ unsigned int num;
+ bool bridge_setup_done;
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
+ struct pci_bus *root_bus;
+ int id;
+};
+
+static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
+static phys_addr_t scb_size[BRCM_MAX_SCB];
+static int num_memc;
+static DEFINE_MUTEX(brcm_pcie_lock);
+
+/*
+ * The roundup_pow_of_two() from log2.h invokes
+ * __roundup_pow_of_two(unsigned long), but we really need a
+ * such a function to take a native u64 since unsigned long
+ * is 32 bits on some configurations. So we provide this helper
+ * function below.
+ */
+static u64 roundup_pow_of_two_64(u64 n)
+{
+ return 1ULL << fls64(n - 1);
+}
+
+static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
+{
+ mutex_lock(&brcm_pcie_lock);
+ snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
+ list_add_tail(&pcie->list, &brcm_pcie);
+ mutex_unlock(&brcm_pcie_lock);
+
+ return 0;
+}
+
+static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
+{
+ struct list_head *pos, *q;
+ struct brcm_pcie *tmp;
+
+ mutex_lock(&brcm_pcie_lock);
+ list_for_each_safe(pos, q, &brcm_pcie) {
+ tmp = list_entry(pos, struct brcm_pcie, list);
+ if (tmp == pcie) {
+ list_del(pos);
+ if (list_empty(&brcm_pcie))
+ num_memc = 0;
+ break;
+ }
+ }
+ mutex_unlock(&brcm_pcie_lock);
+}
+
+/* This is to convert the size of the inbound bar region to the
+ * non-liniear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
+ */
+int encode_ibar_size(u64 size)
+{
+ int log2_in = ilog2(size);
+
+ if (log2_in >= 12 && log2_in <= 15)
+ /* Covers 4KB to 32KB (inclusive) */
+ return (log2_in - 12) + 0x1c;
+ else if (log2_in >= 16 && log2_in <= 37)
+ /* Covers 64KB to 32GB, (inclusive) */
+ return log2_in - 15;
+ /* Something is awry so disable */
+ return 0;
+}
+
+static u32 mdio_form_pkt(int port, int regad, int cmd)
+{
+ u32 pkt = 0;
+
+ pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
+ pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
+ pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
+
+ return pkt;
+}
+
+/* negative return value indicates error */
+static int mdio_read(void __iomem *base, u8 port, u8 regad)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_READ),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ }
+
+ return MDIO_RD_DONE(data)
+ ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
+ : -EIO;
+}
+
+/* negative return value indicates error */
+static int mdio_write(void __iomem *base, u8 port, u8 regad, u16 wrdata)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
+ base + PCIE_RC_DL_MDIO_WR_DATA);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ }
+
+ return MDIO_WT_DONE(data) ? 0 : -EIO;
+}
+
+static u32 rd_fld(void __iomem *p, u32 mask, int shift)
+{
+ return (bcm_readl(p) & mask) >> shift;
+}
+
+static void wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ u32 reg = bcm_readl(p);
+
+ reg = (reg & ~mask) | ((val << shift) & mask);
+ bcm_writel(reg, p);
+}
+
+static void wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ wr_fld(p, mask, shift, val);
+ (void)bcm_readl(p);
+}
+
+/* configures device for ssc mode; negative return value indicates error */
+static int set_ssc(void __iomem *base)
+{
+ int tmp;
+ u16 wrdata;
+ int pll, ssc;
+
+ tmp = mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET, SSC_REGS_ADDR);
+ if (tmp < 0)
+ return tmp;
+
+ tmp = mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
+ wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
+ tmp = mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
+ if (tmp < 0)
+ return tmp;
+
+ usleep_range(1000, 2000);
+ tmp = mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
+ pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
+
+ return (ssc && pll) ? 0 : -EIO;
+}
+
+/* limits operation to a specific generation (1, 2, or 3) */
+static void set_gen(void __iomem *base, int gen)
+{
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_CAPABILITY, MAX_LINK_SPEED, gen);
+ WR_FLD(base, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL_2,
+ TARGET_LINK_SPEED, gen);
+}
+
+static void set_pcie_outbound_win(struct brcm_pcie *pcie, unsigned int win,
+ phys_addr_t cpu_addr, dma_addr_t pci_addr,
+ dma_addr_t size)
+{
+ void __iomem *base = pcie->base;
+ phys_addr_t cpu_addr_mb, limit_addr_mb;
+ u32 tmp;
+
+ /* Set the base of the pci_addr window */
+ bcm_writel(lower_32_bits(pci_addr) + MMIO_ENDIAN,
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
+ bcm_writel(upper_32_bits(pci_addr),
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
+
+ cpu_addr_mb = cpu_addr >> 20;
+ limit_addr_mb = (cpu_addr + size - 1) >> 20;
+
+ /* Write the addr base low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ BASE, cpu_addr_mb);
+ /* Write the addr limit low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ LIMIT, limit_addr_mb);
+
+ if (pcie->type != BCM7435 && pcie->type != BCM7425) {
+ /* Write the cpu addr high register */
+ tmp = (u32)(cpu_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
+ BASE, tmp);
+ /* Write the cpu limit high register */
+ tmp = (u32)(limit_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
+ LIMIT, tmp);
+ }
+}
+
+static int is_pcie_link_up(struct brcm_pcie *pcie, bool silent)
+{
+ void __iomem *base = pcie->base;
+ u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
+ u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
+ u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
+ u32 rc = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
+
+ if (!rc && !silent)
+ dev_err(pcie->dev, "controller configured in EP mode\n");
+
+ return (rc && dla && plu) ? 1 : 0;
+}
+
+static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ unsigned int offset;
+ unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
+ u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
+
+ if (pcie->type != BCM7278) {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ } else if (of_machine_is_compatible("brcm,bcm7278a0")) {
+ /* The two PCIE instance on 7278a0 are not even consistent with
+ * respect to each other for internal offsets, here we offset
+ * by 0x14000 + RGR1_SW_INIT_1's relative offset to account for
+ * that.
+ */
+ offset = pcie->id ? 0x14010 : pcie->reg_offsets[RGR1_SW_INIT_1];
+ wr_fld_rb(pcie->base + offset, mask, shift, val);
+ } else {
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
+ val);
+ }
+}
+
+static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ if (pcie->type != BCM7278)
+ wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie),
+ PCIE_RGR1_SW_INIT_1_PERST_MASK,
+ PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
+ else
+ /* Assert = 0, de-assert = 1 on 7278 */
+ WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
+}
+
+static int brcm_parse_ranges(struct brcm_pcie *pcie)
+{
+ struct resource_entry *win;
+ int ret;
+
+ ret = of_pci_get_host_bridge_resources(pcie->dn, 0, 0xff,
+ &pcie->resources, NULL);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get host resources\n");
+ return ret;
+ }
+
+ resource_list_for_each_entry(win, &pcie->resources) {
+ struct resource *parent, *res = win->res;
+ dma_addr_t offset = (dma_addr_t)win->offset;
+
+ if (resource_type(res) == IORESOURCE_IO) {
+ parent = &ioport_resource;
+ } else if (resource_type(res) == IORESOURCE_MEM) {
+ if (pcie->num_out_wins >= BRCM_NUM_PCI_OUT_WINS) {
+ dev_err(pcie->dev, "too many outbound wins\n");
+ return -EINVAL;
+ }
+ pcie->out_wins[pcie->num_out_wins].cpu_addr
+ = (phys_addr_t)res->start;
+ pcie->out_wins[pcie->num_out_wins].pci_addr
+ = (dma_addr_t)(res->start
+ - (phys_addr_t)offset);
+ pcie->out_wins[pcie->num_out_wins].size
+ = (dma_addr_t)(res->end - res->start + 1);
+ pcie->num_out_wins++;
+ parent = &iomem_resource;
+ } else {
+ continue;
+ }
+
+ ret = devm_request_resource(pcie->dev, parent, res);
+ if (ret) {
+ dev_err(pcie->dev, "failed to get res %pR\n", res);
+ return ret;
+ }
+ }
+ return 0;
+}
+
+static void set_regulators(struct brcm_pcie *pcie, bool on)
+{
+ struct list_head *pos;
+
+ list_for_each(pos, &pcie->pwr_supplies) {
+ struct brcm_dev_pwr_supply *supply
+ = list_entry(pos, struct brcm_dev_pwr_supply, node);
+
+ if (on && regulator_enable(supply->regulator))
+ pr_debug("Unable to turn on %s supply.\n",
+ supply->name);
+ else if (!on && regulator_disable(supply->regulator))
+ pr_debug("Unable to turn off %s supply.\n",
+ supply->name);
+ }
+}
+
+static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ unsigned int scb_size_val;
+ u64 rc_bar2_size = 0, rc_bar2_offset = 0, total_mem_size = 0;
+ u32 tmp, burst;
+ int i;
+
+ /* reset the bridge and the endpoint device */
+ /* field: PCIE_BRIDGE_SW_INIT = 1 */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+
+ /* field: PCIE_SW_PERST = 1, on 7278, we start de-asserted already */
+ if (pcie->type != BCM7278)
+ brcm_pcie_perst_set(pcie, 1);
+
+ usleep_range(100, 200);
+
+ /* take the bridge out of reset */
+ /* field: PCIE_BRIDGE_SW_INIT = 0 */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ /* Grab the PCIe hw revision number */
+ tmp = bcm_readl(base + PCIE_MISC_REVISION);
+ pcie->rev = EXTRACT_FIELD(tmp, PCIE_MISC_REVISION, MAJMIN);
+
+ /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
+ tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
+ burst = (pcie->type == GENERIC || pcie->type == BCM7278)
+ ? BURST_SIZE_512 : BURST_SIZE_256;
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE, burst);
+ bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
+
+ /* Set up inbound memory view for the EP (called RC_BAR2,
+ * not to be confused with the BARs that are advertised by
+ * the EP).
+ */
+ for (i = 0; i < num_memc; i++)
+ total_mem_size += scb_size[i];
+
+ /* The PCI host controller by design must set the inbound
+ * viewport to be a contiguous arrangement of all of the
+ * system's memory. In addition, its size mut be a power of
+ * two. To further complicate matters, the viewport must
+ * start on a pci-address that is aligned on a multiple of its
+ * size. If a portion of the viewport does not represent
+ * system memory -- e.g. 3GB of memory requires a 4GB viewport
+ * -- we can map the outbound memory in or after 3GB and even
+ * though the viewport will overlap the outbound memory the
+ * controller will know to send outbound memory downstream and
+ * everything else upstream.
+ */
+ rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
+
+ /* Set simple configuration based on memory sizes
+ * only. We always start the viewport@address 0.
+ */
+ rc_bar2_offset = 0;
+
+ tmp = lower_32_bits(rc_bar2_offset);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
+ encode_ibar_size(rc_bar2_size));
+ bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
+ bcm_writel(upper_32_bits(rc_bar2_offset),
+ base + PCIE_MISC_RC_BAR2_CONFIG_HI);
+
+ /* field: SCB0_SIZE, default = 0xf (1 GB) */
+ scb_size_val = scb_size[0]
+ ? ilog2(scb_size[0]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
+
+ /* field: SCB1_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 1) {
+ scb_size_val = scb_size[1]
+ ? ilog2(scb_size[1]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB1_SIZE, scb_size_val);
+ }
+
+ /* field: SCB2_SIZE, default = 0xf (1 GB) */
+ if (num_memc > 2) {
+ scb_size_val = scb_size[2]
+ ? ilog2(scb_size[2]) - 15 : 0xf;
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB2_SIZE, scb_size_val);
+ }
+
+ /* disable the PCIE->GISB memory window (RC_BAR1) */
+ WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
+
+ /* disable the PCIE->SCB memory window (RC_BAR3) */
+ WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
+
+ if (!pcie->suspended) {
+ /* clear any interrupts we find on boot */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
+ }
+
+ /* Mask all interrupts since we are not handling any yet */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
+
+ if (pcie->gen)
+ set_gen(base, pcie->gen);
+
+ /* take the EP device out of reset */
+ /* field: PCIE_SW_PERST = 0 */
+ brcm_pcie_perst_set(pcie, 0);
+}
+
+static const char *link_speed_to_str(int s)
+{
+ switch (s) {
+ case 1:
+ return "2.5";
+ case 2:
+ return "5.0";
+ case 3:
+ return "8.0";
+ default:
+ break;
+ }
+ return "???";
+}
+
+static int brcm_pcie_setup_bridge(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ const int limit = pcie->suspended ? 1000 : 100;
+ unsigned int status;
+ int i, j, ret;
+ u32 neg_width, neg_speed;
+ bool ssc_good = false;
+
+ /* Give the RC/EP time to wake up, before trying to configure RC.
+ * Intermittently check status for link-up, up to a total of 100ms
+ * when we don't know if the device is there, and up to 1000ms if
+ * we do know the device is there.
+ */
+ for (i = 1, j = 0; j < limit && !is_pcie_link_up(pcie, true);
+ j += i, i = i * 2)
+ msleep(i + j > limit ? limit - j : i);
+
+ if (!is_pcie_link_up(pcie, false)) {
+ dev_info(pcie->dev, "link down\n");
+ return -ENODEV;
+ }
+
+ for (i = 0; i < pcie->num_out_wins; i++)
+ set_pcie_outbound_win(pcie, i, pcie->out_wins[i].cpu_addr,
+ pcie->out_wins[i].pci_addr,
+ pcie->out_wins[i].size);
+
+ /* For config space accesses on the RC, show the right class for
+ * a PCI-PCI bridge
+ */
+ WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
+
+ if (pcie->ssc) {
+ ret = set_ssc(base);
+ if (ret == 0)
+ ssc_good = true;
+ else
+ dev_err(pcie->dev,
+ "failed attempt to enter ssc mode\n");
+ }
+
+ status = bcm_readl(base + PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL);
+ neg_width = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_WIDTH);
+ neg_speed = EXTRACT_FIELD(status, PCIE_RC_CFG_PCIE_LINK_STATUS_CONTROL,
+ NEG_LINK_SPEED);
+ dev_info(pcie->dev, "link up, %s Gbps x%u %s\n",
+ link_speed_to_str(neg_speed), neg_width,
+ ssc_good ? "(SSC)" : "(!SSC)");
+
+ /* Enable configuration request retry (see pci_scan_device()) */
+ /* field RC_CRS_EN = 1 */
+ WR_FLD(base, PCIE_RC_CFG_PCIE_ROOT_CAP_CONTROL, RC_CRS_EN, 1);
+
+ /* PCIE->SCB endian mode for BAR */
+ /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
+ WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
+ ENDIAN_MODE_BAR2, DATA_ENDIAN);
+
+ /* Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
+ * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
+ */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
+
+ pcie->bridge_setup_done = true;
+
+ return 0;
+}
+
+static void enter_l23(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ int tries, l23;
+
+ /* assert request for L23 */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
+ /* poll L23 status */
+ for (tries = 0, l23 = 0; tries < 1000 && !l23; tries++)
+ l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
+ if (!l23)
+ dev_err(pcie->dev, "failed to enter L23\n");
+}
+
+static void turn_off(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+
+ if (is_pcie_link_up(pcie, true))
+ enter_l23(pcie);
+ /* Reset endpoint device */
+ brcm_pcie_perst_set(pcie, 1);
+ /* deassert request for L23 in case it was asserted */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
+ /* SERDES_IDDQ = 1 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
+ /* Shutdown PCIe bridge */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+}
+
+static int brcm_pcie_suspend(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ set_regulators(pcie, false);
+ pcie->suspended = true;
+
+ return 0;
+}
+
+static int brcm_pcie_resume(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ void __iomem *base;
+ int ret;
+
+ if (!pcie->bridge_setup_done)
+ return 0;
+
+ base = pcie->base;
+ set_regulators(pcie, true);
+ clk_prepare_enable(pcie->clk);
+
+ /* Take bridge out of reset so we can access the SERDES reg */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ /* SERDES_IDDQ = 0 */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* wait for serdes to be stable */
+ usleep_range(100, 200);
+
+ brcm_pcie_setup_prep(pcie);
+
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ return ret;
+
+ pcie->suspended = false;
+
+ return 0;
+}
+
+/* Configuration space read/write support */
+static int cfg_index(int busnr, int devfn, int reg)
+{
+ return ((PCI_SLOT(devfn) & 0x1f) << PCI_SLOT_SHIFT)
+ | ((PCI_FUNC(devfn) & 0x07) << PCI_FUNC_SHIFT)
+ | (busnr << PCI_BUSNUM_SHIFT)
+ | (reg & ~3);
+}
+
+static void __iomem *brcm_pci_map_cfg(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ struct brcm_pcie *pcie = bus->sysdata;
+ void __iomem *base = pcie->base;
+ bool rc_access = pci_is_root_bus(bus);
+ int idx;
+
+ if (!is_pcie_link_up(pcie, true))
+ return NULL;
+
+ base = pcie->base;
+ idx = cfg_index(bus->number, devfn, where);
+
+ bcm_writel(idx, pcie->base + IDX_ADDR(pcie));
+
+ if (rc_access) {
+ if (PCI_SLOT(devfn))
+ return NULL;
+ return base + (where & ~3);
+ }
+
+ return pcie->base + DATA_ADDR(pcie);
+}
+
+static void __attribute__((__section__("pci_fixup_early")))
+brcm_pcibios_fixup(struct pci_dev *dev)
+{
+ struct brcm_pcie *pcie = dev->bus->sysdata;
+ u8 slot = PCI_SLOT(dev->devfn);
+
+ dev_info(pcie->dev,
+ "found device %04x:%04x on bus %d (%s), slot %d (irq %d)\n",
+ dev->vendor, dev->device, dev->bus->number, pcie->name,
+ slot, of_irq_parse_and_map_pci(dev, slot, 1));
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, brcm_pcibios_fixup);
+
+static const struct of_device_id brcm_pci_match[] = {
+ { .compatible = "brcm,bcm7425-pcie", .data = &bcm7425_cfg },
+ { .compatible = "brcm,bcm7435-pcie", .data = &bcm7435_cfg },
+ { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,pci-plat-dev", .data = &generic_cfg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, brcm_pci_match);
+
+static void _brcm_pcie_remove(struct brcm_pcie *pcie)
+{
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ clk_put(pcie->clk);
+ set_regulators(pcie, false);
+ brcm_pcie_remove_controller(pcie);
+}
+
+static int brcm_pcie_probe(struct platform_device *pdev)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ const struct of_device_id *of_id;
+ const struct pcie_cfg_data *data;
+ int i, ret;
+ struct brcm_pcie *pcie;
+ struct resource *res;
+ void __iomem *base;
+ u32 tmp;
+ int supplies;
+ const char *name;
+ struct brcm_dev_pwr_supply *supply;
+ struct pci_host_bridge *bridge;
+ struct pci_bus *child;
+ u32 domain;
+
+ bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
+ if (!bridge)
+ return -ENOMEM;
+
+ pcie = pci_host_bridge_priv(bridge);
+ INIT_LIST_HEAD(&pcie->resources);
+
+ of_id = of_match_node(brcm_pci_match, dn);
+ if (!of_id) {
+ pr_err("failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
+ pr_err("cannot yet handle dma-ranges\n");
+ return -EINVAL;
+ }
+
+ data = of_id->data;
+ pcie->reg_offsets = data->offsets;
+ pcie->reg_field_info = data->reg_field_info;
+ pcie->type = data->type;
+ pcie->dn = dn;
+ pcie->dev = &pdev->dev;
+
+ if (of_property_read_u32(dn, "linux,pci-domain", &domain) == 0) {
+ pcie->id = (int)domain;
+ } else {
+ dev_err(pcie->dev, "linux,pci-domain prop missing\n");
+ return -EINVAL;
+ }
+
+ INIT_LIST_HEAD(&pcie->pwr_supplies);
+ supplies = of_property_count_strings(dn, "supply-names");
+ if (supplies <= 0)
+ supplies = 0;
+
+ for (i = 0; i < supplies; i++) {
+ if (of_property_read_string_index(dn, "supply-names", i,
+ &name))
+ continue;
+ supply = devm_kzalloc(&pdev->dev, sizeof(*supply), GFP_KERNEL);
+ if (!supply)
+ return -ENOMEM;
+ strncpy(supply->name, name, sizeof(supply->name));
+ supply->name[sizeof(supply->name) - 1] = '\0';
+ supply->regulator = devm_regulator_get(&pdev->dev, name);
+ if (IS_ERR(supply->regulator)) {
+ dev_err(&pdev->dev, "Unable to get %s supply, err=%d\n",
+ name, (int)PTR_ERR(supply->regulator));
+ continue;
+ }
+ list_add_tail(&supply->node, &pcie->pwr_supplies);
+ }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pcie->clk = of_clk_get_by_name(dn, "sw_pcie");
+ if (IS_ERR(pcie->clk)) {
+ dev_err(&pdev->dev, "could not get clock\n");
+ pcie->clk = NULL;
+ }
+ pcie->base = base;
+ pcie->gen = 0;
+
+ if (of_property_read_u32(dn, "brcm,gen", &tmp) == 0)
+ pcie->gen = tmp;
+
+ pcie->ssc = of_property_read_bool(dn, "brcm,ssc");
+
+ ret = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ if (ret == 0)
+ /* keep going, as we don't use this intr yet */
+ dev_warn(pcie->dev, "cannot get pcie interrupt\n");
+ else
+ pcie->irq = ret;
+
+ ret = brcm_parse_ranges(pcie);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(pcie->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "could not enable clock\n");
+ return ret;
+ }
+
+ ret = brcm_pcie_add_controller(pcie);
+ if (ret)
+ return ret;
+
+ set_regulators(pcie, true);
+ brcm_pcie_setup_prep(pcie);
+ ret = brcm_pcie_setup_bridge(pcie);
+ if (ret)
+ goto fail;
+
+ list_splice_init(&pcie->resources, &bridge->windows);
+ bridge->dev.parent = &pdev->dev;
+ bridge->busnr = 0;
+ bridge->ops = &brcm_pci_ops;
+ bridge->sysdata = pcie;
+ bridge->map_irq = of_irq_parse_and_map_pci;
+ bridge->swizzle_irq = pci_common_swizzle;
+
+ ret = pci_scan_root_bus_bridge(bridge);
+ if (ret < 0) {
+ dev_err(pcie->dev, "Scanning root bridge failed");
+ goto fail;
+ }
+
+ pci_assign_unassigned_bus_resources(bridge->bus);
+ list_for_each_entry(child, &bridge->bus->children, node)
+ pcie_bus_configure_settings(child);
+ pci_bus_add_devices(bridge->bus);
+ platform_set_drvdata(pdev, pcie);
+ pcie->root_bus = bridge->bus;
+
+ return 0;
+
+fail:
+ _brcm_pcie_remove(pcie);
+ return ret;
+}
+
+static int brcm_pcie_remove(struct platform_device *pdev)
+{
+ struct brcm_pcie *pcie = platform_get_drvdata(pdev);
+
+ pci_stop_root_bus(pcie->root_bus);
+ pci_remove_root_bus(pcie->root_bus);
+ _brcm_pcie_remove(pcie);
+
+ return 0;
+}
+
+static const struct dev_pm_ops brcm_pcie_pm_ops = {
+ .suspend_noirq = brcm_pcie_suspend,
+ .resume_noirq = brcm_pcie_resume,
+};
+
+static struct platform_driver __refdata brcm_pci_driver = {
+ .probe = brcm_pcie_probe,
+ .remove = brcm_pcie_remove,
+ .driver = {
+ .name = "brcm-pci",
+ .owner = THIS_MODULE,
+ .of_match_table = brcm_pci_match,
+ .pm = &brcm_pcie_pm_ops,
+ },
+};
+
+module_platform_driver(brcm_pci_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Broadcom STB PCIE RC driver");
+MODULE_AUTHOR("Broadcom");
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
new file mode 100644
index 0000000..86f9cd1
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -0,0 +1,33 @@
+#ifndef __BRCMSTB_PCI_H
+#define __BRCMSTB_PCI_H
+
+/*
+ * Copyright (C) 2015 - 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define BRCM_PCIE_NAME_SIZE 8
+#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_PCIE_HW_REV_33 0x0303
+
+/* Broadcom PCIE Offsets */
+#define PCIE_INTR2_CPU_BASE 0x4300
+
+#if defined(CONFIG_MIPS)
+/* Broadcom MIPs HW implicitly does the swapping if necessary */
+#define bcm_readl(a) __raw_readl(a)
+#define bcm_writel(d, a) __raw_writel(d, a)
+#else
+#define bcm_readl(a) readl(a)
+#define bcm_writel(d, a) writel(d, a)
+#endif
+
+#endif /* __BRCMSTB_PCI_H */
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
2017-10-11 22:34 ` Jim Quinlan
(?)
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
However, that variable is defined as static. Instead, we use
arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
we also want our driver to be a separate module, we need to
export this function.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/arm64/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 614af88..dae572f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
}
#endif
}
+EXPORT_SYMBOL(arch_setup_dma_ops);
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Jim Quinlan, Brian Norris,
linux-arm-kernel
The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
However, that variable is defined as static. Instead, we use
arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
we also want our driver to be a separate module, we need to
export this function.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/arm64/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 614af88..dae572f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
}
#endif
}
+EXPORT_SYMBOL(arch_setup_dma_ops);
--
1.9.0.138.g2de3478
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
However, that variable is defined as static. Instead, we use
arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
we also want our driver to be a separate module, we need to
export this function.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/arm64/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 614af88..dae572f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
}
#endif
}
+EXPORT_SYMBOL(arch_setup_dma_ops);
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-11 22:34 ` Jim Quinlan
(?)
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
The Broadcom STB PCIe host controller is intimately related to the
memory subsystem. This close relationship adds complexity to how cpu
system memory is mapped to PCIe memory. Ideally, this mapping is an
identity mapping, or an identity mapping off by a constant. Not so in
this case.
Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
of system memory. Here is how the PCIe controller maps the
system memory to PCIe memory:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
Although there are some "gaps" that can be added between the
individual mappings by software, the permutation of memory regions for
the most part is fixed by HW. The solution of having something close
to an identity mapping is not possible.
The idea behind this HW design is that the same PCIe module can
act as an RC or EP, and if it acts as an EP it concatenates all
of system memory into a BAR so anything can be accessed. Unfortunately,
when the PCIe block is in the role of an RC it also presents this
"BAR" to downstream PCIe devices, rather than offering an identity map
between its system memory and PCIe space.
Suppose that an endpoint driver allocs some DMA memory. Suppose this
memory is located at 0x6000_0000, which is in the middle of memc1-a.
The driver wants a dma_addr_t value that it can pass on to the EP to
use. Without doing any custom mapping, the EP will use this value for
DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
won't work; the device needs a dma_addr_t that reflects the PCIe space
address, namely 0xa000_0000.
So, essentially the solution to this problem must modify the
dma_addr_t returned by the DMA routines routines. There are two
ways (I know of) of doing this:
(a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
that are used by the dma_ops routines. This is the approach of
arch/mips/cavium-octeon/dma-octeon.c
In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
as static inline functions.
(b) Subscribe to a notifier that notifies when a device is added to a
bus. When this happens, set_dma_ops() can be called for the device.
This method is mentioned in:
http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
where it says as a comment
"In case if platform code need to use own special DMA
configuration, it can use Platform bus notifier and
handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
configuration."
Solution (b) is what this commit does. It uses the native dma_ops
as the base set of operations, and overrides some with custom
functions that translate the address and then call the base
function.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Makefile | 3 +-
drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
drivers/pci/host/pci-brcmstb.h | 7 ++
4 files changed, 368 insertions(+), 11 deletions(-)
create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 4398d2c..c283321 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
-obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
+obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
+brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
new file mode 100644
index 0000000..81ce122
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb-dma.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) 2015-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/dma-mapping.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of_address.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/smp.h>
+
+#include "pci-brcmstb.h"
+
+static const struct dma_map_ops *arch_dma_ops;
+static struct dma_map_ops brcm_dma_ops;
+
+static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+ gfp_t gfp, unsigned long attrs)
+{
+ void *ret;
+
+ ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
+ if (ret)
+ *handle = brcm_to_pci(*handle);
+ return ret;
+}
+
+static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t handle, unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
+}
+
+static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+ dma_addr = brcm_to_cpu(dma_addr);
+ return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
+}
+
+static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
+ void *cpu_addr, dma_addr_t handle, size_t size,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
+ attrs);
+}
+
+static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
+ dir, attrs));
+}
+
+static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
+}
+
+static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int ret, i;
+ struct scatterlist *sg;
+
+ ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
+ /* The ARM and MIPS implementations of map_sg and unmap_sg
+ * make calls to ops->map_page(), which we already intercept.
+ * The ARM64 does not, so we must iterate through the SG list
+ * and convert each dma_address to one that is compatible
+ * with our PCI RC implementation.
+ */
+ if (IS_ENABLED(CONFIG_ARM64))
+ for_each_sg(sgl, sg, ret, i)
+ sg->dma_address = brcm_to_pci(sg->dma_address);
+ return ret;
+}
+
+static void brcm_dma_unmap_sg(struct device *dev,
+ struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int i;
+ struct scatterlist *sg;
+
+ /* The ARM and MIPS implementations of map_sg and unmap_sg
+ * make calls to ops->map_page(), which we already intercept.
+ * The ARM64 does not, so we must iterate through the SG list
+ * and convert each dma_address to one that is compatible
+ * with our PCI RC implementation.
+ */
+ if (IS_ENABLED(CONFIG_ARM64))
+ for_each_sg(sgl, sg, nents, i)
+ sg->dma_address = brcm_to_cpu(sg->dma_address);
+ arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
+}
+
+static void brcm_dma_sync_single_for_cpu(struct device *dev,
+ dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
+}
+
+static void brcm_dma_sync_single_for_device(struct device *dev,
+ dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
+}
+
+static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return brcm_to_pci(arch_dma_ops->map_resource
+ (dev, phys, size, dir, attrs));
+}
+
+static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
+}
+
+static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
+{
+ return dma_addr == BRCMSTB_ERROR_CODE;
+}
+
+static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
+{
+#if defined(CONFIG_MIPS)
+ return mips_dma_map_ops;
+#elif defined(CONFIG_ARM)
+ return &arm_dma_ops;
+#elif defined(CONFIG_ARM64)
+ /* swiotlb_dma_ops is a static var, so we get ahold
+ * of it by calling arch_setup_dma_ops(...).
+ */
+ arch_setup_dma_ops(dev, 0, 0, NULL, false);
+ return dev->dma_ops;
+#endif
+ return 0;
+}
+
+static void brcm_set_dma_ops(struct device *dev)
+{
+ arch_dma_ops = brcm_get_arch_dma_ops(dev);
+ if (!arch_dma_ops)
+ return;
+
+ /* Set all of the base operations; some will be overridden */
+ brcm_dma_ops = *arch_dma_ops;
+
+ /* Insert the Brcm-specific override operations */
+ brcm_dma_ops.alloc = brcm_dma_alloc;
+ brcm_dma_ops.free = brcm_dma_free;
+ brcm_dma_ops.mmap = brcm_dma_mmap;
+ brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
+ brcm_dma_ops.map_page = brcm_dma_map_page;
+ brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
+ brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
+ brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
+ brcm_dma_ops.map_sg = brcm_dma_map_sg;
+ brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
+ if (arch_dma_ops->map_resource)
+ brcm_dma_ops.map_resource = brcm_dma_map_resource;
+ if (arch_dma_ops->unmap_resource)
+ brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
+ brcm_dma_ops.mapping_error = brcm_mapping_error;
+
+ /* Use our brcm_dma_ops for this driver */
+ set_dma_ops(dev, &brcm_dma_ops);
+}
+
+static int brcmstb_platform_notifier(struct notifier_block *nb,
+ unsigned long event, void *__dev)
+{
+ struct device *dev = __dev;
+
+ if (event != BUS_NOTIFY_ADD_DEVICE)
+ return NOTIFY_DONE;
+
+ brcm_set_dma_ops(dev);
+ return NOTIFY_OK;
+}
+
+struct notifier_block brcmstb_platform_nb = {
+ .notifier_call = brcmstb_platform_notifier,
+};
+EXPORT_SYMBOL(brcmstb_platform_nb);
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
index f4cd6e7..03c0da9 100644
--- a/drivers/pci/host/pci-brcmstb.c
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -343,6 +343,8 @@ struct brcm_pcie {
static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
static phys_addr_t scb_size[BRCM_MAX_SCB];
+static struct of_pci_range *dma_ranges;
+static int num_dma_ranges;
static int num_memc;
static DEFINE_MUTEX(brcm_pcie_lock);
@@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
{
mutex_lock(&brcm_pcie_lock);
snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
+ if (list_empty(&brcm_pcie))
+ bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
list_add_tail(&pcie->list, &brcm_pcie);
mutex_unlock(&brcm_pcie_lock);
@@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
tmp = list_entry(pos, struct brcm_pcie, list);
if (tmp == pcie) {
list_del(pos);
- if (list_empty(&brcm_pcie))
+ if (list_empty(&brcm_pcie)) {
+ bus_unregister_notifier(&pci_bus_type,
+ &brcmstb_platform_nb);
+ kfree(dma_ranges);
+ dma_ranges = NULL;
+ num_dma_ranges = 0;
num_memc = 0;
+ }
break;
}
}
@@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
return 0;
}
+dma_addr_t brcm_to_pci(dma_addr_t addr)
+{
+ struct of_pci_range *p;
+
+ if (!num_dma_ranges)
+ return addr;
+
+ for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
+ if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
+ return addr - p->cpu_addr + p->pci_addr;
+
+ return BRCMSTB_ERROR_CODE;
+}
+EXPORT_SYMBOL(brcm_to_pci);
+
+dma_addr_t brcm_to_cpu(dma_addr_t addr)
+{
+ struct of_pci_range *p;
+
+ if (!num_dma_ranges)
+ return addr;
+ for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
+ if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
+ return addr - p->pci_addr + p->cpu_addr;
+
+ return addr;
+}
+EXPORT_SYMBOL(brcm_to_cpu);
+
static u32 mdio_form_pkt(int port, int regad, int cmd)
{
u32 pkt = 0;
@@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
return 0;
}
+static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser->node = node;
+ parser->pna = of_n_addr_cells(node);
+ parser->np = parser->pna + na + ns;
+
+ parser->range = of_get_property(node, "dma-ranges", &rlen);
+ if (!parser->range)
+ return -ENOENT;
+
+ parser->end = parser->range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
+{
+ int i, ret = 0;
+ struct of_pci_range_parser parser;
+ struct device_node *dn = pcie->dn;
+
+ mutex_lock(&brcm_pcie_lock);
+ if (dma_ranges)
+ goto done;
+
+ /* Parse dma-ranges property if present. If there are multiple
+ * PCI controllers, we only have to parse from one of them since
+ * the others will have an identical mapping.
+ */
+ if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
+ unsigned int max_ranges
+ = (parser.end - parser.range) / parser.np;
+
+ dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
+ GFP_KERNEL);
+ if (!dma_ranges) {
+ ret = -ENOMEM;
+ goto done;
+ }
+ for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
+ i++)
+ num_dma_ranges++;
+ }
+
+ for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
+ u64 size = brcmstb_memory_memc_size(i);
+
+ if (size == (u64)-1) {
+ dev_err(pcie->dev, "cannot get memc%d size", i);
+ ret = -EINVAL;
+ goto done;
+ } else if (size) {
+ scb_size[i] = roundup_pow_of_two_64(size);
+ num_memc++;
+ } else {
+ break;
+ }
+ }
+
+done:
+ mutex_unlock(&brcm_pcie_lock);
+ return ret;
+}
+
static void set_regulators(struct brcm_pcie *pcie, bool on)
{
struct list_head *pos;
@@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
*/
rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
- /* Set simple configuration based on memory sizes
- * only. We always start the viewport at address 0.
- */
- rc_bar2_offset = 0;
+ if (dma_ranges) {
+ /* The best-case scenario is to place the inbound
+ * region in the first 4GB of pci-space, as some
+ * legacy devices can only address 32bits.
+ * We would also like to put the MSI under 4GB
+ * as well, since some devices require a 32bit
+ * MSI target address.
+ */
+ if (total_mem_size <= 0xc0000000ULL &&
+ rc_bar2_size <= 0x100000000ULL) {
+ rc_bar2_offset = 0;
+ } else {
+ /* The system memory is 4GB or larger so we
+ * cannot start the inbound region at location
+ * 0 (since we have to allow some space for
+ * outbound memory @ 3GB). So instead we
+ * start it at the 1x multiple of its size
+ */
+ rc_bar2_offset = rc_bar2_size;
+ }
+
+ } else {
+ /* Set simple configuration based on memory sizes
+ * only. We always start the viewport at address 0,
+ * and set the MSI target address accordingly.
+ */
+ rc_bar2_offset = 0;
+ }
tmp = lower_32_bits(rc_bar2_offset);
tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
@@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
return -EINVAL;
}
- if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
- pr_err("cannot yet handle dma-ranges\n");
- return -EINVAL;
- }
-
data = of_id->data;
pcie->reg_offsets = data->offsets;
pcie->reg_field_info = data->reg_field_info;
@@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = brcm_parse_dma_ranges(pcie);
+ if (ret)
+ return ret;
+
ret = clk_prepare_enable(pcie->clk);
if (ret) {
dev_err(&pdev->dev, "could not enable clock\n");
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
index 86f9cd1..4851be8 100644
--- a/drivers/pci/host/pci-brcmstb.h
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -21,6 +21,13 @@
/* Broadcom PCIE Offsets */
#define PCIE_INTR2_CPU_BASE 0x4300
+dma_addr_t brcm_to_pci(dma_addr_t addr);
+dma_addr_t brcm_to_cpu(dma_addr_t addr);
+
+extern struct notifier_block brcmstb_platform_nb;
+
+#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
+
#if defined(CONFIG_MIPS)
/* Broadcom MIPs HW implicitly does the swapping if necessary */
#define bcm_readl(a) __raw_readl(a)
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Jim Quinlan, Brian Norris,
linux-arm-kernel
The Broadcom STB PCIe host controller is intimately related to the
memory subsystem. This close relationship adds complexity to how cpu
system memory is mapped to PCIe memory. Ideally, this mapping is an
identity mapping, or an identity mapping off by a constant. Not so in
this case.
Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
of system memory. Here is how the PCIe controller maps the
system memory to PCIe memory:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
Although there are some "gaps" that can be added between the
individual mappings by software, the permutation of memory regions for
the most part is fixed by HW. The solution of having something close
to an identity mapping is not possible.
The idea behind this HW design is that the same PCIe module can
act as an RC or EP, and if it acts as an EP it concatenates all
of system memory into a BAR so anything can be accessed. Unfortunately,
when the PCIe block is in the role of an RC it also presents this
"BAR" to downstream PCIe devices, rather than offering an identity map
between its system memory and PCIe space.
Suppose that an endpoint driver allocs some DMA memory. Suppose this
memory is located at 0x6000_0000, which is in the middle of memc1-a.
The driver wants a dma_addr_t value that it can pass on to the EP to
use. Without doing any custom mapping, the EP will use this value for
DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
won't work; the device needs a dma_addr_t that reflects the PCIe space
address, namely 0xa000_0000.
So, essentially the solution to this problem must modify the
dma_addr_t returned by the DMA routines routines. There are two
ways (I know of) of doing this:
(a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
that are used by the dma_ops routines. This is the approach of
arch/mips/cavium-octeon/dma-octeon.c
In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
as static inline functions.
(b) Subscribe to a notifier that notifies when a device is added to a
bus. When this happens, set_dma_ops() can be called for the device.
This method is mentioned in:
http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
where it says as a comment
"In case if platform code need to use own special DMA
configuration, it can use Platform bus notifier and
handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
configuration."
Solution (b) is what this commit does. It uses the native dma_ops
as the base set of operations, and overrides some with custom
functions that translate the address and then call the base
function.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Makefile | 3 +-
drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
drivers/pci/host/pci-brcmstb.h | 7 ++
4 files changed, 368 insertions(+), 11 deletions(-)
create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 4398d2c..c283321 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
-obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
+obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
+brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
new file mode 100644
index 0000000..81ce122
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb-dma.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) 2015-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/dma-mapping.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of_address.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/smp.h>
+
+#include "pci-brcmstb.h"
+
+static const struct dma_map_ops *arch_dma_ops;
+static struct dma_map_ops brcm_dma_ops;
+
+static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+ gfp_t gfp, unsigned long attrs)
+{
+ void *ret;
+
+ ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
+ if (ret)
+ *handle = brcm_to_pci(*handle);
+ return ret;
+}
+
+static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t handle, unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
+}
+
+static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+ dma_addr = brcm_to_cpu(dma_addr);
+ return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
+}
+
+static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
+ void *cpu_addr, dma_addr_t handle, size_t size,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
+ attrs);
+}
+
+static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
+ dir, attrs));
+}
+
+static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
+}
+
+static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int ret, i;
+ struct scatterlist *sg;
+
+ ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
+ /* The ARM and MIPS implementations of map_sg and unmap_sg
+ * make calls to ops->map_page(), which we already intercept.
+ * The ARM64 does not, so we must iterate through the SG list
+ * and convert each dma_address to one that is compatible
+ * with our PCI RC implementation.
+ */
+ if (IS_ENABLED(CONFIG_ARM64))
+ for_each_sg(sgl, sg, ret, i)
+ sg->dma_address = brcm_to_pci(sg->dma_address);
+ return ret;
+}
+
+static void brcm_dma_unmap_sg(struct device *dev,
+ struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int i;
+ struct scatterlist *sg;
+
+ /* The ARM and MIPS implementations of map_sg and unmap_sg
+ * make calls to ops->map_page(), which we already intercept.
+ * The ARM64 does not, so we must iterate through the SG list
+ * and convert each dma_address to one that is compatible
+ * with our PCI RC implementation.
+ */
+ if (IS_ENABLED(CONFIG_ARM64))
+ for_each_sg(sgl, sg, nents, i)
+ sg->dma_address = brcm_to_cpu(sg->dma_address);
+ arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
+}
+
+static void brcm_dma_sync_single_for_cpu(struct device *dev,
+ dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
+}
+
+static void brcm_dma_sync_single_for_device(struct device *dev,
+ dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
+}
+
+static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return brcm_to_pci(arch_dma_ops->map_resource
+ (dev, phys, size, dir, attrs));
+}
+
+static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
+}
+
+static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
+{
+ return dma_addr == BRCMSTB_ERROR_CODE;
+}
+
+static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
+{
+#if defined(CONFIG_MIPS)
+ return mips_dma_map_ops;
+#elif defined(CONFIG_ARM)
+ return &arm_dma_ops;
+#elif defined(CONFIG_ARM64)
+ /* swiotlb_dma_ops is a static var, so we get ahold
+ * of it by calling arch_setup_dma_ops(...).
+ */
+ arch_setup_dma_ops(dev, 0, 0, NULL, false);
+ return dev->dma_ops;
+#endif
+ return 0;
+}
+
+static void brcm_set_dma_ops(struct device *dev)
+{
+ arch_dma_ops = brcm_get_arch_dma_ops(dev);
+ if (!arch_dma_ops)
+ return;
+
+ /* Set all of the base operations; some will be overridden */
+ brcm_dma_ops = *arch_dma_ops;
+
+ /* Insert the Brcm-specific override operations */
+ brcm_dma_ops.alloc = brcm_dma_alloc;
+ brcm_dma_ops.free = brcm_dma_free;
+ brcm_dma_ops.mmap = brcm_dma_mmap;
+ brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
+ brcm_dma_ops.map_page = brcm_dma_map_page;
+ brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
+ brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
+ brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
+ brcm_dma_ops.map_sg = brcm_dma_map_sg;
+ brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
+ if (arch_dma_ops->map_resource)
+ brcm_dma_ops.map_resource = brcm_dma_map_resource;
+ if (arch_dma_ops->unmap_resource)
+ brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
+ brcm_dma_ops.mapping_error = brcm_mapping_error;
+
+ /* Use our brcm_dma_ops for this driver */
+ set_dma_ops(dev, &brcm_dma_ops);
+}
+
+static int brcmstb_platform_notifier(struct notifier_block *nb,
+ unsigned long event, void *__dev)
+{
+ struct device *dev = __dev;
+
+ if (event != BUS_NOTIFY_ADD_DEVICE)
+ return NOTIFY_DONE;
+
+ brcm_set_dma_ops(dev);
+ return NOTIFY_OK;
+}
+
+struct notifier_block brcmstb_platform_nb = {
+ .notifier_call = brcmstb_platform_notifier,
+};
+EXPORT_SYMBOL(brcmstb_platform_nb);
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
index f4cd6e7..03c0da9 100644
--- a/drivers/pci/host/pci-brcmstb.c
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -343,6 +343,8 @@ struct brcm_pcie {
static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
static phys_addr_t scb_size[BRCM_MAX_SCB];
+static struct of_pci_range *dma_ranges;
+static int num_dma_ranges;
static int num_memc;
static DEFINE_MUTEX(brcm_pcie_lock);
@@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
{
mutex_lock(&brcm_pcie_lock);
snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
+ if (list_empty(&brcm_pcie))
+ bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
list_add_tail(&pcie->list, &brcm_pcie);
mutex_unlock(&brcm_pcie_lock);
@@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
tmp = list_entry(pos, struct brcm_pcie, list);
if (tmp == pcie) {
list_del(pos);
- if (list_empty(&brcm_pcie))
+ if (list_empty(&brcm_pcie)) {
+ bus_unregister_notifier(&pci_bus_type,
+ &brcmstb_platform_nb);
+ kfree(dma_ranges);
+ dma_ranges = NULL;
+ num_dma_ranges = 0;
num_memc = 0;
+ }
break;
}
}
@@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
return 0;
}
+dma_addr_t brcm_to_pci(dma_addr_t addr)
+{
+ struct of_pci_range *p;
+
+ if (!num_dma_ranges)
+ return addr;
+
+ for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
+ if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
+ return addr - p->cpu_addr + p->pci_addr;
+
+ return BRCMSTB_ERROR_CODE;
+}
+EXPORT_SYMBOL(brcm_to_pci);
+
+dma_addr_t brcm_to_cpu(dma_addr_t addr)
+{
+ struct of_pci_range *p;
+
+ if (!num_dma_ranges)
+ return addr;
+ for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
+ if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
+ return addr - p->pci_addr + p->cpu_addr;
+
+ return addr;
+}
+EXPORT_SYMBOL(brcm_to_cpu);
+
static u32 mdio_form_pkt(int port, int regad, int cmd)
{
u32 pkt = 0;
@@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
return 0;
}
+static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser->node = node;
+ parser->pna = of_n_addr_cells(node);
+ parser->np = parser->pna + na + ns;
+
+ parser->range = of_get_property(node, "dma-ranges", &rlen);
+ if (!parser->range)
+ return -ENOENT;
+
+ parser->end = parser->range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
+{
+ int i, ret = 0;
+ struct of_pci_range_parser parser;
+ struct device_node *dn = pcie->dn;
+
+ mutex_lock(&brcm_pcie_lock);
+ if (dma_ranges)
+ goto done;
+
+ /* Parse dma-ranges property if present. If there are multiple
+ * PCI controllers, we only have to parse from one of them since
+ * the others will have an identical mapping.
+ */
+ if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
+ unsigned int max_ranges
+ = (parser.end - parser.range) / parser.np;
+
+ dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
+ GFP_KERNEL);
+ if (!dma_ranges) {
+ ret = -ENOMEM;
+ goto done;
+ }
+ for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
+ i++)
+ num_dma_ranges++;
+ }
+
+ for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
+ u64 size = brcmstb_memory_memc_size(i);
+
+ if (size == (u64)-1) {
+ dev_err(pcie->dev, "cannot get memc%d size", i);
+ ret = -EINVAL;
+ goto done;
+ } else if (size) {
+ scb_size[i] = roundup_pow_of_two_64(size);
+ num_memc++;
+ } else {
+ break;
+ }
+ }
+
+done:
+ mutex_unlock(&brcm_pcie_lock);
+ return ret;
+}
+
static void set_regulators(struct brcm_pcie *pcie, bool on)
{
struct list_head *pos;
@@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
*/
rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
- /* Set simple configuration based on memory sizes
- * only. We always start the viewport at address 0.
- */
- rc_bar2_offset = 0;
+ if (dma_ranges) {
+ /* The best-case scenario is to place the inbound
+ * region in the first 4GB of pci-space, as some
+ * legacy devices can only address 32bits.
+ * We would also like to put the MSI under 4GB
+ * as well, since some devices require a 32bit
+ * MSI target address.
+ */
+ if (total_mem_size <= 0xc0000000ULL &&
+ rc_bar2_size <= 0x100000000ULL) {
+ rc_bar2_offset = 0;
+ } else {
+ /* The system memory is 4GB or larger so we
+ * cannot start the inbound region at location
+ * 0 (since we have to allow some space for
+ * outbound memory @ 3GB). So instead we
+ * start it at the 1x multiple of its size
+ */
+ rc_bar2_offset = rc_bar2_size;
+ }
+
+ } else {
+ /* Set simple configuration based on memory sizes
+ * only. We always start the viewport at address 0,
+ * and set the MSI target address accordingly.
+ */
+ rc_bar2_offset = 0;
+ }
tmp = lower_32_bits(rc_bar2_offset);
tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
@@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
return -EINVAL;
}
- if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
- pr_err("cannot yet handle dma-ranges\n");
- return -EINVAL;
- }
-
data = of_id->data;
pcie->reg_offsets = data->offsets;
pcie->reg_field_info = data->reg_field_info;
@@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = brcm_parse_dma_ranges(pcie);
+ if (ret)
+ return ret;
+
ret = clk_prepare_enable(pcie->clk);
if (ret) {
dev_err(&pdev->dev, "could not enable clock\n");
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
index 86f9cd1..4851be8 100644
--- a/drivers/pci/host/pci-brcmstb.h
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -21,6 +21,13 @@
/* Broadcom PCIE Offsets */
#define PCIE_INTR2_CPU_BASE 0x4300
+dma_addr_t brcm_to_pci(dma_addr_t addr);
+dma_addr_t brcm_to_cpu(dma_addr_t addr);
+
+extern struct notifier_block brcmstb_platform_nb;
+
+#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
+
#if defined(CONFIG_MIPS)
/* Broadcom MIPs HW implicitly does the swapping if necessary */
#define bcm_readl(a) __raw_readl(a)
--
1.9.0.138.g2de3478
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
The Broadcom STB PCIe host controller is intimately related to the
memory subsystem. This close relationship adds complexity to how cpu
system memory is mapped to PCIe memory. Ideally, this mapping is an
identity mapping, or an identity mapping off by a constant. Not so in
this case.
Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
of system memory. Here is how the PCIe controller maps the
system memory to PCIe memory:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
Although there are some "gaps" that can be added between the
individual mappings by software, the permutation of memory regions for
the most part is fixed by HW. The solution of having something close
to an identity mapping is not possible.
The idea behind this HW design is that the same PCIe module can
act as an RC or EP, and if it acts as an EP it concatenates all
of system memory into a BAR so anything can be accessed. Unfortunately,
when the PCIe block is in the role of an RC it also presents this
"BAR" to downstream PCIe devices, rather than offering an identity map
between its system memory and PCIe space.
Suppose that an endpoint driver allocs some DMA memory. Suppose this
memory is located at 0x6000_0000, which is in the middle of memc1-a.
The driver wants a dma_addr_t value that it can pass on to the EP to
use. Without doing any custom mapping, the EP will use this value for
DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
won't work; the device needs a dma_addr_t that reflects the PCIe space
address, namely 0xa000_0000.
So, essentially the solution to this problem must modify the
dma_addr_t returned by the DMA routines routines. There are two
ways (I know of) of doing this:
(a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
that are used by the dma_ops routines. This is the approach of
arch/mips/cavium-octeon/dma-octeon.c
In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
as static inline functions.
(b) Subscribe to a notifier that notifies when a device is added to a
bus. When this happens, set_dma_ops() can be called for the device.
This method is mentioned in:
http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
where it says as a comment
"In case if platform code need to use own special DMA
configuration, it can use Platform bus notifier and
handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
configuration."
Solution (b) is what this commit does. It uses the native dma_ops
as the base set of operations, and overrides some with custom
functions that translate the address and then call the base
function.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Makefile | 3 +-
drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
drivers/pci/host/pci-brcmstb.h | 7 ++
4 files changed, 368 insertions(+), 11 deletions(-)
create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 4398d2c..c283321 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
-obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
+obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
+brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
new file mode 100644
index 0000000..81ce122
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb-dma.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) 2015-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/dma-mapping.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of_address.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/smp.h>
+
+#include "pci-brcmstb.h"
+
+static const struct dma_map_ops *arch_dma_ops;
+static struct dma_map_ops brcm_dma_ops;
+
+static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
+ gfp_t gfp, unsigned long attrs)
+{
+ void *ret;
+
+ ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
+ if (ret)
+ *handle = brcm_to_pci(*handle);
+ return ret;
+}
+
+static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t handle, unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
+}
+
+static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+ dma_addr = brcm_to_cpu(dma_addr);
+ return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
+}
+
+static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
+ void *cpu_addr, dma_addr_t handle, size_t size,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
+ attrs);
+}
+
+static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
+ dir, attrs));
+}
+
+static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
+}
+
+static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int ret, i;
+ struct scatterlist *sg;
+
+ ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
+ /* The ARM and MIPS implementations of map_sg and unmap_sg
+ * make calls to ops->map_page(), which we already intercept.
+ * The ARM64 does not, so we must iterate through the SG list
+ * and convert each dma_address to one that is compatible
+ * with our PCI RC implementation.
+ */
+ if (IS_ENABLED(CONFIG_ARM64))
+ for_each_sg(sgl, sg, ret, i)
+ sg->dma_address = brcm_to_pci(sg->dma_address);
+ return ret;
+}
+
+static void brcm_dma_unmap_sg(struct device *dev,
+ struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int i;
+ struct scatterlist *sg;
+
+ /* The ARM and MIPS implementations of map_sg and unmap_sg
+ * make calls to ops->map_page(), which we already intercept.
+ * The ARM64 does not, so we must iterate through the SG list
+ * and convert each dma_address to one that is compatible
+ * with our PCI RC implementation.
+ */
+ if (IS_ENABLED(CONFIG_ARM64))
+ for_each_sg(sgl, sg, nents, i)
+ sg->dma_address = brcm_to_cpu(sg->dma_address);
+ arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
+}
+
+static void brcm_dma_sync_single_for_cpu(struct device *dev,
+ dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
+}
+
+static void brcm_dma_sync_single_for_device(struct device *dev,
+ dma_addr_t handle, size_t size,
+ enum dma_data_direction dir)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
+}
+
+static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return brcm_to_pci(arch_dma_ops->map_resource
+ (dev, phys, size, dir, attrs));
+}
+
+static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ handle = brcm_to_cpu(handle);
+ arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
+}
+
+static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
+{
+ return dma_addr == BRCMSTB_ERROR_CODE;
+}
+
+static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
+{
+#if defined(CONFIG_MIPS)
+ return mips_dma_map_ops;
+#elif defined(CONFIG_ARM)
+ return &arm_dma_ops;
+#elif defined(CONFIG_ARM64)
+ /* swiotlb_dma_ops is a static var, so we get ahold
+ * of it by calling arch_setup_dma_ops(...).
+ */
+ arch_setup_dma_ops(dev, 0, 0, NULL, false);
+ return dev->dma_ops;
+#endif
+ return 0;
+}
+
+static void brcm_set_dma_ops(struct device *dev)
+{
+ arch_dma_ops = brcm_get_arch_dma_ops(dev);
+ if (!arch_dma_ops)
+ return;
+
+ /* Set all of the base operations; some will be overridden */
+ brcm_dma_ops = *arch_dma_ops;
+
+ /* Insert the Brcm-specific override operations */
+ brcm_dma_ops.alloc = brcm_dma_alloc;
+ brcm_dma_ops.free = brcm_dma_free;
+ brcm_dma_ops.mmap = brcm_dma_mmap;
+ brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
+ brcm_dma_ops.map_page = brcm_dma_map_page;
+ brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
+ brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
+ brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
+ brcm_dma_ops.map_sg = brcm_dma_map_sg;
+ brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
+ if (arch_dma_ops->map_resource)
+ brcm_dma_ops.map_resource = brcm_dma_map_resource;
+ if (arch_dma_ops->unmap_resource)
+ brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
+ brcm_dma_ops.mapping_error = brcm_mapping_error;
+
+ /* Use our brcm_dma_ops for this driver */
+ set_dma_ops(dev, &brcm_dma_ops);
+}
+
+static int brcmstb_platform_notifier(struct notifier_block *nb,
+ unsigned long event, void *__dev)
+{
+ struct device *dev = __dev;
+
+ if (event != BUS_NOTIFY_ADD_DEVICE)
+ return NOTIFY_DONE;
+
+ brcm_set_dma_ops(dev);
+ return NOTIFY_OK;
+}
+
+struct notifier_block brcmstb_platform_nb = {
+ .notifier_call = brcmstb_platform_notifier,
+};
+EXPORT_SYMBOL(brcmstb_platform_nb);
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
index f4cd6e7..03c0da9 100644
--- a/drivers/pci/host/pci-brcmstb.c
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -343,6 +343,8 @@ struct brcm_pcie {
static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
static phys_addr_t scb_size[BRCM_MAX_SCB];
+static struct of_pci_range *dma_ranges;
+static int num_dma_ranges;
static int num_memc;
static DEFINE_MUTEX(brcm_pcie_lock);
@@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
{
mutex_lock(&brcm_pcie_lock);
snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
+ if (list_empty(&brcm_pcie))
+ bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
list_add_tail(&pcie->list, &brcm_pcie);
mutex_unlock(&brcm_pcie_lock);
@@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
tmp = list_entry(pos, struct brcm_pcie, list);
if (tmp == pcie) {
list_del(pos);
- if (list_empty(&brcm_pcie))
+ if (list_empty(&brcm_pcie)) {
+ bus_unregister_notifier(&pci_bus_type,
+ &brcmstb_platform_nb);
+ kfree(dma_ranges);
+ dma_ranges = NULL;
+ num_dma_ranges = 0;
num_memc = 0;
+ }
break;
}
}
@@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
return 0;
}
+dma_addr_t brcm_to_pci(dma_addr_t addr)
+{
+ struct of_pci_range *p;
+
+ if (!num_dma_ranges)
+ return addr;
+
+ for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
+ if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
+ return addr - p->cpu_addr + p->pci_addr;
+
+ return BRCMSTB_ERROR_CODE;
+}
+EXPORT_SYMBOL(brcm_to_pci);
+
+dma_addr_t brcm_to_cpu(dma_addr_t addr)
+{
+ struct of_pci_range *p;
+
+ if (!num_dma_ranges)
+ return addr;
+ for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
+ if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
+ return addr - p->pci_addr + p->cpu_addr;
+
+ return addr;
+}
+EXPORT_SYMBOL(brcm_to_cpu);
+
static u32 mdio_form_pkt(int port, int regad, int cmd)
{
u32 pkt = 0;
@@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
return 0;
}
+static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser->node = node;
+ parser->pna = of_n_addr_cells(node);
+ parser->np = parser->pna + na + ns;
+
+ parser->range = of_get_property(node, "dma-ranges", &rlen);
+ if (!parser->range)
+ return -ENOENT;
+
+ parser->end = parser->range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
+{
+ int i, ret = 0;
+ struct of_pci_range_parser parser;
+ struct device_node *dn = pcie->dn;
+
+ mutex_lock(&brcm_pcie_lock);
+ if (dma_ranges)
+ goto done;
+
+ /* Parse dma-ranges property if present. If there are multiple
+ * PCI controllers, we only have to parse from one of them since
+ * the others will have an identical mapping.
+ */
+ if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
+ unsigned int max_ranges
+ = (parser.end - parser.range) / parser.np;
+
+ dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
+ GFP_KERNEL);
+ if (!dma_ranges) {
+ ret = -ENOMEM;
+ goto done;
+ }
+ for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
+ i++)
+ num_dma_ranges++;
+ }
+
+ for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
+ u64 size = brcmstb_memory_memc_size(i);
+
+ if (size == (u64)-1) {
+ dev_err(pcie->dev, "cannot get memc%d size", i);
+ ret = -EINVAL;
+ goto done;
+ } else if (size) {
+ scb_size[i] = roundup_pow_of_two_64(size);
+ num_memc++;
+ } else {
+ break;
+ }
+ }
+
+done:
+ mutex_unlock(&brcm_pcie_lock);
+ return ret;
+}
+
static void set_regulators(struct brcm_pcie *pcie, bool on)
{
struct list_head *pos;
@@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
*/
rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
- /* Set simple configuration based on memory sizes
- * only. We always start the viewport at address 0.
- */
- rc_bar2_offset = 0;
+ if (dma_ranges) {
+ /* The best-case scenario is to place the inbound
+ * region in the first 4GB of pci-space, as some
+ * legacy devices can only address 32bits.
+ * We would also like to put the MSI under 4GB
+ * as well, since some devices require a 32bit
+ * MSI target address.
+ */
+ if (total_mem_size <= 0xc0000000ULL &&
+ rc_bar2_size <= 0x100000000ULL) {
+ rc_bar2_offset = 0;
+ } else {
+ /* The system memory is 4GB or larger so we
+ * cannot start the inbound region at location
+ * 0 (since we have to allow some space for
+ * outbound memory @ 3GB). So instead we
+ * start it at the 1x multiple of its size
+ */
+ rc_bar2_offset = rc_bar2_size;
+ }
+
+ } else {
+ /* Set simple configuration based on memory sizes
+ * only. We always start the viewport@address 0,
+ * and set the MSI target address accordingly.
+ */
+ rc_bar2_offset = 0;
+ }
tmp = lower_32_bits(rc_bar2_offset);
tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
@@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
return -EINVAL;
}
- if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
- pr_err("cannot yet handle dma-ranges\n");
- return -EINVAL;
- }
-
data = of_id->data;
pcie->reg_offsets = data->offsets;
pcie->reg_field_info = data->reg_field_info;
@@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = brcm_parse_dma_ranges(pcie);
+ if (ret)
+ return ret;
+
ret = clk_prepare_enable(pcie->clk);
if (ret) {
dev_err(&pdev->dev, "could not enable clock\n");
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
index 86f9cd1..4851be8 100644
--- a/drivers/pci/host/pci-brcmstb.h
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -21,6 +21,13 @@
/* Broadcom PCIE Offsets */
#define PCIE_INTR2_CPU_BASE 0x4300
+dma_addr_t brcm_to_pci(dma_addr_t addr);
+dma_addr_t brcm_to_cpu(dma_addr_t addr);
+
+extern struct notifier_block brcmstb_platform_nb;
+
+#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
+
#if defined(CONFIG_MIPS)
/* Broadcom MIPs HW implicitly does the swapping if necessary */
#define bcm_readl(a) __raw_readl(a)
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 6/9] PCI/MSI: Enable PCI_MSI_IRQ_DOMAIN support for MIPS
2017-10-11 22:34 ` Jim Quinlan
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
Add MIPS as an arch that supports PCI_MSI_IRQ_DOMAIN and add
generation of msi.h in the MIPS arch.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/mips/include/asm/Kbuild | 1 +
drivers/pci/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild
index 7c8aab2..8c78ba7 100644
--- a/arch/mips/include/asm/Kbuild
+++ b/arch/mips/include/asm/Kbuild
@@ -9,6 +9,7 @@ generic-y += irq_work.h
generic-y += local64.h
generic-y += mcs_spinlock.h
generic-y += mm-arch-hooks.h
+generic-y += msi.h
generic-y += parport.h
generic-y += percpu.h
generic-y += preempt.h
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index c32a77f..927c335 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -25,7 +25,7 @@ config PCI_MSI
If you don't know what to do here, say Y.
config PCI_MSI_IRQ_DOMAIN
- def_bool ARC || ARM || ARM64 || X86
+ def_bool ARC || ARM || ARM64 || MIPS || X86
depends on PCI_MSI
select GENERIC_MSI_IRQ_DOMAIN
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 6/9] PCI/MSI: Enable PCI_MSI_IRQ_DOMAIN support for MIPS
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
Add MIPS as an arch that supports PCI_MSI_IRQ_DOMAIN and add
generation of msi.h in the MIPS arch.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/mips/include/asm/Kbuild | 1 +
drivers/pci/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild
index 7c8aab2..8c78ba7 100644
--- a/arch/mips/include/asm/Kbuild
+++ b/arch/mips/include/asm/Kbuild
@@ -9,6 +9,7 @@ generic-y += irq_work.h
generic-y += local64.h
generic-y += mcs_spinlock.h
generic-y += mm-arch-hooks.h
+generic-y += msi.h
generic-y += parport.h
generic-y += percpu.h
generic-y += preempt.h
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index c32a77f..927c335 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -25,7 +25,7 @@ config PCI_MSI
If you don't know what to do here, say Y.
config PCI_MSI_IRQ_DOMAIN
- def_bool ARC || ARM || ARM64 || X86
+ def_bool ARC || ARM || ARM64 || MIPS || X86
depends on PCI_MSI
select GENERIC_MSI_IRQ_DOMAIN
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 7/9] PCI: host: brcmstb: add MSI capability
2017-10-11 22:34 ` Jim Quinlan
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
This commit adds MSI to the Broadcom STB PCIe host controller. It does
not add MSIX since that functionality is not in the HW. The MSI
controller is physically located within the PCIe block, however, there
is no reason why the MSI controller could not be moved elsewhere in
the future.
Since the internal Brcmstb MSI controller is intertwined with the PCIe
controller, it is not its own platform device but rather part of the
PCIe platform device.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Kconfig | 12 ++
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-brcmstb-msi.c | 318 +++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.c | 72 +++++++--
drivers/pci/host/pci-brcmstb.h | 26 +++
5 files changed, 419 insertions(+), 10 deletions(-)
create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b9b4f11..54aa5d2 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -228,4 +228,16 @@ config PCI_BRCMSTB
default ARCH_BRCMSTB || BMIPS_GENERIC
help
Adds support for Broadcom Settop Box PCIe host controller.
+ To compile this driver as a module, choose m here.
+
+config PCI_BRCMSTB_MSI
+ bool "Broadcom Brcmstb PCIe MSI support"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ depends on OF
+ depends on PCI_MSI
+ default PCI_BRCMSTB
+ help
+ Say Y here if you want to enable MSI support for Broadcom's iProc
+ PCIe controller
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index c283321..1026d6f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
+obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb-msi.c b/drivers/pci/host/pci-brcmstb-msi.c
new file mode 100644
index 0000000..c805e2f
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb-msi.c
@@ -0,0 +1,318 @@
+/*
+ * Copyright (C) 2015-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/bitops.h>
+#include <linux/compiler.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/types.h>
+
+#include "pci-brcmstb.h"
+
+#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
+#define PCIE_MSI_INTR2_BASE 0x4500
+#define PCIE_MISC_MSI_BAR_CONFIG_LO 0x4044
+#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
+
+/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
+#define STATUS 0x0
+#define SET 0x4
+#define CLR 0x8
+#define MASK_STATUS 0xc
+#define MASK_SET 0x10
+#define MASK_CLR 0x14
+
+struct brcm_msi {
+ struct irq_domain *msi_domain;
+ struct irq_domain *inner_domain;
+ struct mutex lock; /* guards the alloc/free operations */
+ u64 target_addr;
+ int irq;
+ /* intr_base is the base pointer for interrupt status/set/clr regs */
+ void __iomem *intr_base;
+ /* intr_legacy_mask indicates how many bits are MSI interrupts */
+ u32 intr_legacy_mask;
+ /* intr_legacy_offset indicates bit position of MSI_01. It is
+ * to map the register bit position to a hwirq that starts at 0.
+ */
+ u32 intr_legacy_offset;
+ /* used indicates which MSI interrupts have been alloc'd */
+ unsigned long used;
+
+ void __iomem *base;
+ struct device *dev;
+ struct device_node *dn;
+ unsigned int rev;
+};
+
+static struct irq_chip brcm_msi_irq_chip = {
+ .name = "Brcm_MSI",
+ .irq_mask = pci_msi_mask_irq,
+ .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info brcm_msi_domain_info = {
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_PCI_MSIX),
+ .chip = &brcm_msi_irq_chip,
+};
+
+static void brcm_pcie_msi_isr(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct brcm_msi *msi;
+ unsigned long status, virq;
+ u32 mask, bit, hwirq;
+
+ chained_irq_enter(chip, desc);
+ msi = irq_desc_get_handler_data(desc);
+ mask = msi->intr_legacy_mask;
+
+ while ((status = bcm_readl(msi->intr_base + STATUS) & mask)) {
+ for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
+ /* clear the interrupt */
+ bcm_writel(1 << bit, msi->intr_base + CLR);
+
+ /* Account for legacy interrupt offset */
+ hwirq = bit - msi->intr_legacy_offset;
+
+ virq = irq_find_mapping(msi->inner_domain, hwirq);
+ if (virq) {
+ if (msi->used & (1 << hwirq))
+ generic_handle_irq(virq);
+ else
+ dev_info(msi->dev, "unhandled MSI %d\n",
+ hwirq);
+ } else {
+ /* Unknown MSI, just clear it */
+ dev_dbg(msi->dev, "unexpected MSI\n");
+ }
+ }
+ }
+ chained_irq_exit(chip, desc);
+}
+
+static void brcm_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
+ u32 temp;
+
+ msg->address_lo = lower_32_bits(msi->target_addr);
+ msg->address_hi = upper_32_bits(msi->target_addr);
+ temp = bcm_readl(msi->base + PCIE_MISC_MSI_DATA_CONFIG);
+ msg->data = ((temp >> 16) & (temp & 0xffff)) | data->hwirq;
+}
+
+static int brcm_msi_set_affinity(struct irq_data *irq_data,
+ const struct cpumask *mask, bool force)
+{
+ return -EINVAL;
+}
+
+static struct irq_chip brcm_msi_bottom_irq_chip = {
+ .name = "Brcm MSI",
+ .irq_compose_msi_msg = brcm_compose_msi_msg,
+ .irq_set_affinity = brcm_msi_set_affinity,
+};
+
+static int brcm_msi_alloc(struct brcm_msi *msi)
+{
+ int bit, hwirq;
+
+ mutex_lock(&msi->lock);
+ bit = ~msi->used ? ffz(msi->used) : -1;
+
+ if (bit >= 0 && bit < BRCM_INT_PCI_MSI_NR) {
+ msi->used |= (1 << bit);
+ hwirq = bit - msi->intr_legacy_offset;
+ } else {
+ hwirq = -ENOSPC;
+ }
+
+ mutex_unlock(&msi->lock);
+ return hwirq;
+}
+
+static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq)
+{
+ mutex_lock(&msi->lock);
+ msi->used &= ~(1 << (hwirq + msi->intr_legacy_offset));
+ mutex_unlock(&msi->lock);
+}
+
+static int brcm_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *args)
+{
+ struct brcm_msi *msi = domain->host_data;
+ int hwirq;
+
+ hwirq = brcm_msi_alloc(msi);
+
+ if (hwirq < 0)
+ return hwirq;
+
+ irq_domain_set_info(domain, virq, (irq_hw_number_t)hwirq,
+ &brcm_msi_bottom_irq_chip, domain->host_data,
+ handle_simple_irq, NULL, NULL);
+ return 0;
+}
+
+static void brcm_irq_domain_free(struct irq_domain *domain,
+ unsigned int virq, unsigned int nr_irqs)
+{
+ struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+ struct brcm_msi *msi = irq_data_get_irq_chip_data(d);
+
+ brcm_msi_free(msi, d->hwirq);
+}
+
+void brcm_msi_set_regs(struct brcm_msi *msi)
+{
+ u32 data_val, msi_lo, msi_hi;
+
+ if (msi->rev >= BRCM_PCIE_HW_REV_33) {
+ /* ffe0 -- least sig 5 bits are 0 indicating 32 msgs
+ * 6540 -- this is our arbitrary unique data value
+ */
+ data_val = 0xffe06540;
+ } else {
+ /* fff8 -- least sig 3 bits are 0 indicating 8 msgs
+ * 6540 -- this is our arbitrary unique data value
+ */
+ data_val = 0xfff86540;
+ }
+
+ /* Make sure we are not masking MSIs. Note that MSIs can be masked,
+ * but that occurs on the PCIe EP device
+ */
+ bcm_writel(0xffffffff & msi->intr_legacy_mask,
+ msi->intr_base + MASK_CLR);
+
+ msi_lo = lower_32_bits(msi->target_addr);
+ msi_hi = upper_32_bits(msi->target_addr);
+ /* The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
+ * enable, which we set to 1.
+ */
+ bcm_writel(msi_lo | 1, msi->base + PCIE_MISC_MSI_BAR_CONFIG_LO);
+ bcm_writel(msi_hi, msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
+ bcm_writel(data_val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
+}
+EXPORT_SYMBOL(brcm_msi_set_regs);
+
+static const struct irq_domain_ops msi_domain_ops = {
+ .alloc = brcm_irq_domain_alloc,
+ .free = brcm_irq_domain_free,
+};
+
+static int brcm_allocate_domains(struct brcm_msi *msi)
+{
+ struct fwnode_handle *fwnode = of_node_to_fwnode(msi->dn);
+
+ msi->inner_domain = irq_domain_add_linear(NULL, BRCM_INT_PCI_MSI_NR,
+ &msi_domain_ops, msi);
+ if (!msi->inner_domain) {
+ dev_err(msi->dev, "failed to create IRQ domain\n");
+ return -ENOMEM;
+ }
+
+ msi->msi_domain = pci_msi_create_irq_domain(fwnode,
+ &brcm_msi_domain_info,
+ msi->inner_domain);
+ if (!msi->msi_domain) {
+ dev_err(msi->dev, "failed to create MSI domain\n");
+ irq_domain_remove(msi->inner_domain);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void brcm_free_domains(struct brcm_msi *msi)
+{
+ irq_domain_remove(msi->msi_domain);
+ irq_domain_remove(msi->inner_domain);
+}
+
+void brcm_msi_remove(struct brcm_msi *msi)
+{
+ if (!msi)
+ return;
+ irq_set_chained_handler(msi->irq, NULL);
+ irq_set_handler_data(msi->irq, NULL);
+ brcm_free_domains(msi);
+}
+EXPORT_SYMBOL(brcm_msi_remove);
+
+int brcm_msi_probe(struct platform_device *pdev, struct brcm_info *info)
+{
+ struct brcm_msi *msi;
+ int irq, ret;
+
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 1);
+ if (irq <= 0) {
+ dev_err(&pdev->dev, "cannot map msi intr\n");
+ return -ENODEV;
+ }
+
+ msi = devm_kzalloc(&pdev->dev, sizeof(struct brcm_msi), GFP_KERNEL);
+ if (!msi)
+ return -ENOMEM;
+
+ msi->dev = &pdev->dev;
+ msi->base = info->base;
+ msi->rev = info->rev;
+ msi->dn = pdev->dev.of_node;
+ msi->target_addr = info->msi_target_addr;
+ msi->irq = irq;
+
+ ret = brcm_allocate_domains(msi);
+ if (ret)
+ return ret;
+
+ irq_set_chained_handler_and_data(msi->irq, brcm_pcie_msi_isr, msi);
+
+ if (msi->rev >= BRCM_PCIE_HW_REV_33) {
+ msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
+ /* This version of PCIe hw has only 32 intr bits
+ * starting at bit position 0.
+ */
+ msi->intr_legacy_mask = 0xffffffff;
+ msi->intr_legacy_offset = 0x0;
+ msi->used = 0x0;
+
+ } else {
+ msi->intr_base = msi->base + PCIE_INTR2_CPU_BASE;
+ /* This version of PCIe hw has only 8 intr bits starting
+ * at bit position 24.
+ */
+ msi->intr_legacy_mask = 0xff000000;
+ msi->intr_legacy_offset = 24;
+ msi->used = 0x00ffffff;
+ }
+
+ brcm_msi_set_regs(msi);
+ info->msi = msi;
+
+ return 0;
+}
+EXPORT_SYMBOL(brcm_msi_probe);
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
index 03c0da9..7a8ad43 100644
--- a/drivers/pci/host/pci-brcmstb.c
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -22,6 +22,7 @@
#include <linux/list.h>
#include <linux/log2.h>
#include <linux/module.h>
+#include <linux/msi.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
@@ -327,10 +328,13 @@ struct brcm_pcie {
int num_out_wins;
bool ssc;
int gen;
+ u64 msi_target_addr;
struct brcm_window out_wins[BRCM_NUM_PCI_OUT_WINS];
struct list_head resources;
struct device *dev;
struct list_head pwr_supplies;
+ struct brcm_msi *msi;
+ bool msi_internal;
unsigned int rev;
unsigned int num;
bool bridge_setup_done;
@@ -781,6 +785,7 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
void __iomem *base = pcie->base;
unsigned int scb_size_val;
u64 rc_bar2_size = 0, rc_bar2_offset = 0, total_mem_size = 0;
+ u64 msi_target_addr;
u32 tmp, burst;
int i;
@@ -824,14 +829,17 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
/* The PCI host controller by design must set the inbound
* viewport to be a contiguous arrangement of all of the
* system's memory. In addition, its size mut be a power of
- * two. To further complicate matters, the viewport must
- * start on a pci-address that is aligned on a multiple of its
- * size. If a portion of the viewport does not represent
- * system memory -- e.g. 3GB of memory requires a 4GB viewport
- * -- we can map the outbound memory in or after 3GB and even
- * though the viewport will overlap the outbound memory the
- * controller will know to send outbound memory downstream and
- * everything else upstream.
+ * two. Further, the MSI target address must NOT be placed
+ * inside this region, as the decoding logic will consider its
+ * address to be inbound memory traffic. To further
+ * complicate matters, the viewport must start on a
+ * pci-address that is aligned on a multiple of its size.
+ * If a portion of the viewport does not represent system
+ * memory -- e.g. 3GB of memory requires a 4GB viewport --
+ * we can map the outbound memory in or after 3GB and even
+ * though the viewport will overlap the outbound memory
+ * the controller will know to send outbound memory downstream
+ * and everything else upstream.
*/
rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
@@ -846,6 +854,14 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
if (total_mem_size <= 0xc0000000ULL &&
rc_bar2_size <= 0x100000000ULL) {
rc_bar2_offset = 0;
+ /* If the viewport is less then 4GB we can fit
+ * the MSI target address under 4GB. Otherwise
+ * put it right below 64GB.
+ */
+ msi_target_addr =
+ (rc_bar2_size == 0x100000000ULL)
+ ? BRCM_MSI_TARGET_ADDR_GT_4GB
+ : BRCM_MSI_TARGET_ADDR_LT_4GB;
} else {
/* The system memory is 4GB or larger so we
* cannot start the inbound region at location
@@ -854,15 +870,24 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
* start it at the 1x multiple of its size
*/
rc_bar2_offset = rc_bar2_size;
- }
+ /* Since we are starting the viewport at 4GB or
+ * higher, put the MSI target address below 4GB
+ */
+ msi_target_addr = BRCM_MSI_TARGET_ADDR_LT_4GB;
+ }
} else {
/* Set simple configuration based on memory sizes
* only. We always start the viewport at address 0,
* and set the MSI target address accordingly.
*/
rc_bar2_offset = 0;
+
+ msi_target_addr = (rc_bar2_size >= 0x100000000ULL)
+ ? BRCM_MSI_TARGET_ADDR_GT_4GB
+ : BRCM_MSI_TARGET_ADDR_LT_4GB;
}
+ pcie->msi_target_addr = msi_target_addr;
tmp = lower_32_bits(rc_bar2_offset);
tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
@@ -1071,6 +1096,9 @@ static int brcm_pcie_resume(struct device *dev)
if (ret)
return ret;
+ if (pcie->msi && pcie->msi_internal)
+ brcm_msi_set_regs(pcie->msi);
+
pcie->suspended = false;
return 0;
@@ -1134,6 +1162,7 @@ static void __attribute__((__section__("pci_fixup_early")))
static void _brcm_pcie_remove(struct brcm_pcie *pcie)
{
+ brcm_msi_remove(pcie->msi);
turn_off(pcie);
clk_disable_unprepare(pcie->clk);
clk_put(pcie->clk);
@@ -1143,7 +1172,7 @@ static void _brcm_pcie_remove(struct brcm_pcie *pcie)
static int brcm_pcie_probe(struct platform_device *pdev)
{
- struct device_node *dn = pdev->dev.of_node;
+ struct device_node *dn = pdev->dev.of_node, *msi_dn;
const struct of_device_id *of_id;
const struct pcie_cfg_data *data;
int i, ret;
@@ -1259,6 +1288,29 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
goto fail;
+ msi_dn = of_parse_phandle(pcie->dn, "msi-parent", 0);
+ /* Use the internal MSI if no msi-parent property */
+ if (!msi_dn)
+ msi_dn = pcie->dn;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_enabled()
+ && msi_dn == pcie->dn) {
+ struct brcm_info info;
+
+ info.rev = pcie->rev;
+ info.msi_target_addr = pcie->msi_target_addr;
+ info.base = pcie->base;
+
+ ret = brcm_msi_probe(pdev, &info);
+ if (ret)
+ dev_err(pcie->dev,
+ "probe of internal MSI failed: %d)", ret);
+ else
+ pcie->msi_internal = true;
+
+ pcie->msi = info.msi;
+ }
+
list_splice_init(&pcie->resources, &bridge->windows);
bridge->dev.parent = &pdev->dev;
bridge->busnr = 0;
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
index 4851be8..f48e368 100644
--- a/drivers/pci/host/pci-brcmstb.h
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -21,11 +21,37 @@
/* Broadcom PCIE Offsets */
#define PCIE_INTR2_CPU_BASE 0x4300
+struct brcm_msi;
+struct brcm_info;
+struct platform_device;
+
dma_addr_t brcm_to_pci(dma_addr_t addr);
dma_addr_t brcm_to_cpu(dma_addr_t addr);
extern struct notifier_block brcmstb_platform_nb;
+#ifdef CONFIG_PCI_BRCMSTB_MSI
+int brcm_msi_probe(struct platform_device *pdev, struct brcm_info *info);
+void brcm_msi_set_regs(struct brcm_msi *chip);
+void brcm_msi_remove(struct brcm_msi *chip);
+#else
+static inline int brcm_msi_probe(struct platform_device *pdev,
+ struct brcm_info *info)
+{
+ return -ENODEV;
+}
+
+static inline void brcm_msi_set_regs(struct brcm_msi *chip) {}
+static inline void brcm_msi_remove(struct brcm_msi *chip) {}
+#endif /* CONFIG_PCI_BRCMSTB_MSI */
+
+struct brcm_info {
+ int rev;
+ u64 msi_target_addr;
+ void __iomem *base;
+ struct brcm_msi *msi;
+};
+
#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
#if defined(CONFIG_MIPS)
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 7/9] PCI: host: brcmstb: add MSI capability
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds MSI to the Broadcom STB PCIe host controller. It does
not add MSIX since that functionality is not in the HW. The MSI
controller is physically located within the PCIe block, however, there
is no reason why the MSI controller could not be moved elsewhere in
the future.
Since the internal Brcmstb MSI controller is intertwined with the PCIe
controller, it is not its own platform device but rather part of the
PCIe platform device.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
drivers/pci/host/Kconfig | 12 ++
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-brcmstb-msi.c | 318 +++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-brcmstb.c | 72 +++++++--
drivers/pci/host/pci-brcmstb.h | 26 +++
5 files changed, 419 insertions(+), 10 deletions(-)
create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b9b4f11..54aa5d2 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -228,4 +228,16 @@ config PCI_BRCMSTB
default ARCH_BRCMSTB || BMIPS_GENERIC
help
Adds support for Broadcom Settop Box PCIe host controller.
+ To compile this driver as a module, choose m here.
+
+config PCI_BRCMSTB_MSI
+ bool "Broadcom Brcmstb PCIe MSI support"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ depends on OF
+ depends on PCI_MSI
+ default PCI_BRCMSTB
+ help
+ Say Y here if you want to enable MSI support for Broadcom's iProc
+ PCIe controller
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index c283321..1026d6f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
+obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/host/pci-brcmstb-msi.c b/drivers/pci/host/pci-brcmstb-msi.c
new file mode 100644
index 0000000..c805e2f
--- /dev/null
+++ b/drivers/pci/host/pci-brcmstb-msi.c
@@ -0,0 +1,318 @@
+/*
+ * Copyright (C) 2015-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/bitops.h>
+#include <linux/compiler.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/types.h>
+
+#include "pci-brcmstb.h"
+
+#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
+#define PCIE_MSI_INTR2_BASE 0x4500
+#define PCIE_MISC_MSI_BAR_CONFIG_LO 0x4044
+#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
+
+/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
+#define STATUS 0x0
+#define SET 0x4
+#define CLR 0x8
+#define MASK_STATUS 0xc
+#define MASK_SET 0x10
+#define MASK_CLR 0x14
+
+struct brcm_msi {
+ struct irq_domain *msi_domain;
+ struct irq_domain *inner_domain;
+ struct mutex lock; /* guards the alloc/free operations */
+ u64 target_addr;
+ int irq;
+ /* intr_base is the base pointer for interrupt status/set/clr regs */
+ void __iomem *intr_base;
+ /* intr_legacy_mask indicates how many bits are MSI interrupts */
+ u32 intr_legacy_mask;
+ /* intr_legacy_offset indicates bit position of MSI_01. It is
+ * to map the register bit position to a hwirq that starts at 0.
+ */
+ u32 intr_legacy_offset;
+ /* used indicates which MSI interrupts have been alloc'd */
+ unsigned long used;
+
+ void __iomem *base;
+ struct device *dev;
+ struct device_node *dn;
+ unsigned int rev;
+};
+
+static struct irq_chip brcm_msi_irq_chip = {
+ .name = "Brcm_MSI",
+ .irq_mask = pci_msi_mask_irq,
+ .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info brcm_msi_domain_info = {
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_PCI_MSIX),
+ .chip = &brcm_msi_irq_chip,
+};
+
+static void brcm_pcie_msi_isr(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct brcm_msi *msi;
+ unsigned long status, virq;
+ u32 mask, bit, hwirq;
+
+ chained_irq_enter(chip, desc);
+ msi = irq_desc_get_handler_data(desc);
+ mask = msi->intr_legacy_mask;
+
+ while ((status = bcm_readl(msi->intr_base + STATUS) & mask)) {
+ for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
+ /* clear the interrupt */
+ bcm_writel(1 << bit, msi->intr_base + CLR);
+
+ /* Account for legacy interrupt offset */
+ hwirq = bit - msi->intr_legacy_offset;
+
+ virq = irq_find_mapping(msi->inner_domain, hwirq);
+ if (virq) {
+ if (msi->used & (1 << hwirq))
+ generic_handle_irq(virq);
+ else
+ dev_info(msi->dev, "unhandled MSI %d\n",
+ hwirq);
+ } else {
+ /* Unknown MSI, just clear it */
+ dev_dbg(msi->dev, "unexpected MSI\n");
+ }
+ }
+ }
+ chained_irq_exit(chip, desc);
+}
+
+static void brcm_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
+ u32 temp;
+
+ msg->address_lo = lower_32_bits(msi->target_addr);
+ msg->address_hi = upper_32_bits(msi->target_addr);
+ temp = bcm_readl(msi->base + PCIE_MISC_MSI_DATA_CONFIG);
+ msg->data = ((temp >> 16) & (temp & 0xffff)) | data->hwirq;
+}
+
+static int brcm_msi_set_affinity(struct irq_data *irq_data,
+ const struct cpumask *mask, bool force)
+{
+ return -EINVAL;
+}
+
+static struct irq_chip brcm_msi_bottom_irq_chip = {
+ .name = "Brcm MSI",
+ .irq_compose_msi_msg = brcm_compose_msi_msg,
+ .irq_set_affinity = brcm_msi_set_affinity,
+};
+
+static int brcm_msi_alloc(struct brcm_msi *msi)
+{
+ int bit, hwirq;
+
+ mutex_lock(&msi->lock);
+ bit = ~msi->used ? ffz(msi->used) : -1;
+
+ if (bit >= 0 && bit < BRCM_INT_PCI_MSI_NR) {
+ msi->used |= (1 << bit);
+ hwirq = bit - msi->intr_legacy_offset;
+ } else {
+ hwirq = -ENOSPC;
+ }
+
+ mutex_unlock(&msi->lock);
+ return hwirq;
+}
+
+static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq)
+{
+ mutex_lock(&msi->lock);
+ msi->used &= ~(1 << (hwirq + msi->intr_legacy_offset));
+ mutex_unlock(&msi->lock);
+}
+
+static int brcm_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *args)
+{
+ struct brcm_msi *msi = domain->host_data;
+ int hwirq;
+
+ hwirq = brcm_msi_alloc(msi);
+
+ if (hwirq < 0)
+ return hwirq;
+
+ irq_domain_set_info(domain, virq, (irq_hw_number_t)hwirq,
+ &brcm_msi_bottom_irq_chip, domain->host_data,
+ handle_simple_irq, NULL, NULL);
+ return 0;
+}
+
+static void brcm_irq_domain_free(struct irq_domain *domain,
+ unsigned int virq, unsigned int nr_irqs)
+{
+ struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+ struct brcm_msi *msi = irq_data_get_irq_chip_data(d);
+
+ brcm_msi_free(msi, d->hwirq);
+}
+
+void brcm_msi_set_regs(struct brcm_msi *msi)
+{
+ u32 data_val, msi_lo, msi_hi;
+
+ if (msi->rev >= BRCM_PCIE_HW_REV_33) {
+ /* ffe0 -- least sig 5 bits are 0 indicating 32 msgs
+ * 6540 -- this is our arbitrary unique data value
+ */
+ data_val = 0xffe06540;
+ } else {
+ /* fff8 -- least sig 3 bits are 0 indicating 8 msgs
+ * 6540 -- this is our arbitrary unique data value
+ */
+ data_val = 0xfff86540;
+ }
+
+ /* Make sure we are not masking MSIs. Note that MSIs can be masked,
+ * but that occurs on the PCIe EP device
+ */
+ bcm_writel(0xffffffff & msi->intr_legacy_mask,
+ msi->intr_base + MASK_CLR);
+
+ msi_lo = lower_32_bits(msi->target_addr);
+ msi_hi = upper_32_bits(msi->target_addr);
+ /* The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
+ * enable, which we set to 1.
+ */
+ bcm_writel(msi_lo | 1, msi->base + PCIE_MISC_MSI_BAR_CONFIG_LO);
+ bcm_writel(msi_hi, msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
+ bcm_writel(data_val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
+}
+EXPORT_SYMBOL(brcm_msi_set_regs);
+
+static const struct irq_domain_ops msi_domain_ops = {
+ .alloc = brcm_irq_domain_alloc,
+ .free = brcm_irq_domain_free,
+};
+
+static int brcm_allocate_domains(struct brcm_msi *msi)
+{
+ struct fwnode_handle *fwnode = of_node_to_fwnode(msi->dn);
+
+ msi->inner_domain = irq_domain_add_linear(NULL, BRCM_INT_PCI_MSI_NR,
+ &msi_domain_ops, msi);
+ if (!msi->inner_domain) {
+ dev_err(msi->dev, "failed to create IRQ domain\n");
+ return -ENOMEM;
+ }
+
+ msi->msi_domain = pci_msi_create_irq_domain(fwnode,
+ &brcm_msi_domain_info,
+ msi->inner_domain);
+ if (!msi->msi_domain) {
+ dev_err(msi->dev, "failed to create MSI domain\n");
+ irq_domain_remove(msi->inner_domain);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void brcm_free_domains(struct brcm_msi *msi)
+{
+ irq_domain_remove(msi->msi_domain);
+ irq_domain_remove(msi->inner_domain);
+}
+
+void brcm_msi_remove(struct brcm_msi *msi)
+{
+ if (!msi)
+ return;
+ irq_set_chained_handler(msi->irq, NULL);
+ irq_set_handler_data(msi->irq, NULL);
+ brcm_free_domains(msi);
+}
+EXPORT_SYMBOL(brcm_msi_remove);
+
+int brcm_msi_probe(struct platform_device *pdev, struct brcm_info *info)
+{
+ struct brcm_msi *msi;
+ int irq, ret;
+
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 1);
+ if (irq <= 0) {
+ dev_err(&pdev->dev, "cannot map msi intr\n");
+ return -ENODEV;
+ }
+
+ msi = devm_kzalloc(&pdev->dev, sizeof(struct brcm_msi), GFP_KERNEL);
+ if (!msi)
+ return -ENOMEM;
+
+ msi->dev = &pdev->dev;
+ msi->base = info->base;
+ msi->rev = info->rev;
+ msi->dn = pdev->dev.of_node;
+ msi->target_addr = info->msi_target_addr;
+ msi->irq = irq;
+
+ ret = brcm_allocate_domains(msi);
+ if (ret)
+ return ret;
+
+ irq_set_chained_handler_and_data(msi->irq, brcm_pcie_msi_isr, msi);
+
+ if (msi->rev >= BRCM_PCIE_HW_REV_33) {
+ msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
+ /* This version of PCIe hw has only 32 intr bits
+ * starting at bit position 0.
+ */
+ msi->intr_legacy_mask = 0xffffffff;
+ msi->intr_legacy_offset = 0x0;
+ msi->used = 0x0;
+
+ } else {
+ msi->intr_base = msi->base + PCIE_INTR2_CPU_BASE;
+ /* This version of PCIe hw has only 8 intr bits starting
+ * at bit position 24.
+ */
+ msi->intr_legacy_mask = 0xff000000;
+ msi->intr_legacy_offset = 24;
+ msi->used = 0x00ffffff;
+ }
+
+ brcm_msi_set_regs(msi);
+ info->msi = msi;
+
+ return 0;
+}
+EXPORT_SYMBOL(brcm_msi_probe);
diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
index 03c0da9..7a8ad43 100644
--- a/drivers/pci/host/pci-brcmstb.c
+++ b/drivers/pci/host/pci-brcmstb.c
@@ -22,6 +22,7 @@
#include <linux/list.h>
#include <linux/log2.h>
#include <linux/module.h>
+#include <linux/msi.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
@@ -327,10 +328,13 @@ struct brcm_pcie {
int num_out_wins;
bool ssc;
int gen;
+ u64 msi_target_addr;
struct brcm_window out_wins[BRCM_NUM_PCI_OUT_WINS];
struct list_head resources;
struct device *dev;
struct list_head pwr_supplies;
+ struct brcm_msi *msi;
+ bool msi_internal;
unsigned int rev;
unsigned int num;
bool bridge_setup_done;
@@ -781,6 +785,7 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
void __iomem *base = pcie->base;
unsigned int scb_size_val;
u64 rc_bar2_size = 0, rc_bar2_offset = 0, total_mem_size = 0;
+ u64 msi_target_addr;
u32 tmp, burst;
int i;
@@ -824,14 +829,17 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
/* The PCI host controller by design must set the inbound
* viewport to be a contiguous arrangement of all of the
* system's memory. In addition, its size mut be a power of
- * two. To further complicate matters, the viewport must
- * start on a pci-address that is aligned on a multiple of its
- * size. If a portion of the viewport does not represent
- * system memory -- e.g. 3GB of memory requires a 4GB viewport
- * -- we can map the outbound memory in or after 3GB and even
- * though the viewport will overlap the outbound memory the
- * controller will know to send outbound memory downstream and
- * everything else upstream.
+ * two. Further, the MSI target address must NOT be placed
+ * inside this region, as the decoding logic will consider its
+ * address to be inbound memory traffic. To further
+ * complicate matters, the viewport must start on a
+ * pci-address that is aligned on a multiple of its size.
+ * If a portion of the viewport does not represent system
+ * memory -- e.g. 3GB of memory requires a 4GB viewport --
+ * we can map the outbound memory in or after 3GB and even
+ * though the viewport will overlap the outbound memory
+ * the controller will know to send outbound memory downstream
+ * and everything else upstream.
*/
rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
@@ -846,6 +854,14 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
if (total_mem_size <= 0xc0000000ULL &&
rc_bar2_size <= 0x100000000ULL) {
rc_bar2_offset = 0;
+ /* If the viewport is less then 4GB we can fit
+ * the MSI target address under 4GB. Otherwise
+ * put it right below 64GB.
+ */
+ msi_target_addr =
+ (rc_bar2_size == 0x100000000ULL)
+ ? BRCM_MSI_TARGET_ADDR_GT_4GB
+ : BRCM_MSI_TARGET_ADDR_LT_4GB;
} else {
/* The system memory is 4GB or larger so we
* cannot start the inbound region at location
@@ -854,15 +870,24 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
* start it at the 1x multiple of its size
*/
rc_bar2_offset = rc_bar2_size;
- }
+ /* Since we are starting the viewport at 4GB or
+ * higher, put the MSI target address below 4GB
+ */
+ msi_target_addr = BRCM_MSI_TARGET_ADDR_LT_4GB;
+ }
} else {
/* Set simple configuration based on memory sizes
* only. We always start the viewport@address 0,
* and set the MSI target address accordingly.
*/
rc_bar2_offset = 0;
+
+ msi_target_addr = (rc_bar2_size >= 0x100000000ULL)
+ ? BRCM_MSI_TARGET_ADDR_GT_4GB
+ : BRCM_MSI_TARGET_ADDR_LT_4GB;
}
+ pcie->msi_target_addr = msi_target_addr;
tmp = lower_32_bits(rc_bar2_offset);
tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
@@ -1071,6 +1096,9 @@ static int brcm_pcie_resume(struct device *dev)
if (ret)
return ret;
+ if (pcie->msi && pcie->msi_internal)
+ brcm_msi_set_regs(pcie->msi);
+
pcie->suspended = false;
return 0;
@@ -1134,6 +1162,7 @@ static void __attribute__((__section__("pci_fixup_early")))
static void _brcm_pcie_remove(struct brcm_pcie *pcie)
{
+ brcm_msi_remove(pcie->msi);
turn_off(pcie);
clk_disable_unprepare(pcie->clk);
clk_put(pcie->clk);
@@ -1143,7 +1172,7 @@ static void _brcm_pcie_remove(struct brcm_pcie *pcie)
static int brcm_pcie_probe(struct platform_device *pdev)
{
- struct device_node *dn = pdev->dev.of_node;
+ struct device_node *dn = pdev->dev.of_node, *msi_dn;
const struct of_device_id *of_id;
const struct pcie_cfg_data *data;
int i, ret;
@@ -1259,6 +1288,29 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
goto fail;
+ msi_dn = of_parse_phandle(pcie->dn, "msi-parent", 0);
+ /* Use the internal MSI if no msi-parent property */
+ if (!msi_dn)
+ msi_dn = pcie->dn;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_enabled()
+ && msi_dn == pcie->dn) {
+ struct brcm_info info;
+
+ info.rev = pcie->rev;
+ info.msi_target_addr = pcie->msi_target_addr;
+ info.base = pcie->base;
+
+ ret = brcm_msi_probe(pdev, &info);
+ if (ret)
+ dev_err(pcie->dev,
+ "probe of internal MSI failed: %d)", ret);
+ else
+ pcie->msi_internal = true;
+
+ pcie->msi = info.msi;
+ }
+
list_splice_init(&pcie->resources, &bridge->windows);
bridge->dev.parent = &pdev->dev;
bridge->busnr = 0;
diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
index 4851be8..f48e368 100644
--- a/drivers/pci/host/pci-brcmstb.h
+++ b/drivers/pci/host/pci-brcmstb.h
@@ -21,11 +21,37 @@
/* Broadcom PCIE Offsets */
#define PCIE_INTR2_CPU_BASE 0x4300
+struct brcm_msi;
+struct brcm_info;
+struct platform_device;
+
dma_addr_t brcm_to_pci(dma_addr_t addr);
dma_addr_t brcm_to_cpu(dma_addr_t addr);
extern struct notifier_block brcmstb_platform_nb;
+#ifdef CONFIG_PCI_BRCMSTB_MSI
+int brcm_msi_probe(struct platform_device *pdev, struct brcm_info *info);
+void brcm_msi_set_regs(struct brcm_msi *chip);
+void brcm_msi_remove(struct brcm_msi *chip);
+#else
+static inline int brcm_msi_probe(struct platform_device *pdev,
+ struct brcm_info *info)
+{
+ return -ENODEV;
+}
+
+static inline void brcm_msi_set_regs(struct brcm_msi *chip) {}
+static inline void brcm_msi_remove(struct brcm_msi *chip) {}
+#endif /* CONFIG_PCI_BRCMSTB_MSI */
+
+struct brcm_info {
+ int rev;
+ u64 msi_target_addr;
+ void __iomem *base;
+ struct brcm_msi *msi;
+};
+
#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
#if defined(CONFIG_MIPS)
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 8/9] MIPS: BMIPS: add PCI bindings for 7425, 7435
2017-10-11 22:34 ` Jim Quinlan
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
Adds the PCIe nodes for the Broadcom STB PCIe root complex.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/mips/boot/dts/brcm/bcm7425.dtsi | 25 +++++++++++++++++++++++++
arch/mips/boot/dts/brcm/bcm7435.dtsi | 26 ++++++++++++++++++++++++++
arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 ++++
4 files changed, 59 insertions(+)
diff --git a/arch/mips/boot/dts/brcm/bcm7425.dtsi b/arch/mips/boot/dts/brcm/bcm7425.dtsi
index f56fb25..2c416f6 100644
--- a/arch/mips/boot/dts/brcm/bcm7425.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7425.dtsi
@@ -494,4 +494,29 @@
status = "disabled";
};
};
+
+ pcie: pcie@10410000 {
+ reg = <0x10410000 0x830c>;
+ compatible = "brcm,bcm7425-pcie", "brcm,pci-plat-dev";
+ interrupts = <37>, <37>;
+ interrupt-names = "pcie", "msi";
+ interrupt-parent = <&periph_intc>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ linux,pci-domain = <0>;
+ brcm,ssc;
+ msi-controller;
+ #interrupt-cells = <1>;
+ /* 4x128mb windows */
+ ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0 0x08000000>,
+ <0x2000000 0x0 0xd8000000 0xd8000000 0 0x08000000>,
+ <0x2000000 0x0 0xe0000000 0xe0000000 0 0x08000000>,
+ <0x2000000 0x0 0xe8000000 0xe8000000 0 0x08000000>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &periph_intc 33
+ 0 0 0 2 &periph_intc 34
+ 0 0 0 3 &periph_intc 35
+ 0 0 0 4 &periph_intc 36>;
+ };
+
};
diff --git a/arch/mips/boot/dts/brcm/bcm7435.dtsi b/arch/mips/boot/dts/brcm/bcm7435.dtsi
index f2cead2..2f869e5 100644
--- a/arch/mips/boot/dts/brcm/bcm7435.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7435.dtsi
@@ -509,4 +509,30 @@
status = "disabled";
};
};
+
+ pcie: pcie@10410000 {
+ reg = <0x10410000 0x930c>;
+ interrupts = <0x27>, <0x27>;
+ interrupt-names = "pcie", "msi";
+ interrupt-parent = <&periph_intc>;
+ compatible = "brcm,bcm7435-pcie", "brcm,pci-plat-dev";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ linux,pci-domain = <0>;
+ brcm,ssc;
+ msi-controller;
+ #interrupt-cells = <1>;
+ /* 4x128mb windows */
+ ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0 0x08000000>,
+ <0x2000000 0x0 0xd8000000 0xd8000000 0 0x08000000>,
+ <0x2000000 0x0 0xe0000000 0xe0000000 0 0x08000000>,
+ <0x2000000 0x0 0xe8000000 0xe8000000 0 0x08000000>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &periph_intc 35
+ 0 0 0 2 &periph_intc 36
+ 0 0 0 3 &periph_intc 37
+ 0 0 0 4 &periph_intc 38>;
+ status = "disabled";
+ };
+
};
diff --git a/arch/mips/boot/dts/brcm/bcm97425svmb.dts b/arch/mips/boot/dts/brcm/bcm97425svmb.dts
index 73aa006..3a87ac5 100644
--- a/arch/mips/boot/dts/brcm/bcm97425svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97425svmb.dts
@@ -143,3 +143,7 @@
&mspi {
status = "okay";
};
+
+&pcie {
+ status = "okay";
+};
diff --git a/arch/mips/boot/dts/brcm/bcm97435svmb.dts b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
index 0a915f3..456d024 100644
--- a/arch/mips/boot/dts/brcm/bcm97435svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
@@ -119,3 +119,7 @@
&mspi {
status = "okay";
};
+
+&pcie {
+ status = "okay";
+};
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 8/9] MIPS: BMIPS: add PCI bindings for 7425, 7435
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
Adds the PCIe nodes for the Broadcom STB PCIe root complex.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/mips/boot/dts/brcm/bcm7425.dtsi | 25 +++++++++++++++++++++++++
arch/mips/boot/dts/brcm/bcm7435.dtsi | 26 ++++++++++++++++++++++++++
arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 ++++
4 files changed, 59 insertions(+)
diff --git a/arch/mips/boot/dts/brcm/bcm7425.dtsi b/arch/mips/boot/dts/brcm/bcm7425.dtsi
index f56fb25..2c416f6 100644
--- a/arch/mips/boot/dts/brcm/bcm7425.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7425.dtsi
@@ -494,4 +494,29 @@
status = "disabled";
};
};
+
+ pcie: pcie at 10410000 {
+ reg = <0x10410000 0x830c>;
+ compatible = "brcm,bcm7425-pcie", "brcm,pci-plat-dev";
+ interrupts = <37>, <37>;
+ interrupt-names = "pcie", "msi";
+ interrupt-parent = <&periph_intc>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ linux,pci-domain = <0>;
+ brcm,ssc;
+ msi-controller;
+ #interrupt-cells = <1>;
+ /* 4x128mb windows */
+ ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0 0x08000000>,
+ <0x2000000 0x0 0xd8000000 0xd8000000 0 0x08000000>,
+ <0x2000000 0x0 0xe0000000 0xe0000000 0 0x08000000>,
+ <0x2000000 0x0 0xe8000000 0xe8000000 0 0x08000000>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &periph_intc 33
+ 0 0 0 2 &periph_intc 34
+ 0 0 0 3 &periph_intc 35
+ 0 0 0 4 &periph_intc 36>;
+ };
+
};
diff --git a/arch/mips/boot/dts/brcm/bcm7435.dtsi b/arch/mips/boot/dts/brcm/bcm7435.dtsi
index f2cead2..2f869e5 100644
--- a/arch/mips/boot/dts/brcm/bcm7435.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7435.dtsi
@@ -509,4 +509,30 @@
status = "disabled";
};
};
+
+ pcie: pcie at 10410000 {
+ reg = <0x10410000 0x930c>;
+ interrupts = <0x27>, <0x27>;
+ interrupt-names = "pcie", "msi";
+ interrupt-parent = <&periph_intc>;
+ compatible = "brcm,bcm7435-pcie", "brcm,pci-plat-dev";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ linux,pci-domain = <0>;
+ brcm,ssc;
+ msi-controller;
+ #interrupt-cells = <1>;
+ /* 4x128mb windows */
+ ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0 0x08000000>,
+ <0x2000000 0x0 0xd8000000 0xd8000000 0 0x08000000>,
+ <0x2000000 0x0 0xe0000000 0xe0000000 0 0x08000000>,
+ <0x2000000 0x0 0xe8000000 0xe8000000 0 0x08000000>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &periph_intc 35
+ 0 0 0 2 &periph_intc 36
+ 0 0 0 3 &periph_intc 37
+ 0 0 0 4 &periph_intc 38>;
+ status = "disabled";
+ };
+
};
diff --git a/arch/mips/boot/dts/brcm/bcm97425svmb.dts b/arch/mips/boot/dts/brcm/bcm97425svmb.dts
index 73aa006..3a87ac5 100644
--- a/arch/mips/boot/dts/brcm/bcm97425svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97425svmb.dts
@@ -143,3 +143,7 @@
&mspi {
status = "okay";
};
+
+&pcie {
+ status = "okay";
+};
diff --git a/arch/mips/boot/dts/brcm/bcm97435svmb.dts b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
index 0a915f3..456d024 100644
--- a/arch/mips/boot/dts/brcm/bcm97435svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
@@ -119,3 +119,7 @@
&mspi {
status = "okay";
};
+
+&pcie {
+ status = "okay";
+};
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 9/9] MIPS: BMIPS: enable PCI
2017-10-11 22:34 ` Jim Quinlan
@ 2017-10-11 22:34 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris,
Jim Quinlan
Adds the Kconfig hooks to enable the Broadcom STB PCIe root complex
driver for Broadcom MIPS systems.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/mips/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index cb7fcc4..83ba54d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -209,6 +209,9 @@ config BMIPS_GENERIC
select BOOT_RAW
select NO_EXCEPT_FILL
select USE_OF
+ select HW_HAS_PCI
+ select PCI_DRIVERS_GENERIC
+ select PCI
select CEVT_R4K
select CSRC_R4K
select SYNC_R4K
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* [PATCH 9/9] MIPS: BMIPS: enable PCI
@ 2017-10-11 22:34 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-11 22:34 UTC (permalink / raw)
To: linux-arm-kernel
Adds the Kconfig hooks to enable the Broadcom STB PCIe root complex
driver for Broadcom MIPS systems.
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
---
arch/mips/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index cb7fcc4..83ba54d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -209,6 +209,9 @@ config BMIPS_GENERIC
select BOOT_RAW
select NO_EXCEPT_FILL
select USE_OF
+ select HW_HAS_PCI
+ select PCI_DRIVERS_GENERIC
+ select PCI
select CEVT_R4K
select CSRC_R4K
select SYNC_R4K
--
1.9.0.138.g2de3478
^ permalink raw reply related [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-12 0:55 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-12 0:55 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
linux-mips, devicetree, linux-pci, Florian Fainelli,
Ralf Baechle, Catalin Marinas, Will Deacon, Bjorn Helgaas,
Rob Herring, Mark Rutland, Gregory Fong, Kevin Cernekee
Hi Jim,
On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
> 1 file changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 0000000..2f699da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,106 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Introduction:
> + The brcmstb host controller closely follows the example set in
> +
> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> +
> + The rest of this document explains some added customizations and
> + offers an example Brcmstb PCIe host controller DT node.
> +
> +Required Properties:
> + reg -- the register start address and length for the PCIe block.
> + Additional start,length pairs may be specified for clock addresses.
> + interrupts -- two interrupts are specified; the first interrupt is for
> + the PCI host controller and the second is for MSI if the built-in
> + MSI controller is to be used.
> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
> + or "brcm,bcm7278-pcie".
> + #address-cells -- the number of address cells for PCI-space.
> + #size-cells -- the number of size cells for PCI-space.
> + ranges -- See [1]; a specification of the outbound windows for the host
> + controller. Each outbound window is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + Due to hardware limitations, there may be a maximum of four
> + non-contiguous ranges specified.
> + #interrupt-cells -- number of cells used to describe the interrupt.
> + interrupt-map-mask -- see [1]; four cells, the first three are zero
> + for our uses and the fourth cell is the mask (val = 0x7) for
> + the legacy interrupt number [1..4].
> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
> + plus the size of the interrupt specifier.
> + linux,pci-domain -- the domain of the host controller.
> +
> +Optional Properties:
> + clocks -- list of clock phandles. If specified, this should list one
> + clock.
> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
> + that if the 'clocks' property is given, 'clock-names' is mandatory,
> + and the name of the clock is expected to be "sw_pcie".
> + dma-ranges -- Similar in structure to ranges, each dma region is
> + specified with a n-tuple. Dma-regions describe the inbound
> + accesses from EP to RC; it translates the pci address that the
> + EP "sees" to the CPU address in memory. This property is needed
> + because the design of the Brcmstb memory subsystem often precludes
> + idenity-mapping between CPU address space and PCIe address space.
> + Each range is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + msi-parent -- if MSI is to be used, this must be a phandle to the
> + msi-parent. If this prop is set to the phandle of the PCIe
> + node, or if the msi-parent prop is missing, the PCIE controller
> + will attempt to use its built in MSI controller.
> + msi-controller -- this property should only be specified if the
> + PCIe controller is using its internal MSI controller.
> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
> + brcm,gen -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
Does this differ from the 'max-link-speed' now documented in
Documentation/devicetree/bindings/pci/pci.txt? If not, might as well use
it, and of_pci_get_max_link_speed().
> + supply-names -- the names of voltage regulators that the root
> + complex should turn off/on/on on suspend/resume/boot. This
> + is a string list.
> + supplies -- A collection of phandles to a regulator nodes, see
> + Documentation/devicetree/bindings/regulator/ for specific
> + bindings. The number and order of phandles must match
> + exactly the number of strings in the "supply-names" property.
> +
> +Example Node:
> +
> +pcie0: pcie@f0460000 {
^^ You've got a tab after the colon. Makes this look funky in my
vim/mutt :)
Brian
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
> + compatible = "brcm,pci-plat-dev";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 47 3
> + 0 0 0 2 &intc 0 48 3
> + 0 0 0 3 &intc 0 49 3
> + 0 0 0 4 &intc 0 50 3>;
> + interrupt-names = "pcie_0_inta",
> + "pcie_0_intb",
> + "pcie_0_intc",
> + "pcie_0_intd";
> + clocks = <&sw_pcie0>;
> + clock-names = "sw_pcie";
> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
> + msi-controller; /* use PCIe's internal MSI controller */
> + brcm,ssc;
> + brcm,gen = <1>;
> + supply-names = "vreg-wifi-pwr";
> + supplies = <&vreg-wifi-pwr>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-12 0:55 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-12 0:55 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee
Hi Jim,
On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
> 1 file changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 0000000..2f699da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,106 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Introduction:
> + The brcmstb host controller closely follows the example set in
> +
> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> +
> + The rest of this document explains some added customizations and
> + offers an example Brcmstb PCIe host controller DT node.
> +
> +Required Properties:
> + reg -- the register start address and length for the PCIe block.
> + Additional start,length pairs may be specified for clock addresses.
> + interrupts -- two interrupts are specified; the first interrupt is for
> + the PCI host controller and the second is for MSI if the built-in
> + MSI controller is to be used.
> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
> + or "brcm,bcm7278-pcie".
> + #address-cells -- the number of address cells for PCI-space.
> + #size-cells -- the number of size cells for PCI-space.
> + ranges -- See [1]; a specification of the outbound windows for the host
> + controller. Each outbound window is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + Due to hardware limitations, there may be a maximum of four
> + non-contiguous ranges specified.
> + #interrupt-cells -- number of cells used to describe the interrupt.
> + interrupt-map-mask -- see [1]; four cells, the first three are zero
> + for our uses and the fourth cell is the mask (val = 0x7) for
> + the legacy interrupt number [1..4].
> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
> + plus the size of the interrupt specifier.
> + linux,pci-domain -- the domain of the host controller.
> +
> +Optional Properties:
> + clocks -- list of clock phandles. If specified, this should list one
> + clock.
> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
> + that if the 'clocks' property is given, 'clock-names' is mandatory,
> + and the name of the clock is expected to be "sw_pcie".
> + dma-ranges -- Similar in structure to ranges, each dma region is
> + specified with a n-tuple. Dma-regions describe the inbound
> + accesses from EP to RC; it translates the pci address that the
> + EP "sees" to the CPU address in memory. This property is needed
> + because the design of the Brcmstb memory subsystem often precludes
> + idenity-mapping between CPU address space and PCIe address space.
> + Each range is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + msi-parent -- if MSI is to be used, this must be a phandle to the
> + msi-parent. If this prop is set to the phandle of the PCIe
> + node, or if the msi-parent prop is missing, the PCIE controller
> + will attempt to use its built in MSI controller.
> + msi-controller -- this property should only be specified if the
> + PCIe controller is using its internal MSI controller.
> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
> + brcm,gen -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
Does this differ from the 'max-link-speed' now documented in
Documentation/devicetree/bindings/pci/pci.txt? If not, might as well use
it, and of_pci_get_max_link_speed().
> + supply-names -- the names of voltage regulators that the root
> + complex should turn off/on/on on suspend/resume/boot. This
> + is a string list.
> + supplies -- A collection of phandles to a regulator nodes, see
> + Documentation/devicetree/bindings/regulator/ for specific
> + bindings. The number and order of phandles must match
> + exactly the number of strings in the "supply-names" property.
> +
> +Example Node:
> +
> +pcie0: pcie@f0460000 {
^^ You've got a tab after the colon. Makes this look funky in my
vim/mutt :)
Brian
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
> + compatible = "brcm,pci-plat-dev";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 47 3
> + 0 0 0 2 &intc 0 48 3
> + 0 0 0 3 &intc 0 49 3
> + 0 0 0 4 &intc 0 50 3>;
> + interrupt-names = "pcie_0_inta",
> + "pcie_0_intb",
> + "pcie_0_intc",
> + "pcie_0_intd";
> + clocks = <&sw_pcie0>;
> + clock-names = "sw_pcie";
> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
> + msi-controller; /* use PCIe's internal MSI controller */
> + brcm,ssc;
> + brcm,gen = <1>;
> + supply-names = "vreg-wifi-pwr";
> + supplies = <&vreg-wifi-pwr>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-12 0:55 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-12 0:55 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, linux-arm-kernel
Hi Jim,
On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
> 1 file changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 0000000..2f699da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,106 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Introduction:
> + The brcmstb host controller closely follows the example set in
> +
> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> +
> + The rest of this document explains some added customizations and
> + offers an example Brcmstb PCIe host controller DT node.
> +
> +Required Properties:
> + reg -- the register start address and length for the PCIe block.
> + Additional start,length pairs may be specified for clock addresses.
> + interrupts -- two interrupts are specified; the first interrupt is for
> + the PCI host controller and the second is for MSI if the built-in
> + MSI controller is to be used.
> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
> + or "brcm,bcm7278-pcie".
> + #address-cells -- the number of address cells for PCI-space.
> + #size-cells -- the number of size cells for PCI-space.
> + ranges -- See [1]; a specification of the outbound windows for the host
> + controller. Each outbound window is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + Due to hardware limitations, there may be a maximum of four
> + non-contiguous ranges specified.
> + #interrupt-cells -- number of cells used to describe the interrupt.
> + interrupt-map-mask -- see [1]; four cells, the first three are zero
> + for our uses and the fourth cell is the mask (val = 0x7) for
> + the legacy interrupt number [1..4].
> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
> + plus the size of the interrupt specifier.
> + linux,pci-domain -- the domain of the host controller.
> +
> +Optional Properties:
> + clocks -- list of clock phandles. If specified, this should list one
> + clock.
> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
> + that if the 'clocks' property is given, 'clock-names' is mandatory,
> + and the name of the clock is expected to be "sw_pcie".
> + dma-ranges -- Similar in structure to ranges, each dma region is
> + specified with a n-tuple. Dma-regions describe the inbound
> + accesses from EP to RC; it translates the pci address that the
> + EP "sees" to the CPU address in memory. This property is needed
> + because the design of the Brcmstb memory subsystem often precludes
> + idenity-mapping between CPU address space and PCIe address space.
> + Each range is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + msi-parent -- if MSI is to be used, this must be a phandle to the
> + msi-parent. If this prop is set to the phandle of the PCIe
> + node, or if the msi-parent prop is missing, the PCIE controller
> + will attempt to use its built in MSI controller.
> + msi-controller -- this property should only be specified if the
> + PCIe controller is using its internal MSI controller.
> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
> + brcm,gen -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
Does this differ from the 'max-link-speed' now documented in
Documentation/devicetree/bindings/pci/pci.txt? If not, might as well use
it, and of_pci_get_max_link_speed().
> + supply-names -- the names of voltage regulators that the root
> + complex should turn off/on/on on suspend/resume/boot. This
> + is a string list.
> + supplies -- A collection of phandles to a regulator nodes, see
> + Documentation/devicetree/bindings/regulator/ for specific
> + bindings. The number and order of phandles must match
> + exactly the number of strings in the "supply-names" property.
> +
> +Example Node:
> +
> +pcie0: pcie@f0460000 {
^^ You've got a tab after the colon. Makes this look funky in my
vim/mutt :)
Brian
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
> + compatible = "brcm,pci-plat-dev";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 47 3
> + 0 0 0 2 &intc 0 48 3
> + 0 0 0 3 &intc 0 49 3
> + 0 0 0 4 &intc 0 50 3>;
> + interrupt-names = "pcie_0_inta",
> + "pcie_0_intb",
> + "pcie_0_intc",
> + "pcie_0_intd";
> + clocks = <&sw_pcie0>;
> + clock-names = "sw_pcie";
> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
> + msi-controller; /* use PCIe's internal MSI controller */
> + brcm,ssc;
> + brcm,gen = <1>;
> + supply-names = "vreg-wifi-pwr";
> + supplies = <&vreg-wifi-pwr>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-12 0:55 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-12 0:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jim,
On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
> 1 file changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 0000000..2f699da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,106 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Introduction:
> + The brcmstb host controller closely follows the example set in
> +
> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> +
> + The rest of this document explains some added customizations and
> + offers an example Brcmstb PCIe host controller DT node.
> +
> +Required Properties:
> + reg -- the register start address and length for the PCIe block.
> + Additional start,length pairs may be specified for clock addresses.
> + interrupts -- two interrupts are specified; the first interrupt is for
> + the PCI host controller and the second is for MSI if the built-in
> + MSI controller is to be used.
> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
> + or "brcm,bcm7278-pcie".
> + #address-cells -- the number of address cells for PCI-space.
> + #size-cells -- the number of size cells for PCI-space.
> + ranges -- See [1]; a specification of the outbound windows for the host
> + controller. Each outbound window is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + Due to hardware limitations, there may be a maximum of four
> + non-contiguous ranges specified.
> + #interrupt-cells -- number of cells used to describe the interrupt.
> + interrupt-map-mask -- see [1]; four cells, the first three are zero
> + for our uses and the fourth cell is the mask (val = 0x7) for
> + the legacy interrupt number [1..4].
> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
> + plus the size of the interrupt specifier.
> + linux,pci-domain -- the domain of the host controller.
> +
> +Optional Properties:
> + clocks -- list of clock phandles. If specified, this should list one
> + clock.
> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
> + that if the 'clocks' property is given, 'clock-names' is mandatory,
> + and the name of the clock is expected to be "sw_pcie".
> + dma-ranges -- Similar in structure to ranges, each dma region is
> + specified with a n-tuple. Dma-regions describe the inbound
> + accesses from EP to RC; it translates the pci address that the
> + EP "sees" to the CPU address in memory. This property is needed
> + because the design of the Brcmstb memory subsystem often precludes
> + idenity-mapping between CPU address space and PCIe address space.
> + Each range is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + msi-parent -- if MSI is to be used, this must be a phandle to the
> + msi-parent. If this prop is set to the phandle of the PCIe
> + node, or if the msi-parent prop is missing, the PCIE controller
> + will attempt to use its built in MSI controller.
> + msi-controller -- this property should only be specified if the
> + PCIe controller is using its internal MSI controller.
> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
> + brcm,gen -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
Does this differ from the 'max-link-speed' now documented in
Documentation/devicetree/bindings/pci/pci.txt? If not, might as well use
it, and of_pci_get_max_link_speed().
> + supply-names -- the names of voltage regulators that the root
> + complex should turn off/on/on on suspend/resume/boot. This
> + is a string list.
> + supplies -- A collection of phandles to a regulator nodes, see
> + Documentation/devicetree/bindings/regulator/ for specific
> + bindings. The number and order of phandles must match
> + exactly the number of strings in the "supply-names" property.
> +
> +Example Node:
> +
> +pcie0: pcie at f0460000 {
^^ You've got a tab after the colon. Makes this look funky in my
vim/mutt :)
Brian
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
> + compatible = "brcm,pci-plat-dev";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 47 3
> + 0 0 0 2 &intc 0 48 3
> + 0 0 0 3 &intc 0 49 3
> + 0 0 0 4 &intc 0 50 3>;
> + interrupt-names = "pcie_0_inta",
> + "pcie_0_intb",
> + "pcie_0_intc",
> + "pcie_0_intd";
> + clocks = <&sw_pcie0>;
> + clock-names = "sw_pcie";
> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
> + msi-controller; /* use PCIe's internal MSI controller */
> + brcm,ssc;
> + brcm,gen = <1>;
> + supply-names = "vreg-wifi-pwr";
> + supplies = <&vreg-wifi-pwr>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-12 14:41 ` Julien Thierry
0 siblings, 0 replies; 146+ messages in thread
From: Julien Thierry @ 2017-10-12 14:41 UTC (permalink / raw)
To: Jim Quinlan, linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris
Hi Jim,
On 11/10/17 23:34, Jim Quinlan wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
>
> This commit adds a memory API suitable for ascertaining the sizes of
> each of the N memory controllers in a Broadcom STB chip. Its first
> user will be the Broadcom STB PCIe root complex driver, which needs
> to know these sizes to properly set up DMA mappings for inbound
> regions.
>
> We cannot use memblock here or anything like what Linux provides
> because it collapses adjacent regions within a larger block, and here
> we actually need per-memory controller addresses and sizes, which is
> why we resort to manual DT parsing.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/soc/bcm/brcmstb/Makefile | 2 +-
> drivers/soc/bcm/brcmstb/memory.c | 183 +++++++++++++++++++++++++++++++++++++++
> include/soc/brcmstb/memory_api.h | 25 ++++++
> 3 files changed, 209 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
> create mode 100644 include/soc/brcmstb/memory_api.h
>
> diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
> index 9120b27..4cea7b6 100644
> --- a/drivers/soc/bcm/brcmstb/Makefile
> +++ b/drivers/soc/bcm/brcmstb/Makefile
> @@ -1 +1 @@
> -obj-y += common.o biuctrl.o
> +obj-y += common.o biuctrl.o memory.o
> diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
> new file mode 100644
> index 0000000..cb6bf73
> --- /dev/null
> +++ b/drivers/soc/bcm/brcmstb/memory.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright © 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * A copy of the GPL is available at
> + * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
> + * Foundation at https://www.gnu.org/licenses/ .
> + */
> +
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/libfdt.h>
> +#include <linux/of_address.h>
> +#include <linux/of_fdt.h>
> +#include <linux/sizes.h>
> +#include <soc/brcmstb/memory_api.h>
> +
> +/* -------------------- Constants -------------------- */
> +
> +/* Macros to help extract property data */
> +#define U8TOU32(b, offs) \
> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
> + (((u32)b[3 + offs] << 24) & 0xff000000))
> +
> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
> +
I fail to understand why this is not:
#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(*(u32*)(b + offs)))
If I understand correctly, fdt data is in big endian, the macro U8TOU32
reads it as little endian. My guess is that this won't work on big
endian kernels but should work on little endian since fdt32_to_cpu will
revert the bytes again.
Am I missing something?
Cheers,
> +/* Constants used when retrieving memc info */
> +#define NUM_BUS_RANGES 10
> +#define BUS_RANGE_ULIMIT_SHIFT 4
> +#define BUS_RANGE_LLIMIT_SHIFT 4
> +#define BUS_RANGE_PA_SHIFT 12
> +
> +enum {
> + BUSNUM_MCP0 = 0x4,
> + BUSNUM_MCP1 = 0x5,
> + BUSNUM_MCP2 = 0x6,
> +};
> +
> +/* -------------------- Functions -------------------- */
> +
> +/*
> + * If the DT nodes are handy, determine which MEMC holds the specified
> + * physical address.
> + */
> +#ifdef CONFIG_ARCH_BRCMSTB
> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
> +{
> + int memc = -1;
> + int i;
> +
> + for (i = 0; i < NUM_BUS_RANGES; i++, base += 8) {
> + const u64 ulimit_raw = readl(base);
> + const u64 llimit_raw = readl(base + 4);
> + const u64 ulimit =
> + ((ulimit_raw >> BUS_RANGE_ULIMIT_SHIFT)
> + << BUS_RANGE_PA_SHIFT) | 0xfff;
> + const u64 llimit = (llimit_raw >> BUS_RANGE_LLIMIT_SHIFT)
> + << BUS_RANGE_PA_SHIFT;
> + const u32 busnum = (u32)(ulimit_raw & 0xf);
> +
> + if (pa >= llimit && pa <= ulimit) {
> + if (busnum >= BUSNUM_MCP0 && busnum <= BUSNUM_MCP2) {
> + memc = busnum - BUSNUM_MCP0;
> + break;
> + }
> + }
> + }
> +
> + return memc;
> +}
> +
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + int memc = -1;
> + struct device_node *np;
> + void __iomem *cpubiuctrl;
> +
> + np = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
> + if (!np)
> + return memc;
> +
> + cpubiuctrl = of_iomap(np, 0);
> + if (!cpubiuctrl)
> + goto cleanup;
> +
> + memc = __brcmstb_memory_phys_addr_to_memc(pa, cpubiuctrl);
> + iounmap(cpubiuctrl);
> +
> +cleanup:
> + of_node_put(np);
> +
> + return memc;
> +}
> +
> +#elif defined(CONFIG_MIPS)
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + /* The logic here is fairly simple and hardcoded: if pa <= 0x5000_0000,
> + * then this is MEMC0, else MEMC1.
> + *
> + * For systems with 2GB on MEMC0, MEMC1 starts at 9000_0000, with 1GB
> + * on MEMC0, MEMC1 starts at 6000_0000.
> + */
> + if (pa >= 0x50000000ULL)
> + return 1;
> + else
> + return 0;
> +}
> +#endif
> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> +
> +u64 brcmstb_memory_memc_size(int memc)
> +{
> + const void *fdt = initial_boot_params;
> + const int mem_offset = fdt_path_offset(fdt, "/memory");
> + int addr_cells = 1, size_cells = 1;
> + const struct fdt_property *prop;
> + int proplen, cellslen;
> + u64 memc_size = 0;
> + int i;
> +
> + /* Get root size and address cells if specified */
> + prop = fdt_get_property(fdt, 0, "#size-cells", &proplen);
> + if (prop)
> + size_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
> +
> + prop = fdt_get_property(fdt, 0, "#address-cells", &proplen);
> + if (prop)
> + addr_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
> +
> + if (mem_offset < 0)
> + return -1;
> +
> + prop = fdt_get_property(fdt, mem_offset, "reg", &proplen);
> + cellslen = (int)sizeof(u32) * (addr_cells + size_cells);
> + if ((proplen % cellslen) != 0)
> + return -1;
> +
> + for (i = 0; i < proplen / cellslen; ++i) {
> + u64 addr = 0;
> + u64 size = 0;
> + int memc_idx;
> + int j;
> +
> + for (j = 0; j < addr_cells; ++j) {
> + int offset = (cellslen * i) + (sizeof(u32) * j);
> +
> + addr |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
> + ((addr_cells - j - 1) * 32);
> + }
> + for (j = 0; j < size_cells; ++j) {
> + int offset = (cellslen * i) +
> + (sizeof(u32) * (j + addr_cells));
> +
> + size |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
> + ((size_cells - j - 1) * 32);
> + }
> +
> + if ((phys_addr_t)addr != addr) {
> + pr_err("phys_addr_t is smaller than provided address 0x%llx!\n",
> + addr);
> + return -1;
> + }
> +
> + memc_idx = brcmstb_memory_phys_addr_to_memc((phys_addr_t)addr);
> + if (memc_idx == memc)
> + memc_size += size;
> + }
> +
> + return memc_size;
> +}
> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
> +
> diff --git a/include/soc/brcmstb/memory_api.h b/include/soc/brcmstb/memory_api.h
> new file mode 100644
> index 0000000..d922906
> --- /dev/null
> +++ b/include/soc/brcmstb/memory_api.h
> @@ -0,0 +1,25 @@
> +#ifndef __MEMORY_API_H
> +#define __MEMORY_API_H
> +
> +/*
> + * Bus Interface Unit control register setup, must happen early during boot,
> + * before SMP is brought up, called by machine entry point.
> + */
> +void brcmstb_biuctrl_init(void);
> +
> +#ifdef CONFIG_SOC_BRCMSTB
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa);
> +u64 brcmstb_memory_memc_size(int memc);
> +#else
> +static inline int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + return -EINVAL;
> +}
> +
> +static inline u64 brcmstb_memory_memc_size(int memc)
> +{
> + return -1;
> +}
> +#endif
> +
> +#endif /* __MEMORY_API_H */
>
--
Julien Thierry
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-12 14:41 ` Julien Thierry
0 siblings, 0 replies; 146+ messages in thread
From: Julien Thierry @ 2017-10-12 14:41 UTC (permalink / raw)
To: Jim Quinlan, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Florian Fainelli, Ralf Baechle,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Rob Herring,
Mark Rutland, Gregory Fong, Kevin Cernekee, Brian Norris
Hi Jim,
On 11/10/17 23:34, Jim Quinlan wrote:
> From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> This commit adds a memory API suitable for ascertaining the sizes of
> each of the N memory controllers in a Broadcom STB chip. Its first
> user will be the Broadcom STB PCIe root complex driver, which needs
> to know these sizes to properly set up DMA mappings for inbound
> regions.
>
> We cannot use memblock here or anything like what Linux provides
> because it collapses adjacent regions within a larger block, and here
> we actually need per-memory controller addresses and sizes, which is
> why we resort to manual DT parsing.
>
> Signed-off-by: Jim Quinlan <jim2101024-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/soc/bcm/brcmstb/Makefile | 2 +-
> drivers/soc/bcm/brcmstb/memory.c | 183 +++++++++++++++++++++++++++++++++++++++
> include/soc/brcmstb/memory_api.h | 25 ++++++
> 3 files changed, 209 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
> create mode 100644 include/soc/brcmstb/memory_api.h
>
> diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
> index 9120b27..4cea7b6 100644
> --- a/drivers/soc/bcm/brcmstb/Makefile
> +++ b/drivers/soc/bcm/brcmstb/Makefile
> @@ -1 +1 @@
> -obj-y += common.o biuctrl.o
> +obj-y += common.o biuctrl.o memory.o
> diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
> new file mode 100644
> index 0000000..cb6bf73
> --- /dev/null
> +++ b/drivers/soc/bcm/brcmstb/memory.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright © 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * A copy of the GPL is available at
> + * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
> + * Foundation at https://www.gnu.org/licenses/ .
> + */
> +
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/libfdt.h>
> +#include <linux/of_address.h>
> +#include <linux/of_fdt.h>
> +#include <linux/sizes.h>
> +#include <soc/brcmstb/memory_api.h>
> +
> +/* -------------------- Constants -------------------- */
> +
> +/* Macros to help extract property data */
> +#define U8TOU32(b, offs) \
> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
> + (((u32)b[3 + offs] << 24) & 0xff000000))
> +
> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
> +
I fail to understand why this is not:
#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(*(u32*)(b + offs)))
If I understand correctly, fdt data is in big endian, the macro U8TOU32
reads it as little endian. My guess is that this won't work on big
endian kernels but should work on little endian since fdt32_to_cpu will
revert the bytes again.
Am I missing something?
Cheers,
> +/* Constants used when retrieving memc info */
> +#define NUM_BUS_RANGES 10
> +#define BUS_RANGE_ULIMIT_SHIFT 4
> +#define BUS_RANGE_LLIMIT_SHIFT 4
> +#define BUS_RANGE_PA_SHIFT 12
> +
> +enum {
> + BUSNUM_MCP0 = 0x4,
> + BUSNUM_MCP1 = 0x5,
> + BUSNUM_MCP2 = 0x6,
> +};
> +
> +/* -------------------- Functions -------------------- */
> +
> +/*
> + * If the DT nodes are handy, determine which MEMC holds the specified
> + * physical address.
> + */
> +#ifdef CONFIG_ARCH_BRCMSTB
> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
> +{
> + int memc = -1;
> + int i;
> +
> + for (i = 0; i < NUM_BUS_RANGES; i++, base += 8) {
> + const u64 ulimit_raw = readl(base);
> + const u64 llimit_raw = readl(base + 4);
> + const u64 ulimit =
> + ((ulimit_raw >> BUS_RANGE_ULIMIT_SHIFT)
> + << BUS_RANGE_PA_SHIFT) | 0xfff;
> + const u64 llimit = (llimit_raw >> BUS_RANGE_LLIMIT_SHIFT)
> + << BUS_RANGE_PA_SHIFT;
> + const u32 busnum = (u32)(ulimit_raw & 0xf);
> +
> + if (pa >= llimit && pa <= ulimit) {
> + if (busnum >= BUSNUM_MCP0 && busnum <= BUSNUM_MCP2) {
> + memc = busnum - BUSNUM_MCP0;
> + break;
> + }
> + }
> + }
> +
> + return memc;
> +}
> +
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + int memc = -1;
> + struct device_node *np;
> + void __iomem *cpubiuctrl;
> +
> + np = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
> + if (!np)
> + return memc;
> +
> + cpubiuctrl = of_iomap(np, 0);
> + if (!cpubiuctrl)
> + goto cleanup;
> +
> + memc = __brcmstb_memory_phys_addr_to_memc(pa, cpubiuctrl);
> + iounmap(cpubiuctrl);
> +
> +cleanup:
> + of_node_put(np);
> +
> + return memc;
> +}
> +
> +#elif defined(CONFIG_MIPS)
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + /* The logic here is fairly simple and hardcoded: if pa <= 0x5000_0000,
> + * then this is MEMC0, else MEMC1.
> + *
> + * For systems with 2GB on MEMC0, MEMC1 starts at 9000_0000, with 1GB
> + * on MEMC0, MEMC1 starts at 6000_0000.
> + */
> + if (pa >= 0x50000000ULL)
> + return 1;
> + else
> + return 0;
> +}
> +#endif
> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> +
> +u64 brcmstb_memory_memc_size(int memc)
> +{
> + const void *fdt = initial_boot_params;
> + const int mem_offset = fdt_path_offset(fdt, "/memory");
> + int addr_cells = 1, size_cells = 1;
> + const struct fdt_property *prop;
> + int proplen, cellslen;
> + u64 memc_size = 0;
> + int i;
> +
> + /* Get root size and address cells if specified */
> + prop = fdt_get_property(fdt, 0, "#size-cells", &proplen);
> + if (prop)
> + size_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
> +
> + prop = fdt_get_property(fdt, 0, "#address-cells", &proplen);
> + if (prop)
> + addr_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
> +
> + if (mem_offset < 0)
> + return -1;
> +
> + prop = fdt_get_property(fdt, mem_offset, "reg", &proplen);
> + cellslen = (int)sizeof(u32) * (addr_cells + size_cells);
> + if ((proplen % cellslen) != 0)
> + return -1;
> +
> + for (i = 0; i < proplen / cellslen; ++i) {
> + u64 addr = 0;
> + u64 size = 0;
> + int memc_idx;
> + int j;
> +
> + for (j = 0; j < addr_cells; ++j) {
> + int offset = (cellslen * i) + (sizeof(u32) * j);
> +
> + addr |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
> + ((addr_cells - j - 1) * 32);
> + }
> + for (j = 0; j < size_cells; ++j) {
> + int offset = (cellslen * i) +
> + (sizeof(u32) * (j + addr_cells));
> +
> + size |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
> + ((size_cells - j - 1) * 32);
> + }
> +
> + if ((phys_addr_t)addr != addr) {
> + pr_err("phys_addr_t is smaller than provided address 0x%llx!\n",
> + addr);
> + return -1;
> + }
> +
> + memc_idx = brcmstb_memory_phys_addr_to_memc((phys_addr_t)addr);
> + if (memc_idx == memc)
> + memc_size += size;
> + }
> +
> + return memc_size;
> +}
> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
> +
> diff --git a/include/soc/brcmstb/memory_api.h b/include/soc/brcmstb/memory_api.h
> new file mode 100644
> index 0000000..d922906
> --- /dev/null
> +++ b/include/soc/brcmstb/memory_api.h
> @@ -0,0 +1,25 @@
> +#ifndef __MEMORY_API_H
> +#define __MEMORY_API_H
> +
> +/*
> + * Bus Interface Unit control register setup, must happen early during boot,
> + * before SMP is brought up, called by machine entry point.
> + */
> +void brcmstb_biuctrl_init(void);
> +
> +#ifdef CONFIG_SOC_BRCMSTB
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa);
> +u64 brcmstb_memory_memc_size(int memc);
> +#else
> +static inline int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + return -EINVAL;
> +}
> +
> +static inline u64 brcmstb_memory_memc_size(int memc)
> +{
> + return -1;
> +}
> +#endif
> +
> +#endif /* __MEMORY_API_H */
>
--
Julien Thierry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-12 14:41 ` Julien Thierry
0 siblings, 0 replies; 146+ messages in thread
From: Julien Thierry @ 2017-10-12 14:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jim,
On 11/10/17 23:34, Jim Quinlan wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
>
> This commit adds a memory API suitable for ascertaining the sizes of
> each of the N memory controllers in a Broadcom STB chip. Its first
> user will be the Broadcom STB PCIe root complex driver, which needs
> to know these sizes to properly set up DMA mappings for inbound
> regions.
>
> We cannot use memblock here or anything like what Linux provides
> because it collapses adjacent regions within a larger block, and here
> we actually need per-memory controller addresses and sizes, which is
> why we resort to manual DT parsing.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/soc/bcm/brcmstb/Makefile | 2 +-
> drivers/soc/bcm/brcmstb/memory.c | 183 +++++++++++++++++++++++++++++++++++++++
> include/soc/brcmstb/memory_api.h | 25 ++++++
> 3 files changed, 209 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
> create mode 100644 include/soc/brcmstb/memory_api.h
>
> diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
> index 9120b27..4cea7b6 100644
> --- a/drivers/soc/bcm/brcmstb/Makefile
> +++ b/drivers/soc/bcm/brcmstb/Makefile
> @@ -1 +1 @@
> -obj-y += common.o biuctrl.o
> +obj-y += common.o biuctrl.o memory.o
> diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
> new file mode 100644
> index 0000000..cb6bf73
> --- /dev/null
> +++ b/drivers/soc/bcm/brcmstb/memory.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright ? 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * A copy of the GPL is available at
> + * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
> + * Foundation at https://www.gnu.org/licenses/ .
> + */
> +
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/libfdt.h>
> +#include <linux/of_address.h>
> +#include <linux/of_fdt.h>
> +#include <linux/sizes.h>
> +#include <soc/brcmstb/memory_api.h>
> +
> +/* -------------------- Constants -------------------- */
> +
> +/* Macros to help extract property data */
> +#define U8TOU32(b, offs) \
> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
> + (((u32)b[3 + offs] << 24) & 0xff000000))
> +
> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
> +
I fail to understand why this is not:
#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(*(u32*)(b + offs)))
If I understand correctly, fdt data is in big endian, the macro U8TOU32
reads it as little endian. My guess is that this won't work on big
endian kernels but should work on little endian since fdt32_to_cpu will
revert the bytes again.
Am I missing something?
Cheers,
> +/* Constants used when retrieving memc info */
> +#define NUM_BUS_RANGES 10
> +#define BUS_RANGE_ULIMIT_SHIFT 4
> +#define BUS_RANGE_LLIMIT_SHIFT 4
> +#define BUS_RANGE_PA_SHIFT 12
> +
> +enum {
> + BUSNUM_MCP0 = 0x4,
> + BUSNUM_MCP1 = 0x5,
> + BUSNUM_MCP2 = 0x6,
> +};
> +
> +/* -------------------- Functions -------------------- */
> +
> +/*
> + * If the DT nodes are handy, determine which MEMC holds the specified
> + * physical address.
> + */
> +#ifdef CONFIG_ARCH_BRCMSTB
> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
> +{
> + int memc = -1;
> + int i;
> +
> + for (i = 0; i < NUM_BUS_RANGES; i++, base += 8) {
> + const u64 ulimit_raw = readl(base);
> + const u64 llimit_raw = readl(base + 4);
> + const u64 ulimit =
> + ((ulimit_raw >> BUS_RANGE_ULIMIT_SHIFT)
> + << BUS_RANGE_PA_SHIFT) | 0xfff;
> + const u64 llimit = (llimit_raw >> BUS_RANGE_LLIMIT_SHIFT)
> + << BUS_RANGE_PA_SHIFT;
> + const u32 busnum = (u32)(ulimit_raw & 0xf);
> +
> + if (pa >= llimit && pa <= ulimit) {
> + if (busnum >= BUSNUM_MCP0 && busnum <= BUSNUM_MCP2) {
> + memc = busnum - BUSNUM_MCP0;
> + break;
> + }
> + }
> + }
> +
> + return memc;
> +}
> +
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + int memc = -1;
> + struct device_node *np;
> + void __iomem *cpubiuctrl;
> +
> + np = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
> + if (!np)
> + return memc;
> +
> + cpubiuctrl = of_iomap(np, 0);
> + if (!cpubiuctrl)
> + goto cleanup;
> +
> + memc = __brcmstb_memory_phys_addr_to_memc(pa, cpubiuctrl);
> + iounmap(cpubiuctrl);
> +
> +cleanup:
> + of_node_put(np);
> +
> + return memc;
> +}
> +
> +#elif defined(CONFIG_MIPS)
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + /* The logic here is fairly simple and hardcoded: if pa <= 0x5000_0000,
> + * then this is MEMC0, else MEMC1.
> + *
> + * For systems with 2GB on MEMC0, MEMC1 starts at 9000_0000, with 1GB
> + * on MEMC0, MEMC1 starts at 6000_0000.
> + */
> + if (pa >= 0x50000000ULL)
> + return 1;
> + else
> + return 0;
> +}
> +#endif
> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> +
> +u64 brcmstb_memory_memc_size(int memc)
> +{
> + const void *fdt = initial_boot_params;
> + const int mem_offset = fdt_path_offset(fdt, "/memory");
> + int addr_cells = 1, size_cells = 1;
> + const struct fdt_property *prop;
> + int proplen, cellslen;
> + u64 memc_size = 0;
> + int i;
> +
> + /* Get root size and address cells if specified */
> + prop = fdt_get_property(fdt, 0, "#size-cells", &proplen);
> + if (prop)
> + size_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
> +
> + prop = fdt_get_property(fdt, 0, "#address-cells", &proplen);
> + if (prop)
> + addr_cells = DT_PROP_DATA_TO_U32(prop->data, 0);
> +
> + if (mem_offset < 0)
> + return -1;
> +
> + prop = fdt_get_property(fdt, mem_offset, "reg", &proplen);
> + cellslen = (int)sizeof(u32) * (addr_cells + size_cells);
> + if ((proplen % cellslen) != 0)
> + return -1;
> +
> + for (i = 0; i < proplen / cellslen; ++i) {
> + u64 addr = 0;
> + u64 size = 0;
> + int memc_idx;
> + int j;
> +
> + for (j = 0; j < addr_cells; ++j) {
> + int offset = (cellslen * i) + (sizeof(u32) * j);
> +
> + addr |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
> + ((addr_cells - j - 1) * 32);
> + }
> + for (j = 0; j < size_cells; ++j) {
> + int offset = (cellslen * i) +
> + (sizeof(u32) * (j + addr_cells));
> +
> + size |= (u64)DT_PROP_DATA_TO_U32(prop->data, offset) <<
> + ((size_cells - j - 1) * 32);
> + }
> +
> + if ((phys_addr_t)addr != addr) {
> + pr_err("phys_addr_t is smaller than provided address 0x%llx!\n",
> + addr);
> + return -1;
> + }
> +
> + memc_idx = brcmstb_memory_phys_addr_to_memc((phys_addr_t)addr);
> + if (memc_idx == memc)
> + memc_size += size;
> + }
> +
> + return memc_size;
> +}
> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
> +
> diff --git a/include/soc/brcmstb/memory_api.h b/include/soc/brcmstb/memory_api.h
> new file mode 100644
> index 0000000..d922906
> --- /dev/null
> +++ b/include/soc/brcmstb/memory_api.h
> @@ -0,0 +1,25 @@
> +#ifndef __MEMORY_API_H
> +#define __MEMORY_API_H
> +
> +/*
> + * Bus Interface Unit control register setup, must happen early during boot,
> + * before SMP is brought up, called by machine entry point.
> + */
> +void brcmstb_biuctrl_init(void);
> +
> +#ifdef CONFIG_SOC_BRCMSTB
> +int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa);
> +u64 brcmstb_memory_memc_size(int memc);
> +#else
> +static inline int brcmstb_memory_phys_addr_to_memc(phys_addr_t pa)
> +{
> + return -EINVAL;
> +}
> +
> +static inline u64 brcmstb_memory_memc_size(int memc)
> +{
> + return -1;
> +}
> +#endif
> +
> +#endif /* __MEMORY_API_H */
>
--
Julien Thierry
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
2017-10-12 14:41 ` Julien Thierry
(?)
@ 2017-10-12 16:53 ` Florian Fainelli
-1 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-12 16:53 UTC (permalink / raw)
To: Julien Thierry, Jim Quinlan, linux-kernel
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Ralf Baechle, Catalin Marinas,
Will Deacon, Bjorn Helgaas, Rob Herring, Mark Rutland,
Gregory Fong, Kevin Cernekee, Brian Norris
On 10/12/2017 07:41 AM, Julien Thierry wrote:
> Hi Jim,
>
> On 11/10/17 23:34, Jim Quinlan wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>>
>> This commit adds a memory API suitable for ascertaining the sizes of
>> each of the N memory controllers in a Broadcom STB chip. Its first
>> user will be the Broadcom STB PCIe root complex driver, which needs
>> to know these sizes to properly set up DMA mappings for inbound
>> regions.
>>
>> We cannot use memblock here or anything like what Linux provides
>> because it collapses adjacent regions within a larger block, and here
>> we actually need per-memory controller addresses and sizes, which is
>> why we resort to manual DT parsing.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> drivers/soc/bcm/brcmstb/Makefile | 2 +-
>> drivers/soc/bcm/brcmstb/memory.c | 183
>> +++++++++++++++++++++++++++++++++++++++
>> include/soc/brcmstb/memory_api.h | 25 ++++++
>> 3 files changed, 209 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
>> create mode 100644 include/soc/brcmstb/memory_api.h
>>
>> diff --git a/drivers/soc/bcm/brcmstb/Makefile
>> b/drivers/soc/bcm/brcmstb/Makefile
>> index 9120b27..4cea7b6 100644
>> --- a/drivers/soc/bcm/brcmstb/Makefile
>> +++ b/drivers/soc/bcm/brcmstb/Makefile
>> @@ -1 +1 @@
>> -obj-y += common.o biuctrl.o
>> +obj-y += common.o biuctrl.o memory.o
>> diff --git a/drivers/soc/bcm/brcmstb/memory.c
>> b/drivers/soc/bcm/brcmstb/memory.c
>> new file mode 100644
>> index 0000000..cb6bf73
>> --- /dev/null
>> +++ b/drivers/soc/bcm/brcmstb/memory.c
>> @@ -0,0 +1,183 @@
>> +/*
>> + * Copyright © 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * A copy of the GPL is available at
>> + * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
>> + * Foundation at https://www.gnu.org/licenses/ .
>> + */
>> +
>> +#include <linux/device.h>
>> +#include <linux/io.h>
>> +#include <linux/libfdt.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_fdt.h>
>> +#include <linux/sizes.h>
>> +#include <soc/brcmstb/memory_api.h>
>> +
>> +/* -------------------- Constants -------------------- */
>> +
>> +/* Macros to help extract property data */
>> +#define U8TOU32(b, offs) \
>> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
>> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
>> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
>> + (((u32)b[3 + offs] << 24) & 0xff000000))
>> +
>> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
>> +
>
> I fail to understand why this is not:
>
> #define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(*(u32*)(b + offs)))
>
>
> If I understand correctly, fdt data is in big endian, the macro U8TOU32
> reads it as little endian. My guess is that this won't work on big
> endian kernels but should work on little endian since fdt32_to_cpu will
> revert the bytes again.
>
> Am I missing something?
No, your point is valid, there is no reason why this cannot be
fdt32_to_cpu() here.
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-12 16:53 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-12 16:53 UTC (permalink / raw)
To: Julien Thierry, Jim Quinlan, linux-kernel
Cc: Mark Rutland, linux-mips, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel
T24gMTAvMTIvMjAxNyAwNzo0MSBBTSwgSnVsaWVuIFRoaWVycnkgd3JvdGU6Cj4gSGkgSmltLAo+
IAo+IE9uIDExLzEwLzE3IDIzOjM0LCBKaW0gUXVpbmxhbiB3cm90ZToKPj4gRnJvbTogRmxvcmlh
biBGYWluZWxsaSA8Zi5mYWluZWxsaUBnbWFpbC5jb20+Cj4+Cj4+IFRoaXMgY29tbWl0IGFkZHMg
YSBtZW1vcnkgQVBJIHN1aXRhYmxlIGZvciBhc2NlcnRhaW5pbmcgdGhlIHNpemVzIG9mCj4+IGVh
Y2ggb2YgdGhlIE4gbWVtb3J5IGNvbnRyb2xsZXJzIGluIGEgQnJvYWRjb20gU1RCIGNoaXAuICBJ
dHMgZmlyc3QKPj4gdXNlciB3aWxsIGJlIHRoZSBCcm9hZGNvbSBTVEIgUENJZSByb290IGNvbXBs
ZXggZHJpdmVyLCB3aGljaCBuZWVkcwo+PiB0byBrbm93IHRoZXNlIHNpemVzIHRvIHByb3Blcmx5
IHNldCB1cCBETUEgbWFwcGluZ3MgZm9yIGluYm91bmQKPj4gcmVnaW9ucy4KPj4KPj4gV2UgY2Fu
bm90IHVzZSBtZW1ibG9jayBoZXJlIG9yIGFueXRoaW5nIGxpa2Ugd2hhdCBMaW51eCBwcm92aWRl
cwo+PiBiZWNhdXNlIGl0IGNvbGxhcHNlcyBhZGphY2VudCByZWdpb25zIHdpdGhpbiBhIGxhcmdl
ciBibG9jaywgYW5kIGhlcmUKPj4gd2UgYWN0dWFsbHkgbmVlZCBwZXItbWVtb3J5IGNvbnRyb2xs
ZXIgYWRkcmVzc2VzIGFuZCBzaXplcywgd2hpY2ggaXMKPj4gd2h5IHdlIHJlc29ydCB0byBtYW51
YWwgRFQgcGFyc2luZy4KPj4KPj4gU2lnbmVkLW9mZi1ieTogSmltIFF1aW5sYW4gPGppbTIxMDEw
MjRAZ21haWwuY29tPgo+PiAtLS0KPj4gICBkcml2ZXJzL3NvYy9iY20vYnJjbXN0Yi9NYWtlZmls
ZSB8ICAgMiArLQo+PiAgIGRyaXZlcnMvc29jL2JjbS9icmNtc3RiL21lbW9yeS5jIHwgMTgzCj4+
ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwo+PiAgIGluY2x1ZGUvc29j
L2JyY21zdGIvbWVtb3J5X2FwaS5oIHwgIDI1ICsrKysrKwo+PiAgIDMgZmlsZXMgY2hhbmdlZCwg
MjA5IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQg
ZHJpdmVycy9zb2MvYmNtL2JyY21zdGIvbWVtb3J5LmMKPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQg
aW5jbHVkZS9zb2MvYnJjbXN0Yi9tZW1vcnlfYXBpLmgKPj4KPj4gZGlmZiAtLWdpdCBhL2RyaXZl
cnMvc29jL2JjbS9icmNtc3RiL01ha2VmaWxlCj4+IGIvZHJpdmVycy9zb2MvYmNtL2JyY21zdGIv
TWFrZWZpbGUKPj4gaW5kZXggOTEyMGIyNy4uNGNlYTdiNiAxMDA2NDQKPj4gLS0tIGEvZHJpdmVy
cy9zb2MvYmNtL2JyY21zdGIvTWFrZWZpbGUKPj4gKysrIGIvZHJpdmVycy9zb2MvYmNtL2JyY21z
dGIvTWFrZWZpbGUKPj4gQEAgLTEgKzEgQEAKPj4gLW9iai15ICAgICAgICAgICAgICAgICs9IGNv
bW1vbi5vIGJpdWN0cmwubwo+PiArb2JqLXkgICAgICAgICAgICAgICAgKz0gY29tbW9uLm8gYml1
Y3RybC5vIG1lbW9yeS5vCj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3NvYy9iY20vYnJjbXN0Yi9t
ZW1vcnkuYwo+PiBiL2RyaXZlcnMvc29jL2JjbS9icmNtc3RiL21lbW9yeS5jCj4+IG5ldyBmaWxl
IG1vZGUgMTAwNjQ0Cj4+IGluZGV4IDAwMDAwMDAuLmNiNmJmNzMKPj4gLS0tIC9kZXYvbnVsbAo+
PiArKysgYi9kcml2ZXJzL3NvYy9iY20vYnJjbXN0Yi9tZW1vcnkuYwo+PiBAQCAtMCwwICsxLDE4
MyBAQAo+PiArLyoKPj4gKyAqIENvcHlyaWdodCDCqSAyMDE1LTIwMTcgQnJvYWRjb20KPj4gKyAq
Cj4+ICsgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1
dGUgaXQgYW5kL29yIG1vZGlmeQo+PiArICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUg
R2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIgYXMKPj4gKyAqIHB1Ymxpc2hlZCBieSB0
aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLgo+PiArICoKPj4gKyAqIFRoaXMgcHJvZ3JhbSBp
cyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAo+PiArICog
YnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFu
dHkgb2YKPj4gKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg
UFVSUE9TRS4gU2VlIHRoZQo+PiArICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1v
cmUgZGV0YWlscy4KPj4gKyAqCj4+ICsgKiBBIGNvcHkgb2YgdGhlIEdQTCBpcyBhdmFpbGFibGUg
YXQKPj4gKyAqIGh0dHA6Ly93d3cuYnJvYWRjb20uY29tL2xpY2Vuc2VzL0dQTHYyLnBocCBvciBm
cm9tIHRoZSBGcmVlIFNvZnR3YXJlCj4+ICsgKiBGb3VuZGF0aW9uIGF0IGh0dHBzOi8vd3d3Lmdu
dS5vcmcvbGljZW5zZXMvIC4KPj4gKyAqLwo+PiArCj4+ICsjaW5jbHVkZSA8bGludXgvZGV2aWNl
Lmg+Cj4+ICsjaW5jbHVkZSA8bGludXgvaW8uaD4KPj4gKyNpbmNsdWRlIDxsaW51eC9saWJmZHQu
aD4KPj4gKyNpbmNsdWRlIDxsaW51eC9vZl9hZGRyZXNzLmg+Cj4+ICsjaW5jbHVkZSA8bGludXgv
b2ZfZmR0Lmg+Cj4+ICsjaW5jbHVkZSA8bGludXgvc2l6ZXMuaD4KPj4gKyNpbmNsdWRlIDxzb2Mv
YnJjbXN0Yi9tZW1vcnlfYXBpLmg+Cj4+ICsKPj4gKy8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tIENv
bnN0YW50cyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAqLwo+PiArCj4+ICsvKiBNYWNyb3MgdG8gaGVs
cCBleHRyYWN0IHByb3BlcnR5IGRhdGEgKi8KPj4gKyNkZWZpbmUgVThUT1UzMihiLCBvZmZzKSBc
Cj4+ICsgICAgKCgoKHUzMiliWzAgKyBvZmZzXSA8PCAwKSAgJiAweDAwMDAwMGZmKSB8IFwKPj4g
KyAgICAgKCgodTMyKWJbMSArIG9mZnNdIDw8IDgpICAmIDB4MDAwMGZmMDApIHwgXAo+PiArICAg
ICAoKCh1MzIpYlsyICsgb2Zmc10gPDwgMTYpICYgMHgwMGZmMDAwMCkgfCBcCj4+ICsgICAgICgo
KHUzMiliWzMgKyBvZmZzXSA8PCAyNCkgJiAweGZmMDAwMDAwKSkKPj4gKwo+PiArI2RlZmluZSBE
VF9QUk9QX0RBVEFfVE9fVTMyKGIsIG9mZnMpIChmZHQzMl90b19jcHUoVThUT1UzMihiLCBvZmZz
KSkpCj4+ICsKPiAKPiBJIGZhaWwgdG8gdW5kZXJzdGFuZCB3aHkgdGhpcyBpcyBub3Q6Cj4gCj4g
I2RlZmluZSBEVF9QUk9QX0RBVEFfVE9fVTMyKGIsIG9mZnMpIChmZHQzMl90b19jcHUoKih1MzIq
KShiICsgb2ZmcykpKQo+IAo+IAo+IElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIGZkdCBkYXRh
IGlzIGluIGJpZyBlbmRpYW4sIHRoZSBtYWNybyBVOFRPVTMyCj4gcmVhZHMgaXQgYXMgbGl0dGxl
IGVuZGlhbi4gTXkgZ3Vlc3MgaXMgdGhhdCB0aGlzIHdvbid0IHdvcmsgb24gYmlnCj4gZW5kaWFu
IGtlcm5lbHMgYnV0IHNob3VsZCB3b3JrIG9uIGxpdHRsZSBlbmRpYW4gc2luY2UgZmR0MzJfdG9f
Y3B1IHdpbGwKPiByZXZlcnQgdGhlIGJ5dGVzIGFnYWluLgo+IAo+IEFtIEkgbWlzc2luZyBzb21l
dGhpbmc/CgpObywgeW91ciBwb2ludCBpcyB2YWxpZCwgdGhlcmUgaXMgbm8gcmVhc29uIHdoeSB0
aGlzIGNhbm5vdCBiZQpmZHQzMl90b19jcHUoKSBoZXJlLgotLSAKRmxvcmlhbgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBt
YWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9s
aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-12 16:53 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-12 16:53 UTC (permalink / raw)
To: linux-arm-kernel
On 10/12/2017 07:41 AM, Julien Thierry wrote:
> Hi Jim,
>
> On 11/10/17 23:34, Jim Quinlan wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>>
>> This commit adds a memory API suitable for ascertaining the sizes of
>> each of the N memory controllers in a Broadcom STB chip. Its first
>> user will be the Broadcom STB PCIe root complex driver, which needs
>> to know these sizes to properly set up DMA mappings for inbound
>> regions.
>>
>> We cannot use memblock here or anything like what Linux provides
>> because it collapses adjacent regions within a larger block, and here
>> we actually need per-memory controller addresses and sizes, which is
>> why we resort to manual DT parsing.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> drivers/soc/bcm/brcmstb/Makefile | 2 +-
>> drivers/soc/bcm/brcmstb/memory.c | 183
>> +++++++++++++++++++++++++++++++++++++++
>> include/soc/brcmstb/memory_api.h | 25 ++++++
>> 3 files changed, 209 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
>> create mode 100644 include/soc/brcmstb/memory_api.h
>>
>> diff --git a/drivers/soc/bcm/brcmstb/Makefile
>> b/drivers/soc/bcm/brcmstb/Makefile
>> index 9120b27..4cea7b6 100644
>> --- a/drivers/soc/bcm/brcmstb/Makefile
>> +++ b/drivers/soc/bcm/brcmstb/Makefile
>> @@ -1 +1 @@
>> -obj-y += common.o biuctrl.o
>> +obj-y += common.o biuctrl.o memory.o
>> diff --git a/drivers/soc/bcm/brcmstb/memory.c
>> b/drivers/soc/bcm/brcmstb/memory.c
>> new file mode 100644
>> index 0000000..cb6bf73
>> --- /dev/null
>> +++ b/drivers/soc/bcm/brcmstb/memory.c
>> @@ -0,0 +1,183 @@
>> +/*
>> + * Copyright ? 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * A copy of the GPL is available at
>> + * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
>> + * Foundation at https://www.gnu.org/licenses/ .
>> + */
>> +
>> +#include <linux/device.h>
>> +#include <linux/io.h>
>> +#include <linux/libfdt.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_fdt.h>
>> +#include <linux/sizes.h>
>> +#include <soc/brcmstb/memory_api.h>
>> +
>> +/* -------------------- Constants -------------------- */
>> +
>> +/* Macros to help extract property data */
>> +#define U8TOU32(b, offs) \
>> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
>> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
>> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
>> + (((u32)b[3 + offs] << 24) & 0xff000000))
>> +
>> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
>> +
>
> I fail to understand why this is not:
>
> #define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(*(u32*)(b + offs)))
>
>
> If I understand correctly, fdt data is in big endian, the macro U8TOU32
> reads it as little endian. My guess is that this won't work on big
> endian kernels but should work on little endian since fdt32_to_cpu will
> revert the bytes again.
>
> Am I missing something?
No, your point is valid, there is no reason why this cannot be
fdt32_to_cpu() here.
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
2017-10-11 22:34 ` Jim Quinlan
(?)
@ 2017-10-12 17:06 ` Robin Murphy
-1 siblings, 0 replies; 146+ messages in thread
From: Robin Murphy @ 2017-10-12 17:06 UTC (permalink / raw)
To: Jim Quinlan, linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On 11/10/17 23:34, Jim Quinlan wrote:
> The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
> However, that variable is defined as static. Instead, we use
> arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
> we also want our driver to be a separate module, we need to
> export this function.
NAK. Retrieve the platform-assigned ops from the device via
get_dma_ops() and stash them in your drvdata or wherever before you
replace them. Don't go poking around arch code internals directly from a
driver.
Robin.
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> arch/arm64/mm/dma-mapping.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 614af88..dae572f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> }
> #endif
> }
> +EXPORT_SYMBOL(arch_setup_dma_ops);
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-12 17:06 ` Robin Murphy
0 siblings, 0 replies; 146+ messages in thread
From: Robin Murphy @ 2017-10-12 17:06 UTC (permalink / raw)
To: Jim Quinlan, linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On 11/10/17 23:34, Jim Quinlan wrote:
> The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
> However, that variable is defined as static. Instead, we use
> arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
> we also want our driver to be a separate module, we need to
> export this function.
NAK. Retrieve the platform-assigned ops from the device via
get_dma_ops() and stash them in your drvdata or wherever before you
replace them. Don't go poking around arch code internals directly from a
driver.
Robin.
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> arch/arm64/mm/dma-mapping.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 614af88..dae572f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> }
> #endif
> }
> +EXPORT_SYMBOL(arch_setup_dma_ops);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-12 17:06 ` Robin Murphy
0 siblings, 0 replies; 146+ messages in thread
From: Robin Murphy @ 2017-10-12 17:06 UTC (permalink / raw)
To: linux-arm-kernel
On 11/10/17 23:34, Jim Quinlan wrote:
> The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
> However, that variable is defined as static. Instead, we use
> arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
> we also want our driver to be a separate module, we need to
> export this function.
NAK. Retrieve the platform-assigned ops from the device via
get_dma_ops() and stash them in your drvdata or wherever before you
replace them. Don't go poking around arch code internals directly from a
driver.
Robin.
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> arch/arm64/mm/dma-mapping.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 614af88..dae572f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> }
> #endif
> }
> +EXPORT_SYMBOL(arch_setup_dma_ops);
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
2017-10-12 0:55 ` Brian Norris
(?)
@ 2017-10-12 17:52 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 17:52 UTC (permalink / raw)
To: Brian Norris
Cc: linux-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
linux-mips, devicetree, linux-pci, Florian Fainelli,
Ralf Baechle, Catalin Marinas, Will Deacon, Bjorn Helgaas,
Rob Herring, Mark Rutland, Gregory Fong, Kevin Cernekee
On Wed, Oct 11, 2017 at 8:55 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Hi Jim,
>
> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
pcie->gen = 0;
>> The DT bindings description of the Brcmstb PCIe device is described. This
>> node can be used by almost all Broadcom settop box chips, using
>> ARM, ARM64, or MIPS CPU architectures.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> new file mode 100644
>> index 0000000..2f699da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> @@ -0,0 +1,106 @@
>> +Brcmstb PCIe Host Controller Device Tree Bindings
>> +
>> +Introduction:
>> + The brcmstb host controller closely follows the example set in
>> +
>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>> +
>> + The rest of this document explains some added customizations and
>> + offers an example Brcmstb PCIe host controller DT node.
>> +
>> +Required Properties:
>> + reg -- the register start address and length for the PCIe block.
>> + Additional start,length pairs may be specified for clock addresses.
>> + interrupts -- two interrupts are specified; the first interrupt is for
>> + the PCI host controller and the second is for MSI if the built-in
>> + MSI controller is to be used.
>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>> + or "brcm,bcm7278-pcie".
>> + #address-cells -- the number of address cells for PCI-space.
>> + #size-cells -- the number of size cells for PCI-space.
>> + ranges -- See [1]; a specification of the outbound windows for the host
>> + controller. Each outbound window is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + Due to hardware limitations, there may be a maximum of four
>> + non-contiguous ranges specified.
>> + #interrupt-cells -- number of cells used to describe the interrupt.
>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>> + for our uses and the fourth cell is the mask (val = 0x7) for
>> + the legacy interrupt number [1..4].
>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>> + plus the size of the interrupt specifier.
>> + linux,pci-domain -- the domain of the host controller.
>> +
>> +Optional Properties:
>> + clocks -- list of clock phandles. If specified, this should list one
>> + clock.
>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>> + and the name of the clock is expected to be "sw_pcie".
>> + dma-ranges -- Similar in structure to ranges, each dma region is
>> + specified with a n-tuple. Dma-regions describe the inbound
>> + accesses from EP to RC; it translates the pci address that the
>> + EP "sees" to the CPU address in memory. This property is needed
>> + because the design of the Brcmstb memory subsystem often precludes
>> + idenity-mapping between CPU address space and PCIe address space.
>> + Each range is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>> + msi-parent. If this prop is set to the phandle of the PCIe
>> + node, or if the msi-parent prop is missing, the PCIE controller
>> + will attempt to use its built in MSI controller.
>> + msi-controller -- this property should only be specified if the
>> + PCIe controller is using its internal MSI controller.
>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>> + brcm,gen -- (integer) indicates desired generation of link:
>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>
> Does this differ from the 'max-link-speed' now documented in
> Documentation/devicetree/bindings/pci/pci.txt? If not, might as well use
> it, and of_pci_get_max_link_speed().
>
Hi Brian, yes that's what it is, will fix.
>> + supply-names -- the names of voltage regulators that the root
>> + complex should turn off/on/on on suspend/resume/boot. This
>> + is a string list.
>> + supplies -- A collection of phandles to a regulator nodes, see
>> + Documentation/devicetree/bindings/regulator/ for specific
>> + bindings. The number and order of phandles must match
>> + exactly the number of strings in the "supply-names" property.
>> +
>> +Example Node:
>> +
>> +pcie0: pcie@f0460000 {
>
> ^^ You've got a tab after the colon. Makes this look funky in my
> vim/mutt :)
>
> Brian
>
Will fix.
>> + reg = <0x0 0xf0460000 0x0 0x9310>;
>> + interrupts = <0x0 0x0 0x4>;
>> + compatible = "brcm,pci-plat-dev";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
>> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &intc 0 47 3
>> + 0 0 0 2 &intc 0 48 3
>> + 0 0 0 3 &intc 0 49 3
>> + 0 0 0 4 &intc 0 50 3>;
>> + interrupt-names = "pcie_0_inta",
>> + "pcie_0_intb",
>> + "pcie_0_intc",
>> + "pcie_0_intd";
>> + clocks = <&sw_pcie0>;
>> + clock-names = "sw_pcie";
>> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
>> + msi-controller; /* use PCIe's internal MSI controller */
>> + brcm,ssc;
>> + brcm,gen = <1>;
>> + supply-names = "vreg-wifi-pwr";
>> + supplies = <&vreg-wifi-pwr>;
>> + linux,pci-domain = <0>;
>> + };
>> --
>> 1.9.0.138.g2de3478
>>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-12 17:52 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 17:52 UTC (permalink / raw)
To: Brian Norris
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, linux-arm-kernel
On Wed, Oct 11, 2017 at 8:55 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Hi Jim,
>
> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
pcie->gen = 0;
>> The DT bindings description of the Brcmstb PCIe device is described. This
>> node can be used by almost all Broadcom settop box chips, using
>> ARM, ARM64, or MIPS CPU architectures.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> new file mode 100644
>> index 0000000..2f699da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> @@ -0,0 +1,106 @@
>> +Brcmstb PCIe Host Controller Device Tree Bindings
>> +
>> +Introduction:
>> + The brcmstb host controller closely follows the example set in
>> +
>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>> +
>> + The rest of this document explains some added customizations and
>> + offers an example Brcmstb PCIe host controller DT node.
>> +
>> +Required Properties:
>> + reg -- the register start address and length for the PCIe block.
>> + Additional start,length pairs may be specified for clock addresses.
>> + interrupts -- two interrupts are specified; the first interrupt is for
>> + the PCI host controller and the second is for MSI if the built-in
>> + MSI controller is to be used.
>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>> + or "brcm,bcm7278-pcie".
>> + #address-cells -- the number of address cells for PCI-space.
>> + #size-cells -- the number of size cells for PCI-space.
>> + ranges -- See [1]; a specification of the outbound windows for the host
>> + controller. Each outbound window is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + Due to hardware limitations, there may be a maximum of four
>> + non-contiguous ranges specified.
>> + #interrupt-cells -- number of cells used to describe the interrupt.
>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>> + for our uses and the fourth cell is the mask (val = 0x7) for
>> + the legacy interrupt number [1..4].
>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>> + plus the size of the interrupt specifier.
>> + linux,pci-domain -- the domain of the host controller.
>> +
>> +Optional Properties:
>> + clocks -- list of clock phandles. If specified, this should list one
>> + clock.
>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>> + and the name of the clock is expected to be "sw_pcie".
>> + dma-ranges -- Similar in structure to ranges, each dma region is
>> + specified with a n-tuple. Dma-regions describe the inbound
>> + accesses from EP to RC; it translates the pci address that the
>> + EP "sees" to the CPU address in memory. This property is needed
>> + because the design of the Brcmstb memory subsystem often precludes
>> + idenity-mapping between CPU address space and PCIe address space.
>> + Each range is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>> + msi-parent. If this prop is set to the phandle of the PCIe
>> + node, or if the msi-parent prop is missing, the PCIE controller
>> + will attempt to use its built in MSI controller.
>> + msi-controller -- this property should only be specified if the
>> + PCIe controller is using its internal MSI controller.
>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>> + brcm,gen -- (integer) indicates desired generation of link:
>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>
> Does this differ from the 'max-link-speed' now documented in
> Documentation/devicetree/bindings/pci/pci.txt? If not, might as well use
> it, and of_pci_get_max_link_speed().
>
Hi Brian, yes that's what it is, will fix.
>> + supply-names -- the names of voltage regulators that the root
>> + complex should turn off/on/on on suspend/resume/boot. This
>> + is a string list.
>> + supplies -- A collection of phandles to a regulator nodes, see
>> + Documentation/devicetree/bindings/regulator/ for specific
>> + bindings. The number and order of phandles must match
>> + exactly the number of strings in the "supply-names" property.
>> +
>> +Example Node:
>> +
>> +pcie0: pcie@f0460000 {
>
> ^^ You've got a tab after the colon. Makes this look funky in my
> vim/mutt :)
>
> Brian
>
Will fix.
>> + reg = <0x0 0xf0460000 0x0 0x9310>;
>> + interrupts = <0x0 0x0 0x4>;
>> + compatible = "brcm,pci-plat-dev";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
>> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &intc 0 47 3
>> + 0 0 0 2 &intc 0 48 3
>> + 0 0 0 3 &intc 0 49 3
>> + 0 0 0 4 &intc 0 50 3>;
>> + interrupt-names = "pcie_0_inta",
>> + "pcie_0_intb",
>> + "pcie_0_intc",
>> + "pcie_0_intd";
>> + clocks = <&sw_pcie0>;
>> + clock-names = "sw_pcie";
>> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
>> + msi-controller; /* use PCIe's internal MSI controller */
>> + brcm,ssc;
>> + brcm,gen = <1>;
>> + supply-names = "vreg-wifi-pwr";
>> + supplies = <&vreg-wifi-pwr>;
>> + linux,pci-domain = <0>;
>> + };
>> --
>> 1.9.0.138.g2de3478
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-12 17:52 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 17:52 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 11, 2017 at 8:55 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Hi Jim,
>
> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
pcie->gen = 0;
>> The DT bindings description of the Brcmstb PCIe device is described. This
>> node can be used by almost all Broadcom settop box chips, using
>> ARM, ARM64, or MIPS CPU architectures.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> new file mode 100644
>> index 0000000..2f699da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> @@ -0,0 +1,106 @@
>> +Brcmstb PCIe Host Controller Device Tree Bindings
>> +
>> +Introduction:
>> + The brcmstb host controller closely follows the example set in
>> +
>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>> +
>> + The rest of this document explains some added customizations and
>> + offers an example Brcmstb PCIe host controller DT node.
>> +
>> +Required Properties:
>> + reg -- the register start address and length for the PCIe block.
>> + Additional start,length pairs may be specified for clock addresses.
>> + interrupts -- two interrupts are specified; the first interrupt is for
>> + the PCI host controller and the second is for MSI if the built-in
>> + MSI controller is to be used.
>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>> + or "brcm,bcm7278-pcie".
>> + #address-cells -- the number of address cells for PCI-space.
>> + #size-cells -- the number of size cells for PCI-space.
>> + ranges -- See [1]; a specification of the outbound windows for the host
>> + controller. Each outbound window is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + Due to hardware limitations, there may be a maximum of four
>> + non-contiguous ranges specified.
>> + #interrupt-cells -- number of cells used to describe the interrupt.
>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>> + for our uses and the fourth cell is the mask (val = 0x7) for
>> + the legacy interrupt number [1..4].
>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>> + plus the size of the interrupt specifier.
>> + linux,pci-domain -- the domain of the host controller.
>> +
>> +Optional Properties:
>> + clocks -- list of clock phandles. If specified, this should list one
>> + clock.
>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>> + and the name of the clock is expected to be "sw_pcie".
>> + dma-ranges -- Similar in structure to ranges, each dma region is
>> + specified with a n-tuple. Dma-regions describe the inbound
>> + accesses from EP to RC; it translates the pci address that the
>> + EP "sees" to the CPU address in memory. This property is needed
>> + because the design of the Brcmstb memory subsystem often precludes
>> + idenity-mapping between CPU address space and PCIe address space.
>> + Each range is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>> + msi-parent. If this prop is set to the phandle of the PCIe
>> + node, or if the msi-parent prop is missing, the PCIE controller
>> + will attempt to use its built in MSI controller.
>> + msi-controller -- this property should only be specified if the
>> + PCIe controller is using its internal MSI controller.
>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>> + brcm,gen -- (integer) indicates desired generation of link:
>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>
> Does this differ from the 'max-link-speed' now documented in
> Documentation/devicetree/bindings/pci/pci.txt? If not, might as well use
> it, and of_pci_get_max_link_speed().
>
Hi Brian, yes that's what it is, will fix.
>> + supply-names -- the names of voltage regulators that the root
>> + complex should turn off/on/on on suspend/resume/boot. This
>> + is a string list.
>> + supplies -- A collection of phandles to a regulator nodes, see
>> + Documentation/devicetree/bindings/regulator/ for specific
>> + bindings. The number and order of phandles must match
>> + exactly the number of strings in the "supply-names" property.
>> +
>> +Example Node:
>> +
>> +pcie0: pcie at f0460000 {
>
> ^^ You've got a tab after the colon. Makes this look funky in my
> vim/mutt :)
>
> Brian
>
Will fix.
>> + reg = <0x0 0xf0460000 0x0 0x9310>;
>> + interrupts = <0x0 0x0 0x4>;
>> + compatible = "brcm,pci-plat-dev";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
>> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &intc 0 47 3
>> + 0 0 0 2 &intc 0 48 3
>> + 0 0 0 3 &intc 0 49 3
>> + 0 0 0 4 &intc 0 50 3>;
>> + interrupt-names = "pcie_0_inta",
>> + "pcie_0_intb",
>> + "pcie_0_intc",
>> + "pcie_0_intd";
>> + clocks = <&sw_pcie0>;
>> + clock-names = "sw_pcie";
>> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
>> + msi-controller; /* use PCIe's internal MSI controller */
>> + brcm,ssc;
>> + brcm,gen = <1>;
>> + supply-names = "vreg-wifi-pwr";
>> + supplies = <&vreg-wifi-pwr>;
>> + linux,pci-domain = <0>;
>> + };
>> --
>> 1.9.0.138.g2de3478
>>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-12 18:04 ` Robin Murphy
0 siblings, 0 replies; 146+ messages in thread
From: Robin Murphy @ 2017-10-12 18:04 UTC (permalink / raw)
To: Jim Quinlan, linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel,
Christoph Hellwig, Marek Szyprowski, iommu
[+DMA API maintainers]
On 11/10/17 23:34, Jim Quinlan wrote:
> The Broadcom STB PCIe host controller is intimately related to the
> memory subsystem. This close relationship adds complexity to how cpu
> system memory is mapped to PCIe memory. Ideally, this mapping is an
> identity mapping, or an identity mapping off by a constant. Not so in
> this case.
>
> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
> of system memory. Here is how the PCIe controller maps the
> system memory to PCIe memory:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> Although there are some "gaps" that can be added between the
> individual mappings by software, the permutation of memory regions for
> the most part is fixed by HW. The solution of having something close
> to an identity mapping is not possible.
>
> The idea behind this HW design is that the same PCIe module can
> act as an RC or EP, and if it acts as an EP it concatenates all
> of system memory into a BAR so anything can be accessed. Unfortunately,
> when the PCIe block is in the role of an RC it also presents this
> "BAR" to downstream PCIe devices, rather than offering an identity map
> between its system memory and PCIe space.
>
> Suppose that an endpoint driver allocs some DMA memory. Suppose this
> memory is located at 0x6000_0000, which is in the middle of memc1-a.
> The driver wants a dma_addr_t value that it can pass on to the EP to
> use. Without doing any custom mapping, the EP will use this value for
> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
> won't work; the device needs a dma_addr_t that reflects the PCIe space
> address, namely 0xa000_0000.
>
> So, essentially the solution to this problem must modify the
> dma_addr_t returned by the DMA routines routines. There are two
> ways (I know of) of doing this:
>
> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
> that are used by the dma_ops routines. This is the approach of
>
> arch/mips/cavium-octeon/dma-octeon.c
>
> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
> as static inline functions.
>
> (b) Subscribe to a notifier that notifies when a device is added to a
> bus. When this happens, set_dma_ops() can be called for the device.
> This method is mentioned in:
>
> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>
> where it says as a comment
>
> "In case if platform code need to use own special DMA
> configuration, it can use Platform bus notifier and
> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
> configuration."
>
> Solution (b) is what this commit does. It uses the native dma_ops
> as the base set of operations, and overrides some with custom
> functions that translate the address and then call the base
> function.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/pci/host/Makefile | 3 +-
> drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
> drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
> drivers/pci/host/pci-brcmstb.h | 7 ++
> 4 files changed, 368 insertions(+), 11 deletions(-)
> create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
>
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 4398d2c..c283321 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> obj-$(CONFIG_VMD) += vmd.o
> -obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
> +obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
> +brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>
> # The following drivers are for devices that use the generic ACPI
> # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
> new file mode 100644
> index 0000000..81ce122
> --- /dev/null
> +++ b/drivers/pci/host/pci-brcmstb-dma.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright (C) 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/dma-mapping.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/smp.h>
> +
> +#include "pci-brcmstb.h"
> +
> +static const struct dma_map_ops *arch_dma_ops;
> +static struct dma_map_ops brcm_dma_ops;
> +
> +static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> + gfp_t gfp, unsigned long attrs)
> +{
> + void *ret;
> +
> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
> + if (ret)
> + *handle = brcm_to_pci(*handle);
> + return ret;
> +}
> +
> +static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
> + dma_addr_t handle, unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
> +}
> +
> +static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + dma_addr = brcm_to_cpu(dma_addr);
> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
> +}
> +
> +static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
> + void *cpu_addr, dma_addr_t handle, size_t size,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
> + attrs);
> +}
> +
> +static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
> + dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int ret, i;
> + struct scatterlist *sg;
> +
> + ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
That's a pretty fragile assumption given that arch code is free to
change, and anyone doing so is unlikely to be aware of your driver.
You'd be better off implementing these in terms of {brcm_dma_}map_page
directly.
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, ret, i)
> + sg->dma_address = brcm_to_pci(sg->dma_address);
> + return ret;
> +}
> +
> +static void brcm_dma_unmap_sg(struct device *dev,
> + struct scatterlist *sgl, int nents,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int i;
> + struct scatterlist *sg;
> +
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, nents, i)
> + sg->dma_address = brcm_to_cpu(sg->dma_address);
> + arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> +}
> +
> +static void brcm_dma_sync_single_for_cpu(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
> +}
> +
> +static void brcm_dma_sync_single_for_device(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
> +}
And sync_sg_*()? They might not be that commonly used by in-tree
drivers, but who knows what lurks beyond?
> +
> +static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
> + size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_resource
> + (dev, phys, size, dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + return dma_addr == BRCMSTB_ERROR_CODE;
Huh? How do you know this will work correctly with every platform's
->map_page implementation (hint: it doesn't).
> +}
> +
> +static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
> +{
> +#if defined(CONFIG_MIPS)
> + return mips_dma_map_ops;
> +#elif defined(CONFIG_ARM)
> + return &arm_dma_ops;
> +#elif defined(CONFIG_ARM64)
> + /* swiotlb_dma_ops is a static var, so we get ahold
> + * of it by calling arch_setup_dma_ops(...).
> + */
> + arch_setup_dma_ops(dev, 0, 0, NULL, false);
> + return dev->dma_ops;
> +#endif
> + return 0;
> +}
As mentioned earlier, no. There are theoretical cases where it might not
be true, but in practice you can assume all PCI devices are going to get
the same DMA ops as their associated host controller (and that's still a
better assumption that what you have here), so you can just grab those
at the point you install the notifier.
> +
> +static void brcm_set_dma_ops(struct device *dev)
> +{
> + arch_dma_ops = brcm_get_arch_dma_ops(dev);
> + if (!arch_dma_ops)
> + return;
> +
> + /* Set all of the base operations; some will be overridden */
> + brcm_dma_ops = *arch_dma_ops;
> +
> + /* Insert the Brcm-specific override operations */
> + brcm_dma_ops.alloc = brcm_dma_alloc;
> + brcm_dma_ops.free = brcm_dma_free;
> + brcm_dma_ops.mmap = brcm_dma_mmap;
> + brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
> + brcm_dma_ops.map_page = brcm_dma_map_page;
> + brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
> + brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
> + brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
> + brcm_dma_ops.map_sg = brcm_dma_map_sg;
> + brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
> + if (arch_dma_ops->map_resource)
> + brcm_dma_ops.map_resource = brcm_dma_map_resource;
> + if (arch_dma_ops->unmap_resource)
> + brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
> + brcm_dma_ops.mapping_error = brcm_mapping_error;
> +
> + /* Use our brcm_dma_ops for this driver */
> + set_dma_ops(dev, &brcm_dma_ops);
> +}
Just have a static const set of ops like everyone else - you can handle
the conditionality of ->{map,unmap}_resource inside the brcm_* wrappers.
> +
> +static int brcmstb_platform_notifier(struct notifier_block *nb,
> + unsigned long event, void *__dev)
> +{
> + struct device *dev = __dev;
> +
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> +
> + brcm_set_dma_ops(dev);
> + return NOTIFY_OK;
> +}
> +
> +struct notifier_block brcmstb_platform_nb = {
> + .notifier_call = brcmstb_platform_notifier,
> +};
> +EXPORT_SYMBOL(brcmstb_platform_nb);
> diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
> index f4cd6e7..03c0da9 100644
> --- a/drivers/pci/host/pci-brcmstb.c
> +++ b/drivers/pci/host/pci-brcmstb.c
> @@ -343,6 +343,8 @@ struct brcm_pcie {
>
> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> +static struct of_pci_range *dma_ranges;
> +static int num_dma_ranges;
> static int num_memc;
> static DEFINE_MUTEX(brcm_pcie_lock);
>
> @@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> {
> mutex_lock(&brcm_pcie_lock);
> snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
> + if (list_empty(&brcm_pcie))
> + bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
> list_add_tail(&pcie->list, &brcm_pcie);
> mutex_unlock(&brcm_pcie_lock);
>
> @@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> tmp = list_entry(pos, struct brcm_pcie, list);
> if (tmp == pcie) {
> list_del(pos);
> - if (list_empty(&brcm_pcie))
> + if (list_empty(&brcm_pcie)) {
> + bus_unregister_notifier(&pci_bus_type,
> + &brcmstb_platform_nb);
> + kfree(dma_ranges);
> + dma_ranges = NULL;
> + num_dma_ranges = 0;
> num_memc = 0;
> + }
> break;
> }
> }
> @@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
> return 0;
> }
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> +
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
> + return addr - p->cpu_addr + p->pci_addr;
> +
> + return BRCMSTB_ERROR_CODE;
> +}
> +EXPORT_SYMBOL(brcm_to_pci);
AFAICS it doesn't make much sense for anyone outside this driver to ever
be calling these.
> +dma_addr_t brcm_to_cpu(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
> + return addr - p->pci_addr + p->cpu_addr;
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(brcm_to_cpu);
> +
> static u32 mdio_form_pkt(int port, int regad, int cmd)
> {
> u32 pkt = 0;
> @@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
> return 0;
> }
>
> +static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> + struct device_node *node)
> +{
> + const int na = 3, ns = 2;
> + int rlen;
> +
> + parser->node = node;
> + parser->pna = of_n_addr_cells(node);
> + parser->np = parser->pna + na + ns;
> +
> + parser->range = of_get_property(node, "dma-ranges", &rlen);
> + if (!parser->range)
> + return -ENOENT;
> +
> + parser->end = parser->range + rlen / sizeof(__be32);
> +
> + return 0;
> +}
Note that we've got a factored-out helper for this queued in -next
already - see here:
https://patchwork.kernel.org/patch/9927541/
> +
> +static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i, ret = 0;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + mutex_lock(&brcm_pcie_lock);
> + if (dma_ranges)
> + goto done;
> +
> + /* Parse dma-ranges property if present. If there are multiple
> + * PCI controllers, we only have to parse from one of them since
> + * the others will have an identical mapping.
> + */
> + if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
> + unsigned int max_ranges
> + = (parser.end - parser.range) / parser.np;
> +
> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
> + GFP_KERNEL);
> + if (!dma_ranges) {
> + ret = -ENOMEM;
> + goto done;
> + }
> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
> + i++)
> + num_dma_ranges++;
> + }
> +
> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
> + u64 size = brcmstb_memory_memc_size(i);
> +
> + if (size == (u64)-1) {
> + dev_err(pcie->dev, "cannot get memc%d size", i);
> + ret = -EINVAL;
> + goto done;
> + } else if (size) {
> + scb_size[i] = roundup_pow_of_two_64(size);
> + num_memc++;
> + } else {
> + break;
> + }
> + }
> +
> +done:
> + mutex_unlock(&brcm_pcie_lock);
> + return ret;
> +}
> +
> static void set_regulators(struct brcm_pcie *pcie, bool on)
> {
> struct list_head *pos;
> @@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
> */
> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>
> - /* Set simple configuration based on memory sizes
> - * only. We always start the viewport at address 0.
> - */
> - rc_bar2_offset = 0;
> + if (dma_ranges) {
> + /* The best-case scenario is to place the inbound
> + * region in the first 4GB of pci-space, as some
> + * legacy devices can only address 32bits.
> + * We would also like to put the MSI under 4GB
> + * as well, since some devices require a 32bit
> + * MSI target address.
> + */
> + if (total_mem_size <= 0xc0000000ULL &&
> + rc_bar2_size <= 0x100000000ULL) {
> + rc_bar2_offset = 0;
> + } else {
> + /* The system memory is 4GB or larger so we
> + * cannot start the inbound region at location
> + * 0 (since we have to allow some space for
> + * outbound memory @ 3GB). So instead we
> + * start it at the 1x multiple of its size
> + */
> + rc_bar2_offset = rc_bar2_size;
> + }
> +
> + } else {
> + /* Set simple configuration based on memory sizes
> + * only. We always start the viewport at address 0,
> + * and set the MSI target address accordingly.
> + */
> + rc_bar2_offset = 0;
> + }
>
> tmp = lower_32_bits(rc_bar2_offset);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> @@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
> - pr_err("cannot yet handle dma-ranges\n");
> - return -EINVAL;
> - }
> -
> data = of_id->data;
> pcie->reg_offsets = data->offsets;
> pcie->reg_field_info = data->reg_field_info;
> @@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = brcm_parse_dma_ranges(pcie);
> + if (ret)
> + return ret;
> +
> ret = clk_prepare_enable(pcie->clk);
> if (ret) {
> dev_err(&pdev->dev, "could not enable clock\n");
> diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
> index 86f9cd1..4851be8 100644
> --- a/drivers/pci/host/pci-brcmstb.h
> +++ b/drivers/pci/host/pci-brcmstb.h
> @@ -21,6 +21,13 @@
> /* Broadcom PCIE Offsets */
> #define PCIE_INTR2_CPU_BASE 0x4300
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr);
> +dma_addr_t brcm_to_cpu(dma_addr_t addr);
> +
> +extern struct notifier_block brcmstb_platform_nb;
It seems a bit weird to have the notifier code split across two
compilation units in the way which requires this - it seems more
reasonable to have it all together on one side or the other, with the
common interface being either the callback for setting the ops or a
function for installing the notifier, depending on where things fall.
Robin.
> +
> +#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
> +
> #if defined(CONFIG_MIPS)
> /* Broadcom MIPs HW implicitly does the swapping if necessary */
> #define bcm_readl(a) __raw_readl(a)
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-12 18:04 ` Robin Murphy
0 siblings, 0 replies; 146+ messages in thread
From: Robin Murphy @ 2017-10-12 18:04 UTC (permalink / raw)
To: Jim Quinlan, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
Florian Fainelli, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Kevin Cernekee, Will Deacon,
Ralf Baechle, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Rob Herring, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Christoph Hellwig,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[+DMA API maintainers]
On 11/10/17 23:34, Jim Quinlan wrote:
> The Broadcom STB PCIe host controller is intimately related to the
> memory subsystem. This close relationship adds complexity to how cpu
> system memory is mapped to PCIe memory. Ideally, this mapping is an
> identity mapping, or an identity mapping off by a constant. Not so in
> this case.
>
> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
> of system memory. Here is how the PCIe controller maps the
> system memory to PCIe memory:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> Although there are some "gaps" that can be added between the
> individual mappings by software, the permutation of memory regions for
> the most part is fixed by HW. The solution of having something close
> to an identity mapping is not possible.
>
> The idea behind this HW design is that the same PCIe module can
> act as an RC or EP, and if it acts as an EP it concatenates all
> of system memory into a BAR so anything can be accessed. Unfortunately,
> when the PCIe block is in the role of an RC it also presents this
> "BAR" to downstream PCIe devices, rather than offering an identity map
> between its system memory and PCIe space.
>
> Suppose that an endpoint driver allocs some DMA memory. Suppose this
> memory is located at 0x6000_0000, which is in the middle of memc1-a.
> The driver wants a dma_addr_t value that it can pass on to the EP to
> use. Without doing any custom mapping, the EP will use this value for
> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
> won't work; the device needs a dma_addr_t that reflects the PCIe space
> address, namely 0xa000_0000.
>
> So, essentially the solution to this problem must modify the
> dma_addr_t returned by the DMA routines routines. There are two
> ways (I know of) of doing this:
>
> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
> that are used by the dma_ops routines. This is the approach of
>
> arch/mips/cavium-octeon/dma-octeon.c
>
> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
> as static inline functions.
>
> (b) Subscribe to a notifier that notifies when a device is added to a
> bus. When this happens, set_dma_ops() can be called for the device.
> This method is mentioned in:
>
> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>
> where it says as a comment
>
> "In case if platform code need to use own special DMA
> configuration, it can use Platform bus notifier and
> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
> configuration."
>
> Solution (b) is what this commit does. It uses the native dma_ops
> as the base set of operations, and overrides some with custom
> functions that translate the address and then call the base
> function.
>
> Signed-off-by: Jim Quinlan <jim2101024-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/pci/host/Makefile | 3 +-
> drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
> drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
> drivers/pci/host/pci-brcmstb.h | 7 ++
> 4 files changed, 368 insertions(+), 11 deletions(-)
> create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
>
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 4398d2c..c283321 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> obj-$(CONFIG_VMD) += vmd.o
> -obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
> +obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
> +brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>
> # The following drivers are for devices that use the generic ACPI
> # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
> new file mode 100644
> index 0000000..81ce122
> --- /dev/null
> +++ b/drivers/pci/host/pci-brcmstb-dma.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright (C) 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/dma-mapping.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/smp.h>
> +
> +#include "pci-brcmstb.h"
> +
> +static const struct dma_map_ops *arch_dma_ops;
> +static struct dma_map_ops brcm_dma_ops;
> +
> +static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> + gfp_t gfp, unsigned long attrs)
> +{
> + void *ret;
> +
> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
> + if (ret)
> + *handle = brcm_to_pci(*handle);
> + return ret;
> +}
> +
> +static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
> + dma_addr_t handle, unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
> +}
> +
> +static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + dma_addr = brcm_to_cpu(dma_addr);
> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
> +}
> +
> +static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
> + void *cpu_addr, dma_addr_t handle, size_t size,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
> + attrs);
> +}
> +
> +static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
> + dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int ret, i;
> + struct scatterlist *sg;
> +
> + ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
That's a pretty fragile assumption given that arch code is free to
change, and anyone doing so is unlikely to be aware of your driver.
You'd be better off implementing these in terms of {brcm_dma_}map_page
directly.
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, ret, i)
> + sg->dma_address = brcm_to_pci(sg->dma_address);
> + return ret;
> +}
> +
> +static void brcm_dma_unmap_sg(struct device *dev,
> + struct scatterlist *sgl, int nents,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int i;
> + struct scatterlist *sg;
> +
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, nents, i)
> + sg->dma_address = brcm_to_cpu(sg->dma_address);
> + arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> +}
> +
> +static void brcm_dma_sync_single_for_cpu(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
> +}
> +
> +static void brcm_dma_sync_single_for_device(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
> +}
And sync_sg_*()? They might not be that commonly used by in-tree
drivers, but who knows what lurks beyond?
> +
> +static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
> + size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_resource
> + (dev, phys, size, dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + return dma_addr == BRCMSTB_ERROR_CODE;
Huh? How do you know this will work correctly with every platform's
->map_page implementation (hint: it doesn't).
> +}
> +
> +static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
> +{
> +#if defined(CONFIG_MIPS)
> + return mips_dma_map_ops;
> +#elif defined(CONFIG_ARM)
> + return &arm_dma_ops;
> +#elif defined(CONFIG_ARM64)
> + /* swiotlb_dma_ops is a static var, so we get ahold
> + * of it by calling arch_setup_dma_ops(...).
> + */
> + arch_setup_dma_ops(dev, 0, 0, NULL, false);
> + return dev->dma_ops;
> +#endif
> + return 0;
> +}
As mentioned earlier, no. There are theoretical cases where it might not
be true, but in practice you can assume all PCI devices are going to get
the same DMA ops as their associated host controller (and that's still a
better assumption that what you have here), so you can just grab those
at the point you install the notifier.
> +
> +static void brcm_set_dma_ops(struct device *dev)
> +{
> + arch_dma_ops = brcm_get_arch_dma_ops(dev);
> + if (!arch_dma_ops)
> + return;
> +
> + /* Set all of the base operations; some will be overridden */
> + brcm_dma_ops = *arch_dma_ops;
> +
> + /* Insert the Brcm-specific override operations */
> + brcm_dma_ops.alloc = brcm_dma_alloc;
> + brcm_dma_ops.free = brcm_dma_free;
> + brcm_dma_ops.mmap = brcm_dma_mmap;
> + brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
> + brcm_dma_ops.map_page = brcm_dma_map_page;
> + brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
> + brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
> + brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
> + brcm_dma_ops.map_sg = brcm_dma_map_sg;
> + brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
> + if (arch_dma_ops->map_resource)
> + brcm_dma_ops.map_resource = brcm_dma_map_resource;
> + if (arch_dma_ops->unmap_resource)
> + brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
> + brcm_dma_ops.mapping_error = brcm_mapping_error;
> +
> + /* Use our brcm_dma_ops for this driver */
> + set_dma_ops(dev, &brcm_dma_ops);
> +}
Just have a static const set of ops like everyone else - you can handle
the conditionality of ->{map,unmap}_resource inside the brcm_* wrappers.
> +
> +static int brcmstb_platform_notifier(struct notifier_block *nb,
> + unsigned long event, void *__dev)
> +{
> + struct device *dev = __dev;
> +
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> +
> + brcm_set_dma_ops(dev);
> + return NOTIFY_OK;
> +}
> +
> +struct notifier_block brcmstb_platform_nb = {
> + .notifier_call = brcmstb_platform_notifier,
> +};
> +EXPORT_SYMBOL(brcmstb_platform_nb);
> diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
> index f4cd6e7..03c0da9 100644
> --- a/drivers/pci/host/pci-brcmstb.c
> +++ b/drivers/pci/host/pci-brcmstb.c
> @@ -343,6 +343,8 @@ struct brcm_pcie {
>
> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> +static struct of_pci_range *dma_ranges;
> +static int num_dma_ranges;
> static int num_memc;
> static DEFINE_MUTEX(brcm_pcie_lock);
>
> @@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> {
> mutex_lock(&brcm_pcie_lock);
> snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
> + if (list_empty(&brcm_pcie))
> + bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
> list_add_tail(&pcie->list, &brcm_pcie);
> mutex_unlock(&brcm_pcie_lock);
>
> @@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> tmp = list_entry(pos, struct brcm_pcie, list);
> if (tmp == pcie) {
> list_del(pos);
> - if (list_empty(&brcm_pcie))
> + if (list_empty(&brcm_pcie)) {
> + bus_unregister_notifier(&pci_bus_type,
> + &brcmstb_platform_nb);
> + kfree(dma_ranges);
> + dma_ranges = NULL;
> + num_dma_ranges = 0;
> num_memc = 0;
> + }
> break;
> }
> }
> @@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
> return 0;
> }
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> +
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
> + return addr - p->cpu_addr + p->pci_addr;
> +
> + return BRCMSTB_ERROR_CODE;
> +}
> +EXPORT_SYMBOL(brcm_to_pci);
AFAICS it doesn't make much sense for anyone outside this driver to ever
be calling these.
> +dma_addr_t brcm_to_cpu(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
> + return addr - p->pci_addr + p->cpu_addr;
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(brcm_to_cpu);
> +
> static u32 mdio_form_pkt(int port, int regad, int cmd)
> {
> u32 pkt = 0;
> @@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
> return 0;
> }
>
> +static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> + struct device_node *node)
> +{
> + const int na = 3, ns = 2;
> + int rlen;
> +
> + parser->node = node;
> + parser->pna = of_n_addr_cells(node);
> + parser->np = parser->pna + na + ns;
> +
> + parser->range = of_get_property(node, "dma-ranges", &rlen);
> + if (!parser->range)
> + return -ENOENT;
> +
> + parser->end = parser->range + rlen / sizeof(__be32);
> +
> + return 0;
> +}
Note that we've got a factored-out helper for this queued in -next
already - see here:
https://patchwork.kernel.org/patch/9927541/
> +
> +static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i, ret = 0;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + mutex_lock(&brcm_pcie_lock);
> + if (dma_ranges)
> + goto done;
> +
> + /* Parse dma-ranges property if present. If there are multiple
> + * PCI controllers, we only have to parse from one of them since
> + * the others will have an identical mapping.
> + */
> + if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
> + unsigned int max_ranges
> + = (parser.end - parser.range) / parser.np;
> +
> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
> + GFP_KERNEL);
> + if (!dma_ranges) {
> + ret = -ENOMEM;
> + goto done;
> + }
> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
> + i++)
> + num_dma_ranges++;
> + }
> +
> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
> + u64 size = brcmstb_memory_memc_size(i);
> +
> + if (size == (u64)-1) {
> + dev_err(pcie->dev, "cannot get memc%d size", i);
> + ret = -EINVAL;
> + goto done;
> + } else if (size) {
> + scb_size[i] = roundup_pow_of_two_64(size);
> + num_memc++;
> + } else {
> + break;
> + }
> + }
> +
> +done:
> + mutex_unlock(&brcm_pcie_lock);
> + return ret;
> +}
> +
> static void set_regulators(struct brcm_pcie *pcie, bool on)
> {
> struct list_head *pos;
> @@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
> */
> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>
> - /* Set simple configuration based on memory sizes
> - * only. We always start the viewport at address 0.
> - */
> - rc_bar2_offset = 0;
> + if (dma_ranges) {
> + /* The best-case scenario is to place the inbound
> + * region in the first 4GB of pci-space, as some
> + * legacy devices can only address 32bits.
> + * We would also like to put the MSI under 4GB
> + * as well, since some devices require a 32bit
> + * MSI target address.
> + */
> + if (total_mem_size <= 0xc0000000ULL &&
> + rc_bar2_size <= 0x100000000ULL) {
> + rc_bar2_offset = 0;
> + } else {
> + /* The system memory is 4GB or larger so we
> + * cannot start the inbound region at location
> + * 0 (since we have to allow some space for
> + * outbound memory @ 3GB). So instead we
> + * start it at the 1x multiple of its size
> + */
> + rc_bar2_offset = rc_bar2_size;
> + }
> +
> + } else {
> + /* Set simple configuration based on memory sizes
> + * only. We always start the viewport at address 0,
> + * and set the MSI target address accordingly.
> + */
> + rc_bar2_offset = 0;
> + }
>
> tmp = lower_32_bits(rc_bar2_offset);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> @@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
> - pr_err("cannot yet handle dma-ranges\n");
> - return -EINVAL;
> - }
> -
> data = of_id->data;
> pcie->reg_offsets = data->offsets;
> pcie->reg_field_info = data->reg_field_info;
> @@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = brcm_parse_dma_ranges(pcie);
> + if (ret)
> + return ret;
> +
> ret = clk_prepare_enable(pcie->clk);
> if (ret) {
> dev_err(&pdev->dev, "could not enable clock\n");
> diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
> index 86f9cd1..4851be8 100644
> --- a/drivers/pci/host/pci-brcmstb.h
> +++ b/drivers/pci/host/pci-brcmstb.h
> @@ -21,6 +21,13 @@
> /* Broadcom PCIE Offsets */
> #define PCIE_INTR2_CPU_BASE 0x4300
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr);
> +dma_addr_t brcm_to_cpu(dma_addr_t addr);
> +
> +extern struct notifier_block brcmstb_platform_nb;
It seems a bit weird to have the notifier code split across two
compilation units in the way which requires this - it seems more
reasonable to have it all together on one side or the other, with the
common interface being either the callback for setting the ops or a
function for installing the notifier, depending on where things fall.
Robin.
> +
> +#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
> +
> #if defined(CONFIG_MIPS)
> /* Broadcom MIPs HW implicitly does the swapping if necessary */
> #define bcm_readl(a) __raw_readl(a)
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-12 18:04 ` Robin Murphy
0 siblings, 0 replies; 146+ messages in thread
From: Robin Murphy @ 2017-10-12 18:04 UTC (permalink / raw)
To: Jim Quinlan, linux-kernel
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle, iommu,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, Christoph Hellwig,
linux-arm-kernel, Marek Szyprowski
[+DMA API maintainers]
On 11/10/17 23:34, Jim Quinlan wrote:
> The Broadcom STB PCIe host controller is intimately related to the
> memory subsystem. This close relationship adds complexity to how cpu
> system memory is mapped to PCIe memory. Ideally, this mapping is an
> identity mapping, or an identity mapping off by a constant. Not so in
> this case.
>
> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
> of system memory. Here is how the PCIe controller maps the
> system memory to PCIe memory:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> Although there are some "gaps" that can be added between the
> individual mappings by software, the permutation of memory regions for
> the most part is fixed by HW. The solution of having something close
> to an identity mapping is not possible.
>
> The idea behind this HW design is that the same PCIe module can
> act as an RC or EP, and if it acts as an EP it concatenates all
> of system memory into a BAR so anything can be accessed. Unfortunately,
> when the PCIe block is in the role of an RC it also presents this
> "BAR" to downstream PCIe devices, rather than offering an identity map
> between its system memory and PCIe space.
>
> Suppose that an endpoint driver allocs some DMA memory. Suppose this
> memory is located at 0x6000_0000, which is in the middle of memc1-a.
> The driver wants a dma_addr_t value that it can pass on to the EP to
> use. Without doing any custom mapping, the EP will use this value for
> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
> won't work; the device needs a dma_addr_t that reflects the PCIe space
> address, namely 0xa000_0000.
>
> So, essentially the solution to this problem must modify the
> dma_addr_t returned by the DMA routines routines. There are two
> ways (I know of) of doing this:
>
> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
> that are used by the dma_ops routines. This is the approach of
>
> arch/mips/cavium-octeon/dma-octeon.c
>
> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
> as static inline functions.
>
> (b) Subscribe to a notifier that notifies when a device is added to a
> bus. When this happens, set_dma_ops() can be called for the device.
> This method is mentioned in:
>
> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>
> where it says as a comment
>
> "In case if platform code need to use own special DMA
> configuration, it can use Platform bus notifier and
> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
> configuration."
>
> Solution (b) is what this commit does. It uses the native dma_ops
> as the base set of operations, and overrides some with custom
> functions that translate the address and then call the base
> function.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/pci/host/Makefile | 3 +-
> drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
> drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
> drivers/pci/host/pci-brcmstb.h | 7 ++
> 4 files changed, 368 insertions(+), 11 deletions(-)
> create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
>
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 4398d2c..c283321 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> obj-$(CONFIG_VMD) += vmd.o
> -obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
> +obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
> +brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>
> # The following drivers are for devices that use the generic ACPI
> # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
> new file mode 100644
> index 0000000..81ce122
> --- /dev/null
> +++ b/drivers/pci/host/pci-brcmstb-dma.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright (C) 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/dma-mapping.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/smp.h>
> +
> +#include "pci-brcmstb.h"
> +
> +static const struct dma_map_ops *arch_dma_ops;
> +static struct dma_map_ops brcm_dma_ops;
> +
> +static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> + gfp_t gfp, unsigned long attrs)
> +{
> + void *ret;
> +
> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
> + if (ret)
> + *handle = brcm_to_pci(*handle);
> + return ret;
> +}
> +
> +static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
> + dma_addr_t handle, unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
> +}
> +
> +static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + dma_addr = brcm_to_cpu(dma_addr);
> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
> +}
> +
> +static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
> + void *cpu_addr, dma_addr_t handle, size_t size,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
> + attrs);
> +}
> +
> +static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
> + dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int ret, i;
> + struct scatterlist *sg;
> +
> + ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
That's a pretty fragile assumption given that arch code is free to
change, and anyone doing so is unlikely to be aware of your driver.
You'd be better off implementing these in terms of {brcm_dma_}map_page
directly.
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, ret, i)
> + sg->dma_address = brcm_to_pci(sg->dma_address);
> + return ret;
> +}
> +
> +static void brcm_dma_unmap_sg(struct device *dev,
> + struct scatterlist *sgl, int nents,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int i;
> + struct scatterlist *sg;
> +
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, nents, i)
> + sg->dma_address = brcm_to_cpu(sg->dma_address);
> + arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> +}
> +
> +static void brcm_dma_sync_single_for_cpu(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
> +}
> +
> +static void brcm_dma_sync_single_for_device(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
> +}
And sync_sg_*()? They might not be that commonly used by in-tree
drivers, but who knows what lurks beyond?
> +
> +static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
> + size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_resource
> + (dev, phys, size, dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + return dma_addr == BRCMSTB_ERROR_CODE;
Huh? How do you know this will work correctly with every platform's
->map_page implementation (hint: it doesn't).
> +}
> +
> +static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
> +{
> +#if defined(CONFIG_MIPS)
> + return mips_dma_map_ops;
> +#elif defined(CONFIG_ARM)
> + return &arm_dma_ops;
> +#elif defined(CONFIG_ARM64)
> + /* swiotlb_dma_ops is a static var, so we get ahold
> + * of it by calling arch_setup_dma_ops(...).
> + */
> + arch_setup_dma_ops(dev, 0, 0, NULL, false);
> + return dev->dma_ops;
> +#endif
> + return 0;
> +}
As mentioned earlier, no. There are theoretical cases where it might not
be true, but in practice you can assume all PCI devices are going to get
the same DMA ops as their associated host controller (and that's still a
better assumption that what you have here), so you can just grab those
at the point you install the notifier.
> +
> +static void brcm_set_dma_ops(struct device *dev)
> +{
> + arch_dma_ops = brcm_get_arch_dma_ops(dev);
> + if (!arch_dma_ops)
> + return;
> +
> + /* Set all of the base operations; some will be overridden */
> + brcm_dma_ops = *arch_dma_ops;
> +
> + /* Insert the Brcm-specific override operations */
> + brcm_dma_ops.alloc = brcm_dma_alloc;
> + brcm_dma_ops.free = brcm_dma_free;
> + brcm_dma_ops.mmap = brcm_dma_mmap;
> + brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
> + brcm_dma_ops.map_page = brcm_dma_map_page;
> + brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
> + brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
> + brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
> + brcm_dma_ops.map_sg = brcm_dma_map_sg;
> + brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
> + if (arch_dma_ops->map_resource)
> + brcm_dma_ops.map_resource = brcm_dma_map_resource;
> + if (arch_dma_ops->unmap_resource)
> + brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
> + brcm_dma_ops.mapping_error = brcm_mapping_error;
> +
> + /* Use our brcm_dma_ops for this driver */
> + set_dma_ops(dev, &brcm_dma_ops);
> +}
Just have a static const set of ops like everyone else - you can handle
the conditionality of ->{map,unmap}_resource inside the brcm_* wrappers.
> +
> +static int brcmstb_platform_notifier(struct notifier_block *nb,
> + unsigned long event, void *__dev)
> +{
> + struct device *dev = __dev;
> +
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> +
> + brcm_set_dma_ops(dev);
> + return NOTIFY_OK;
> +}
> +
> +struct notifier_block brcmstb_platform_nb = {
> + .notifier_call = brcmstb_platform_notifier,
> +};
> +EXPORT_SYMBOL(brcmstb_platform_nb);
> diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
> index f4cd6e7..03c0da9 100644
> --- a/drivers/pci/host/pci-brcmstb.c
> +++ b/drivers/pci/host/pci-brcmstb.c
> @@ -343,6 +343,8 @@ struct brcm_pcie {
>
> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> +static struct of_pci_range *dma_ranges;
> +static int num_dma_ranges;
> static int num_memc;
> static DEFINE_MUTEX(brcm_pcie_lock);
>
> @@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> {
> mutex_lock(&brcm_pcie_lock);
> snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
> + if (list_empty(&brcm_pcie))
> + bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
> list_add_tail(&pcie->list, &brcm_pcie);
> mutex_unlock(&brcm_pcie_lock);
>
> @@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> tmp = list_entry(pos, struct brcm_pcie, list);
> if (tmp == pcie) {
> list_del(pos);
> - if (list_empty(&brcm_pcie))
> + if (list_empty(&brcm_pcie)) {
> + bus_unregister_notifier(&pci_bus_type,
> + &brcmstb_platform_nb);
> + kfree(dma_ranges);
> + dma_ranges = NULL;
> + num_dma_ranges = 0;
> num_memc = 0;
> + }
> break;
> }
> }
> @@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
> return 0;
> }
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> +
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
> + return addr - p->cpu_addr + p->pci_addr;
> +
> + return BRCMSTB_ERROR_CODE;
> +}
> +EXPORT_SYMBOL(brcm_to_pci);
AFAICS it doesn't make much sense for anyone outside this driver to ever
be calling these.
> +dma_addr_t brcm_to_cpu(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
> + return addr - p->pci_addr + p->cpu_addr;
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(brcm_to_cpu);
> +
> static u32 mdio_form_pkt(int port, int regad, int cmd)
> {
> u32 pkt = 0;
> @@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
> return 0;
> }
>
> +static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> + struct device_node *node)
> +{
> + const int na = 3, ns = 2;
> + int rlen;
> +
> + parser->node = node;
> + parser->pna = of_n_addr_cells(node);
> + parser->np = parser->pna + na + ns;
> +
> + parser->range = of_get_property(node, "dma-ranges", &rlen);
> + if (!parser->range)
> + return -ENOENT;
> +
> + parser->end = parser->range + rlen / sizeof(__be32);
> +
> + return 0;
> +}
Note that we've got a factored-out helper for this queued in -next
already - see here:
https://patchwork.kernel.org/patch/9927541/
> +
> +static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i, ret = 0;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + mutex_lock(&brcm_pcie_lock);
> + if (dma_ranges)
> + goto done;
> +
> + /* Parse dma-ranges property if present. If there are multiple
> + * PCI controllers, we only have to parse from one of them since
> + * the others will have an identical mapping.
> + */
> + if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
> + unsigned int max_ranges
> + = (parser.end - parser.range) / parser.np;
> +
> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
> + GFP_KERNEL);
> + if (!dma_ranges) {
> + ret = -ENOMEM;
> + goto done;
> + }
> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
> + i++)
> + num_dma_ranges++;
> + }
> +
> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
> + u64 size = brcmstb_memory_memc_size(i);
> +
> + if (size == (u64)-1) {
> + dev_err(pcie->dev, "cannot get memc%d size", i);
> + ret = -EINVAL;
> + goto done;
> + } else if (size) {
> + scb_size[i] = roundup_pow_of_two_64(size);
> + num_memc++;
> + } else {
> + break;
> + }
> + }
> +
> +done:
> + mutex_unlock(&brcm_pcie_lock);
> + return ret;
> +}
> +
> static void set_regulators(struct brcm_pcie *pcie, bool on)
> {
> struct list_head *pos;
> @@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
> */
> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>
> - /* Set simple configuration based on memory sizes
> - * only. We always start the viewport at address 0.
> - */
> - rc_bar2_offset = 0;
> + if (dma_ranges) {
> + /* The best-case scenario is to place the inbound
> + * region in the first 4GB of pci-space, as some
> + * legacy devices can only address 32bits.
> + * We would also like to put the MSI under 4GB
> + * as well, since some devices require a 32bit
> + * MSI target address.
> + */
> + if (total_mem_size <= 0xc0000000ULL &&
> + rc_bar2_size <= 0x100000000ULL) {
> + rc_bar2_offset = 0;
> + } else {
> + /* The system memory is 4GB or larger so we
> + * cannot start the inbound region at location
> + * 0 (since we have to allow some space for
> + * outbound memory @ 3GB). So instead we
> + * start it at the 1x multiple of its size
> + */
> + rc_bar2_offset = rc_bar2_size;
> + }
> +
> + } else {
> + /* Set simple configuration based on memory sizes
> + * only. We always start the viewport at address 0,
> + * and set the MSI target address accordingly.
> + */
> + rc_bar2_offset = 0;
> + }
>
> tmp = lower_32_bits(rc_bar2_offset);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> @@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
> - pr_err("cannot yet handle dma-ranges\n");
> - return -EINVAL;
> - }
> -
> data = of_id->data;
> pcie->reg_offsets = data->offsets;
> pcie->reg_field_info = data->reg_field_info;
> @@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = brcm_parse_dma_ranges(pcie);
> + if (ret)
> + return ret;
> +
> ret = clk_prepare_enable(pcie->clk);
> if (ret) {
> dev_err(&pdev->dev, "could not enable clock\n");
> diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
> index 86f9cd1..4851be8 100644
> --- a/drivers/pci/host/pci-brcmstb.h
> +++ b/drivers/pci/host/pci-brcmstb.h
> @@ -21,6 +21,13 @@
> /* Broadcom PCIE Offsets */
> #define PCIE_INTR2_CPU_BASE 0x4300
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr);
> +dma_addr_t brcm_to_cpu(dma_addr_t addr);
> +
> +extern struct notifier_block brcmstb_platform_nb;
It seems a bit weird to have the notifier code split across two
compilation units in the way which requires this - it seems more
reasonable to have it all together on one side or the other, with the
common interface being either the callback for setting the ops or a
function for installing the notifier, depending on where things fall.
Robin.
> +
> +#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
> +
> #if defined(CONFIG_MIPS)
> /* Broadcom MIPs HW implicitly does the swapping if necessary */
> #define bcm_readl(a) __raw_readl(a)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-12 18:04 ` Robin Murphy
0 siblings, 0 replies; 146+ messages in thread
From: Robin Murphy @ 2017-10-12 18:04 UTC (permalink / raw)
To: linux-arm-kernel
[+DMA API maintainers]
On 11/10/17 23:34, Jim Quinlan wrote:
> The Broadcom STB PCIe host controller is intimately related to the
> memory subsystem. This close relationship adds complexity to how cpu
> system memory is mapped to PCIe memory. Ideally, this mapping is an
> identity mapping, or an identity mapping off by a constant. Not so in
> this case.
>
> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
> of system memory. Here is how the PCIe controller maps the
> system memory to PCIe memory:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> Although there are some "gaps" that can be added between the
> individual mappings by software, the permutation of memory regions for
> the most part is fixed by HW. The solution of having something close
> to an identity mapping is not possible.
>
> The idea behind this HW design is that the same PCIe module can
> act as an RC or EP, and if it acts as an EP it concatenates all
> of system memory into a BAR so anything can be accessed. Unfortunately,
> when the PCIe block is in the role of an RC it also presents this
> "BAR" to downstream PCIe devices, rather than offering an identity map
> between its system memory and PCIe space.
>
> Suppose that an endpoint driver allocs some DMA memory. Suppose this
> memory is located at 0x6000_0000, which is in the middle of memc1-a.
> The driver wants a dma_addr_t value that it can pass on to the EP to
> use. Without doing any custom mapping, the EP will use this value for
> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
> won't work; the device needs a dma_addr_t that reflects the PCIe space
> address, namely 0xa000_0000.
>
> So, essentially the solution to this problem must modify the
> dma_addr_t returned by the DMA routines routines. There are two
> ways (I know of) of doing this:
>
> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
> that are used by the dma_ops routines. This is the approach of
>
> arch/mips/cavium-octeon/dma-octeon.c
>
> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
> as static inline functions.
>
> (b) Subscribe to a notifier that notifies when a device is added to a
> bus. When this happens, set_dma_ops() can be called for the device.
> This method is mentioned in:
>
> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>
> where it says as a comment
>
> "In case if platform code need to use own special DMA
> configuration, it can use Platform bus notifier and
> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
> configuration."
>
> Solution (b) is what this commit does. It uses the native dma_ops
> as the base set of operations, and overrides some with custom
> functions that translate the address and then call the base
> function.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/pci/host/Makefile | 3 +-
> drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
> drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
> drivers/pci/host/pci-brcmstb.h | 7 ++
> 4 files changed, 368 insertions(+), 11 deletions(-)
> create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
>
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 4398d2c..c283321 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> obj-$(CONFIG_VMD) += vmd.o
> -obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
> +obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
> +brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>
> # The following drivers are for devices that use the generic ACPI
> # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
> new file mode 100644
> index 0000000..81ce122
> --- /dev/null
> +++ b/drivers/pci/host/pci-brcmstb-dma.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright (C) 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/dma-mapping.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/smp.h>
> +
> +#include "pci-brcmstb.h"
> +
> +static const struct dma_map_ops *arch_dma_ops;
> +static struct dma_map_ops brcm_dma_ops;
> +
> +static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> + gfp_t gfp, unsigned long attrs)
> +{
> + void *ret;
> +
> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
> + if (ret)
> + *handle = brcm_to_pci(*handle);
> + return ret;
> +}
> +
> +static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
> + dma_addr_t handle, unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
> +}
> +
> +static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + dma_addr = brcm_to_cpu(dma_addr);
> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
> +}
> +
> +static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
> + void *cpu_addr, dma_addr_t handle, size_t size,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
> + attrs);
> +}
> +
> +static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
> + dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int ret, i;
> + struct scatterlist *sg;
> +
> + ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
That's a pretty fragile assumption given that arch code is free to
change, and anyone doing so is unlikely to be aware of your driver.
You'd be better off implementing these in terms of {brcm_dma_}map_page
directly.
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, ret, i)
> + sg->dma_address = brcm_to_pci(sg->dma_address);
> + return ret;
> +}
> +
> +static void brcm_dma_unmap_sg(struct device *dev,
> + struct scatterlist *sgl, int nents,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int i;
> + struct scatterlist *sg;
> +
> + /* The ARM and MIPS implementations of map_sg and unmap_sg
> + * make calls to ops->map_page(), which we already intercept.
> + * The ARM64 does not, so we must iterate through the SG list
> + * and convert each dma_address to one that is compatible
> + * with our PCI RC implementation.
> + */
> + if (IS_ENABLED(CONFIG_ARM64))
> + for_each_sg(sgl, sg, nents, i)
> + sg->dma_address = brcm_to_cpu(sg->dma_address);
> + arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
> +}
> +
> +static void brcm_dma_sync_single_for_cpu(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
> +}
> +
> +static void brcm_dma_sync_single_for_device(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
> +}
And sync_sg_*()? They might not be that commonly used by in-tree
drivers, but who knows what lurks beyond?
> +
> +static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
> + size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_resource
> + (dev, phys, size, dir, attrs));
> +}
> +
> +static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + return dma_addr == BRCMSTB_ERROR_CODE;
Huh? How do you know this will work correctly with every platform's
->map_page implementation (hint: it doesn't).
> +}
> +
> +static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
> +{
> +#if defined(CONFIG_MIPS)
> + return mips_dma_map_ops;
> +#elif defined(CONFIG_ARM)
> + return &arm_dma_ops;
> +#elif defined(CONFIG_ARM64)
> + /* swiotlb_dma_ops is a static var, so we get ahold
> + * of it by calling arch_setup_dma_ops(...).
> + */
> + arch_setup_dma_ops(dev, 0, 0, NULL, false);
> + return dev->dma_ops;
> +#endif
> + return 0;
> +}
As mentioned earlier, no. There are theoretical cases where it might not
be true, but in practice you can assume all PCI devices are going to get
the same DMA ops as their associated host controller (and that's still a
better assumption that what you have here), so you can just grab those
at the point you install the notifier.
> +
> +static void brcm_set_dma_ops(struct device *dev)
> +{
> + arch_dma_ops = brcm_get_arch_dma_ops(dev);
> + if (!arch_dma_ops)
> + return;
> +
> + /* Set all of the base operations; some will be overridden */
> + brcm_dma_ops = *arch_dma_ops;
> +
> + /* Insert the Brcm-specific override operations */
> + brcm_dma_ops.alloc = brcm_dma_alloc;
> + brcm_dma_ops.free = brcm_dma_free;
> + brcm_dma_ops.mmap = brcm_dma_mmap;
> + brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
> + brcm_dma_ops.map_page = brcm_dma_map_page;
> + brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
> + brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
> + brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
> + brcm_dma_ops.map_sg = brcm_dma_map_sg;
> + brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
> + if (arch_dma_ops->map_resource)
> + brcm_dma_ops.map_resource = brcm_dma_map_resource;
> + if (arch_dma_ops->unmap_resource)
> + brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
> + brcm_dma_ops.mapping_error = brcm_mapping_error;
> +
> + /* Use our brcm_dma_ops for this driver */
> + set_dma_ops(dev, &brcm_dma_ops);
> +}
Just have a static const set of ops like everyone else - you can handle
the conditionality of ->{map,unmap}_resource inside the brcm_* wrappers.
> +
> +static int brcmstb_platform_notifier(struct notifier_block *nb,
> + unsigned long event, void *__dev)
> +{
> + struct device *dev = __dev;
> +
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> +
> + brcm_set_dma_ops(dev);
> + return NOTIFY_OK;
> +}
> +
> +struct notifier_block brcmstb_platform_nb = {
> + .notifier_call = brcmstb_platform_notifier,
> +};
> +EXPORT_SYMBOL(brcmstb_platform_nb);
> diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
> index f4cd6e7..03c0da9 100644
> --- a/drivers/pci/host/pci-brcmstb.c
> +++ b/drivers/pci/host/pci-brcmstb.c
> @@ -343,6 +343,8 @@ struct brcm_pcie {
>
> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> +static struct of_pci_range *dma_ranges;
> +static int num_dma_ranges;
> static int num_memc;
> static DEFINE_MUTEX(brcm_pcie_lock);
>
> @@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> {
> mutex_lock(&brcm_pcie_lock);
> snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
> + if (list_empty(&brcm_pcie))
> + bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
> list_add_tail(&pcie->list, &brcm_pcie);
> mutex_unlock(&brcm_pcie_lock);
>
> @@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> tmp = list_entry(pos, struct brcm_pcie, list);
> if (tmp == pcie) {
> list_del(pos);
> - if (list_empty(&brcm_pcie))
> + if (list_empty(&brcm_pcie)) {
> + bus_unregister_notifier(&pci_bus_type,
> + &brcmstb_platform_nb);
> + kfree(dma_ranges);
> + dma_ranges = NULL;
> + num_dma_ranges = 0;
> num_memc = 0;
> + }
> break;
> }
> }
> @@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
> return 0;
> }
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> +
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
> + return addr - p->cpu_addr + p->pci_addr;
> +
> + return BRCMSTB_ERROR_CODE;
> +}
> +EXPORT_SYMBOL(brcm_to_pci);
AFAICS it doesn't make much sense for anyone outside this driver to ever
be calling these.
> +dma_addr_t brcm_to_cpu(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
> + return addr - p->pci_addr + p->cpu_addr;
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(brcm_to_cpu);
> +
> static u32 mdio_form_pkt(int port, int regad, int cmd)
> {
> u32 pkt = 0;
> @@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
> return 0;
> }
>
> +static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> + struct device_node *node)
> +{
> + const int na = 3, ns = 2;
> + int rlen;
> +
> + parser->node = node;
> + parser->pna = of_n_addr_cells(node);
> + parser->np = parser->pna + na + ns;
> +
> + parser->range = of_get_property(node, "dma-ranges", &rlen);
> + if (!parser->range)
> + return -ENOENT;
> +
> + parser->end = parser->range + rlen / sizeof(__be32);
> +
> + return 0;
> +}
Note that we've got a factored-out helper for this queued in -next
already - see here:
https://patchwork.kernel.org/patch/9927541/
> +
> +static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i, ret = 0;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + mutex_lock(&brcm_pcie_lock);
> + if (dma_ranges)
> + goto done;
> +
> + /* Parse dma-ranges property if present. If there are multiple
> + * PCI controllers, we only have to parse from one of them since
> + * the others will have an identical mapping.
> + */
> + if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
> + unsigned int max_ranges
> + = (parser.end - parser.range) / parser.np;
> +
> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
> + GFP_KERNEL);
> + if (!dma_ranges) {
> + ret = -ENOMEM;
> + goto done;
> + }
> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
> + i++)
> + num_dma_ranges++;
> + }
> +
> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
> + u64 size = brcmstb_memory_memc_size(i);
> +
> + if (size == (u64)-1) {
> + dev_err(pcie->dev, "cannot get memc%d size", i);
> + ret = -EINVAL;
> + goto done;
> + } else if (size) {
> + scb_size[i] = roundup_pow_of_two_64(size);
> + num_memc++;
> + } else {
> + break;
> + }
> + }
> +
> +done:
> + mutex_unlock(&brcm_pcie_lock);
> + return ret;
> +}
> +
> static void set_regulators(struct brcm_pcie *pcie, bool on)
> {
> struct list_head *pos;
> @@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
> */
> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>
> - /* Set simple configuration based on memory sizes
> - * only. We always start the viewport at address 0.
> - */
> - rc_bar2_offset = 0;
> + if (dma_ranges) {
> + /* The best-case scenario is to place the inbound
> + * region in the first 4GB of pci-space, as some
> + * legacy devices can only address 32bits.
> + * We would also like to put the MSI under 4GB
> + * as well, since some devices require a 32bit
> + * MSI target address.
> + */
> + if (total_mem_size <= 0xc0000000ULL &&
> + rc_bar2_size <= 0x100000000ULL) {
> + rc_bar2_offset = 0;
> + } else {
> + /* The system memory is 4GB or larger so we
> + * cannot start the inbound region at location
> + * 0 (since we have to allow some space for
> + * outbound memory @ 3GB). So instead we
> + * start it at the 1x multiple of its size
> + */
> + rc_bar2_offset = rc_bar2_size;
> + }
> +
> + } else {
> + /* Set simple configuration based on memory sizes
> + * only. We always start the viewport at address 0,
> + * and set the MSI target address accordingly.
> + */
> + rc_bar2_offset = 0;
> + }
>
> tmp = lower_32_bits(rc_bar2_offset);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> @@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
> - pr_err("cannot yet handle dma-ranges\n");
> - return -EINVAL;
> - }
> -
> data = of_id->data;
> pcie->reg_offsets = data->offsets;
> pcie->reg_field_info = data->reg_field_info;
> @@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = brcm_parse_dma_ranges(pcie);
> + if (ret)
> + return ret;
> +
> ret = clk_prepare_enable(pcie->clk);
> if (ret) {
> dev_err(&pdev->dev, "could not enable clock\n");
> diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
> index 86f9cd1..4851be8 100644
> --- a/drivers/pci/host/pci-brcmstb.h
> +++ b/drivers/pci/host/pci-brcmstb.h
> @@ -21,6 +21,13 @@
> /* Broadcom PCIE Offsets */
> #define PCIE_INTR2_CPU_BASE 0x4300
>
> +dma_addr_t brcm_to_pci(dma_addr_t addr);
> +dma_addr_t brcm_to_cpu(dma_addr_t addr);
> +
> +extern struct notifier_block brcmstb_platform_nb;
It seems a bit weird to have the notifier code split across two
compilation units in the way which requires this - it seems more
reasonable to have it all together on one side or the other, with the
common interface being either the callback for setting the ops or a
function for installing the notifier, depending on where things fall.
Robin.
> +
> +#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
> +
> #if defined(CONFIG_MIPS)
> /* Broadcom MIPs HW implicitly does the swapping if necessary */
> #define bcm_readl(a) __raw_readl(a)
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-12 18:15 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 18:15 UTC (permalink / raw)
To: Robin Murphy
Cc: linux-kernel, Mark Rutland, linux-mips, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Thu, Oct 12, 2017 at 1:06 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
>> However, that variable is defined as static. Instead, we use
>> arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
>> we also want our driver to be a separate module, we need to
>> export this function.
>
> NAK. Retrieve the platform-assigned ops from the device via
> get_dma_ops() and stash them in your drvdata or wherever before you
> replace them. Don't go poking around arch code internals directly from a
> driver.
Will fix (and drop the commit).
>
> Robin.
>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> arch/arm64/mm/dma-mapping.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 614af88..dae572f 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> }
>> #endif
>> }
>> +EXPORT_SYMBOL(arch_setup_dma_ops);
>>
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-12 18:15 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 18:15 UTC (permalink / raw)
To: Robin Murphy
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-mips-6z/3iImG2C8G8FEW9MqTrA, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thu, Oct 12, 2017 at 1:06 PM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
>> However, that variable is defined as static. Instead, we use
>> arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
>> we also want our driver to be a separate module, we need to
>> export this function.
>
> NAK. Retrieve the platform-assigned ops from the device via
> get_dma_ops() and stash them in your drvdata or wherever before you
> replace them. Don't go poking around arch code internals directly from a
> driver.
Will fix (and drop the commit).
>
> Robin.
>
>> Signed-off-by: Jim Quinlan <jim2101024-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> arch/arm64/mm/dma-mapping.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 614af88..dae572f 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> }
>> #endif
>> }
>> +EXPORT_SYMBOL(arch_setup_dma_ops);
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-12 18:15 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 18:15 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel
On Thu, Oct 12, 2017 at 1:06 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
>> However, that variable is defined as static. Instead, we use
>> arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
>> we also want our driver to be a separate module, we need to
>> export this function.
>
> NAK. Retrieve the platform-assigned ops from the device via
> get_dma_ops() and stash them in your drvdata or wherever before you
> replace them. Don't go poking around arch code internals directly from a
> driver.
Will fix (and drop the commit).
>
> Robin.
>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> arch/arm64/mm/dma-mapping.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 614af88..dae572f 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> }
>> #endif
>> }
>> +EXPORT_SYMBOL(arch_setup_dma_ops);
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops
@ 2017-10-12 18:15 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 18:15 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 12, 2017 at 1:06 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The BrcmSTB driver needs to get ahold of a pointer to swiotlb_dma_ops.
>> However, that variable is defined as static. Instead, we use
>> arch_setup_dma_ops() to get the pointer to swiotlb_dma_ops. Since
>> we also want our driver to be a separate module, we need to
>> export this function.
>
> NAK. Retrieve the platform-assigned ops from the device via
> get_dma_ops() and stash them in your drvdata or wherever before you
> replace them. Don't go poking around arch code internals directly from a
> driver.
Will fix (and drop the commit).
>
> Robin.
>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> arch/arm64/mm/dma-mapping.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 614af88..dae572f 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -936,3 +936,4 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>> }
>> #endif
>> }
>> +EXPORT_SYMBOL(arch_setup_dma_ops);
>>
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-12 18:04 ` Robin Murphy
(?)
@ 2017-10-12 21:43 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 21:43 UTC (permalink / raw)
To: Robin Murphy
Cc: linux-kernel, Mark Rutland, linux-mips, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel,
Christoph Hellwig, Marek Szyprowski, iommu
On Thu, Oct 12, 2017 at 2:04 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> [+DMA API maintainers]
>
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The Broadcom STB PCIe host controller is intimately related to the
>> memory subsystem. This close relationship adds complexity to how cpu
>> system memory is mapped to PCIe memory. Ideally, this mapping is an
>> identity mapping, or an identity mapping off by a constant. Not so in
>> this case.
>>
>> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
>> of system memory. Here is how the PCIe controller maps the
>> system memory to PCIe memory:
>>
>> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
>> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
>> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
>> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
>> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> Although there are some "gaps" that can be added between the
>> individual mappings by software, the permutation of memory regions for
>> the most part is fixed by HW. The solution of having something close
>> to an identity mapping is not possible.
>>
>> The idea behind this HW design is that the same PCIe module can
>> act as an RC or EP, and if it acts as an EP it concatenates all
>> of system memory into a BAR so anything can be accessed. Unfortunately,
>> when the PCIe block is in the role of an RC it also presents this
>> "BAR" to downstream PCIe devices, rather than offering an identity map
>> between its system memory and PCIe space.
>>
>> Suppose that an endpoint driver allocs some DMA memory. Suppose this
>> memory is located at 0x6000_0000, which is in the middle of memc1-a.
>> The driver wants a dma_addr_t value that it can pass on to the EP to
>> use. Without doing any custom mapping, the EP will use this value for
>> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
>> won't work; the device needs a dma_addr_t that reflects the PCIe space
>> address, namely 0xa000_0000.
>>
>> So, essentially the solution to this problem must modify the
>> dma_addr_t returned by the DMA routines routines. There are two
>> ways (I know of) of doing this:
>>
>> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
>> that are used by the dma_ops routines. This is the approach of
>>
>> arch/mips/cavium-octeon/dma-octeon.c
>>
>> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
>> as static inline functions.
>>
>> (b) Subscribe to a notifier that notifies when a device is added to a
>> bus. When this happens, set_dma_ops() can be called for the device.
>> This method is mentioned in:
>>
>> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>>
>> where it says as a comment
>>
>> "In case if platform code need to use own special DMA
>> configuration, it can use Platform bus notifier and
>> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
>> configuration."
>>
>> Solution (b) is what this commit does. It uses the native dma_ops
>> as the base set of operations, and overrides some with custom
>> functions that translate the address and then call the base
>> function.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> drivers/pci/host/Makefile | 3 +-
>> drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
>> drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
>> drivers/pci/host/pci-brcmstb.h | 7 ++
>> 4 files changed, 368 insertions(+), 11 deletions(-)
>> create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
>>
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index 4398d2c..c283321 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
>> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
>> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>> obj-$(CONFIG_VMD) += vmd.o
>> -obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
>> +obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>> +brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>>
>> # The following drivers are for devices that use the generic ACPI
>> # pci_root.c driver but don't support standard ECAM config access.
>> diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
>> new file mode 100644
>> index 0000000..81ce122
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-brcmstb-dma.c
>> @@ -0,0 +1,219 @@
>> +/*
>> + * Copyright (C) 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +#include <linux/dma-mapping.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of_address.h>
>> +#include <linux/pci.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/smp.h>
>> +
>> +#include "pci-brcmstb.h"
>> +
>> +static const struct dma_map_ops *arch_dma_ops;
>> +static struct dma_map_ops brcm_dma_ops;
>> +
>> +static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
>> + gfp_t gfp, unsigned long attrs)
>> +{
>> + void *ret;
>> +
>> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
>> + if (ret)
>> + *handle = brcm_to_pci(*handle);
>> + return ret;
>> +}
>> +
>> +static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
>> + dma_addr_t handle, unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
>> +}
>> +
>> +static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
>> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
>> + unsigned long attrs)
>> +{
>> + dma_addr = brcm_to_cpu(dma_addr);
>> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
>> +}
>> +
>> +static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
>> + void *cpu_addr, dma_addr_t handle, size_t size,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
>> + attrs);
>> +}
>> +
>> +static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
>> + dir, attrs));
>> +}
>> +
>> +static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
>> +}
>> +
>> +static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
>> + int nents, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + int ret, i;
>> + struct scatterlist *sg;
>> +
>> + ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
>> + /* The ARM and MIPS implementations of map_sg and unmap_sg
>> + * make calls to ops->map_page(), which we already intercept.
>> + * The ARM64 does not, so we must iterate through the SG list
>> + * and convert each dma_address to one that is compatible
>> + * with our PCI RC implementation.
>> + */
>
> That's a pretty fragile assumption given that arch code is free to
> change, and anyone doing so is unlikely to be aware of your driver.
> You'd be better off implementing these in terms of {brcm_dma_}map_page
> directly.
>
Will fix.
>> + if (IS_ENABLED(CONFIG_ARM64))
>> + for_each_sg(sgl, sg, ret, i)
>> + sg->dma_address = brcm_to_pci(sg->dma_address);
>> + return ret;
>> +}
>> +
>> +static void brcm_dma_unmap_sg(struct device *dev,
>> + struct scatterlist *sgl, int nents,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + int i;
>> + struct scatterlist *sg;
>> +
>> + /* The ARM and MIPS implementations of map_sg and unmap_sg
>> + * make calls to ops->map_page(), which we already intercept.
>> + * The ARM64 does not, so we must iterate through the SG list
>> + * and convert each dma_address to one that is compatible
>> + * with our PCI RC implementation.
>> + */
>> + if (IS_ENABLED(CONFIG_ARM64))
>> + for_each_sg(sgl, sg, nents, i)
>> + sg->dma_address = brcm_to_cpu(sg->dma_address);
>> + arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
>> +}
>> +
>> +static void brcm_dma_sync_single_for_cpu(struct device *dev,
>> + dma_addr_t handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
>> +}
>> +
>> +static void brcm_dma_sync_single_for_device(struct device *dev,
>> + dma_addr_t handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
>> +}
>
> And sync_sg_*()? They might not be that commonly used by in-tree
> drivers, but who knows what lurks beyond?
>
Will fix.
>> +
>> +static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
>> + size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return brcm_to_pci(arch_dma_ops->map_resource
>> + (dev, phys, size, dir, attrs));
>> +}
>> +
>> +static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
>> +}
>> +
>> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
>> +{
>> + return dma_addr == BRCMSTB_ERROR_CODE;
>
> Huh? How do you know this will work correctly with every platform's
> ->map_page implementation (hint: it doesn't).
>
Will fix.
>> +}
>> +
>> +static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
>> +{
>> +#if defined(CONFIG_MIPS)
>> + return mips_dma_map_ops;
>> +#elif defined(CONFIG_ARM)
>> + return &arm_dma_ops;
>> +#elif defined(CONFIG_ARM64)
>> + /* swiotlb_dma_ops is a static var, so we get ahold
>> + * of it by calling arch_setup_dma_ops(...).
>> + */
>> + arch_setup_dma_ops(dev, 0, 0, NULL, false);
>> + return dev->dma_ops;
>> +#endif
>> + return 0;
>> +}
>
> As mentioned earlier, no. There are theoretical cases where it might not
> be true, but in practice you can assume all PCI devices are going to get
> the same DMA ops as their associated host controller (and that's still a
> better assumption that what you have here), so you can just grab those
> at the point you install the notifier.
>
Yes, for some reason I did not know of get_dma_ops() and I wrote my
own, poorly. Will fix.
>> +
>> +static void brcm_set_dma_ops(struct device *dev)
>> +{
>> + arch_dma_ops = brcm_get_arch_dma_ops(dev);
>> + if (!arch_dma_ops)
>> + return;
>> +
>> + /* Set all of the base operations; some will be overridden */
>> + brcm_dma_ops = *arch_dma_ops;
>> +
>> + /* Insert the Brcm-specific override operations */
>> + brcm_dma_ops.alloc = brcm_dma_alloc;
>> + brcm_dma_ops.free = brcm_dma_free;
>> + brcm_dma_ops.mmap = brcm_dma_mmap;
>> + brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
>> + brcm_dma_ops.map_page = brcm_dma_map_page;
>> + brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
>> + brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
>> + brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
>> + brcm_dma_ops.map_sg = brcm_dma_map_sg;
>> + brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
>> + if (arch_dma_ops->map_resource)
>> + brcm_dma_ops.map_resource = brcm_dma_map_resource;
>> + if (arch_dma_ops->unmap_resource)
>> + brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
>> + brcm_dma_ops.mapping_error = brcm_mapping_error;
>> +
>> + /* Use our brcm_dma_ops for this driver */
>> + set_dma_ops(dev, &brcm_dma_ops);
>> +}
>
> Just have a static const set of ops like everyone else - you can handle
> the conditionality of ->{map,unmap}_resource inside the brcm_* wrappers.
>
Will fix.
>> +
>> +static int brcmstb_platform_notifier(struct notifier_block *nb,
>> + unsigned long event, void *__dev)
>> +{
>> + struct device *dev = __dev;
>> +
>> + if (event != BUS_NOTIFY_ADD_DEVICE)
>> + return NOTIFY_DONE;
>> +
>> + brcm_set_dma_ops(dev);
>> + return NOTIFY_OK;
>> +}
>> +
>> +struct notifier_block brcmstb_platform_nb = {
>> + .notifier_call = brcmstb_platform_notifier,
>> +};
>> +EXPORT_SYMBOL(brcmstb_platform_nb);
>> diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
>> index f4cd6e7..03c0da9 100644
>> --- a/drivers/pci/host/pci-brcmstb.c
>> +++ b/drivers/pci/host/pci-brcmstb.c
>> @@ -343,6 +343,8 @@ struct brcm_pcie {
>>
>> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
>> static phys_addr_t scb_size[BRCM_MAX_SCB];
>> +static struct of_pci_range *dma_ranges;
>> +static int num_dma_ranges;
>> static int num_memc;
>> static DEFINE_MUTEX(brcm_pcie_lock);
>>
>> @@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
>> {
>> mutex_lock(&brcm_pcie_lock);
>> snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
>> + if (list_empty(&brcm_pcie))
>> + bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
>> list_add_tail(&pcie->list, &brcm_pcie);
>> mutex_unlock(&brcm_pcie_lock);
>>
>> @@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
>> tmp = list_entry(pos, struct brcm_pcie, list);
>> if (tmp == pcie) {
>> list_del(pos);
>> - if (list_empty(&brcm_pcie))
>> + if (list_empty(&brcm_pcie)) {
>> + bus_unregister_notifier(&pci_bus_type,
>> + &brcmstb_platform_nb);
>> + kfree(dma_ranges);
>> + dma_ranges = NULL;
>> + num_dma_ranges = 0;
>> num_memc = 0;
>> + }
>> break;
>> }
>> }
>> @@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
>> return 0;
>> }
>>
>> +dma_addr_t brcm_to_pci(dma_addr_t addr)
>> +{
>> + struct of_pci_range *p;
>> +
>> + if (!num_dma_ranges)
>> + return addr;
>> +
>> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
>> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
>> + return addr - p->cpu_addr + p->pci_addr;
>> +
>> + return BRCMSTB_ERROR_CODE;
>> +}
>> +EXPORT_SYMBOL(brcm_to_pci);
>
> AFAICS it doesn't make much sense for anyone outside this driver to ever
> be calling these.
>
Will fix.
>> +dma_addr_t brcm_to_cpu(dma_addr_t addr)
>> +{
>> + struct of_pci_range *p;
>> +
>> + if (!num_dma_ranges)
>> + return addr;
>> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
>> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
>> + return addr - p->pci_addr + p->cpu_addr;
>> +
>> + return addr;
>> +}
>> +EXPORT_SYMBOL(brcm_to_cpu);
>> +
>> static u32 mdio_form_pkt(int port, int regad, int cmd)
>> {
>> u32 pkt = 0;
>> @@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
>> return 0;
>> }
>>
>> +static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>> + struct device_node *node)
>> +{
>> + const int na = 3, ns = 2;
>> + int rlen;
>> +
>> + parser->node = node;
>> + parser->pna = of_n_addr_cells(node);
>> + parser->np = parser->pna + na + ns;
>> +
>> + parser->range = of_get_property(node, "dma-ranges", &rlen);
>> + if (!parser->range)
>> + return -ENOENT;
>> +
>> + parser->end = parser->range + rlen / sizeof(__be32);
>> +
>> + return 0;
>> +}
>
> Note that we've got a factored-out helper for this queued in -next
> already - see here:
>
> https://patchwork.kernel.org/patch/9927541/
>
I will submit a change when it gets merged.
>> +
>> +static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
>> +{
>> + int i, ret = 0;
>> + struct of_pci_range_parser parser;
>> + struct device_node *dn = pcie->dn;
>> +
>> + mutex_lock(&brcm_pcie_lock);
>> + if (dma_ranges)
>> + goto done;
>> +
>> + /* Parse dma-ranges property if present. If there are multiple
>> + * PCI controllers, we only have to parse from one of them since
>> + * the others will have an identical mapping.
>> + */
>> + if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
>> + unsigned int max_ranges
>> + = (parser.end - parser.range) / parser.np;
>> +
>> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
>> + GFP_KERNEL);
>> + if (!dma_ranges) {
>> + ret = -ENOMEM;
>> + goto done;
>> + }
>> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
>> + i++)
>> + num_dma_ranges++;
>> + }
>> +
>> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
>> + u64 size = brcmstb_memory_memc_size(i);
>> +
>> + if (size == (u64)-1) {
>> + dev_err(pcie->dev, "cannot get memc%d size", i);
>> + ret = -EINVAL;
>> + goto done;
>> + } else if (size) {
>> + scb_size[i] = roundup_pow_of_two_64(size);
>> + num_memc++;
>> + } else {
>> + break;
>> + }
>> + }
>> +
>> +done:
>> + mutex_unlock(&brcm_pcie_lock);
>> + return ret;
>> +}
>> +
>> static void set_regulators(struct brcm_pcie *pcie, bool on)
>> {
>> struct list_head *pos;
>> @@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
>> */
>> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>>
>> - /* Set simple configuration based on memory sizes
>> - * only. We always start the viewport at address 0.
>> - */
>> - rc_bar2_offset = 0;
>> + if (dma_ranges) {
>> + /* The best-case scenario is to place the inbound
>> + * region in the first 4GB of pci-space, as some
>> + * legacy devices can only address 32bits.
>> + * We would also like to put the MSI under 4GB
>> + * as well, since some devices require a 32bit
>> + * MSI target address.
>> + */
>> + if (total_mem_size <= 0xc0000000ULL &&
>> + rc_bar2_size <= 0x100000000ULL) {
>> + rc_bar2_offset = 0;
>> + } else {
>> + /* The system memory is 4GB or larger so we
>> + * cannot start the inbound region at location
>> + * 0 (since we have to allow some space for
>> + * outbound memory @ 3GB). So instead we
>> + * start it at the 1x multiple of its size
>> + */
>> + rc_bar2_offset = rc_bar2_size;
>> + }
>> +
>> + } else {
>> + /* Set simple configuration based on memory sizes
>> + * only. We always start the viewport at address 0,
>> + * and set the MSI target address accordingly.
>> + */
>> + rc_bar2_offset = 0;
>> + }
>>
>> tmp = lower_32_bits(rc_bar2_offset);
>> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
>> @@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>> return -EINVAL;
>> }
>>
>> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
>> - pr_err("cannot yet handle dma-ranges\n");
>> - return -EINVAL;
>> - }
>> -
>> data = of_id->data;
>> pcie->reg_offsets = data->offsets;
>> pcie->reg_field_info = data->reg_field_info;
>> @@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> + ret = brcm_parse_dma_ranges(pcie);
>> + if (ret)
>> + return ret;
>> +
>> ret = clk_prepare_enable(pcie->clk);
>> if (ret) {
>> dev_err(&pdev->dev, "could not enable clock\n");
>> diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
>> index 86f9cd1..4851be8 100644
>> --- a/drivers/pci/host/pci-brcmstb.h
>> +++ b/drivers/pci/host/pci-brcmstb.h
>> @@ -21,6 +21,13 @@
>> /* Broadcom PCIE Offsets */
>> #define PCIE_INTR2_CPU_BASE 0x4300
>>
>> +dma_addr_t brcm_to_pci(dma_addr_t addr);
>> +dma_addr_t brcm_to_cpu(dma_addr_t addr);
>> +
>> +extern struct notifier_block brcmstb_platform_nb;
>
> It seems a bit weird to have the notifier code split across two
> compilation units in the way which requires this - it seems more
> reasonable to have it all together on one side or the other, with the
> common interface being either the callback for setting the ops or a
> function for installing the notifier, depending on where things fall.
Okay, I'll try to rework this.
Thanks Robin,
Jim
>
> Robin.
>
>> +
>> +#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
>> +
>> #if defined(CONFIG_MIPS)
>> /* Broadcom MIPs HW implicitly does the swapping if necessary */
>> #define bcm_readl(a) __raw_readl(a)
>>
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-12 21:43 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 21:43 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
On Thu, Oct 12, 2017 at 2:04 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> [+DMA API maintainers]
>
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The Broadcom STB PCIe host controller is intimately related to the
>> memory subsystem. This close relationship adds complexity to how cpu
>> system memory is mapped to PCIe memory. Ideally, this mapping is an
>> identity mapping, or an identity mapping off by a constant. Not so in
>> this case.
>>
>> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
>> of system memory. Here is how the PCIe controller maps the
>> system memory to PCIe memory:
>>
>> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
>> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
>> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
>> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
>> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> Although there are some "gaps" that can be added between the
>> individual mappings by software, the permutation of memory regions for
>> the most part is fixed by HW. The solution of having something close
>> to an identity mapping is not possible.
>>
>> The idea behind this HW design is that the same PCIe module can
>> act as an RC or EP, and if it acts as an EP it concatenates all
>> of system memory into a BAR so anything can be accessed. Unfortunately,
>> when the PCIe block is in the role of an RC it also presents this
>> "BAR" to downstream PCIe devices, rather than offering an identity map
>> between its system memory and PCIe space.
>>
>> Suppose that an endpoint driver allocs some DMA memory. Suppose this
>> memory is located at 0x6000_0000, which is in the middle of memc1-a.
>> The driver wants a dma_addr_t value that it can pass on to the EP to
>> use. Without doing any custom mapping, the EP will use this value for
>> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
>> won't work; the device needs a dma_addr_t that reflects the PCIe space
>> address, namely 0xa000_0000.
>>
>> So, essentially the solution to this problem must modify the
>> dma_addr_t returned by the DMA routines routines. There are two
>> ways (I know of) of doing this:
>>
>> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
>> that are used by the dma_ops routines. This is the approach of
>>
>> arch/mips/cavium-octeon/dma-octeon.c
>>
>> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
>> as static inline functions.
>>
>> (b) Subscribe to a notifier that notifies when a device is added to a
>> bus. When this happens, set_dma_ops() can be called for the device.
>> This method is mentioned in:
>>
>> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>>
>> where it says as a comment
>>
>> "In case if platform code need to use own special DMA
>> configuration, it can use Platform bus notifier and
>> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
>> configuration."
>>
>> Solution (b) is what this commit does. It uses the native dma_ops
>> as the base set of operations, and overrides some with custom
>> functions that translate the address and then call the base
>> function.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> drivers/pci/host/Makefile | 3 +-
>> drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
>> drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
>> drivers/pci/host/pci-brcmstb.h | 7 ++
>> 4 files changed, 368 insertions(+), 11 deletions(-)
>> create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
>>
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index 4398d2c..c283321 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
>> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
>> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>> obj-$(CONFIG_VMD) += vmd.o
>> -obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
>> +obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>> +brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>>
>> # The following drivers are for devices that use the generic ACPI
>> # pci_root.c driver but don't support standard ECAM config access.
>> diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
>> new file mode 100644
>> index 0000000..81ce122
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-brcmstb-dma.c
>> @@ -0,0 +1,219 @@
>> +/*
>> + * Copyright (C) 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +#include <linux/dma-mapping.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of_address.h>
>> +#include <linux/pci.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/smp.h>
>> +
>> +#include "pci-brcmstb.h"
>> +
>> +static const struct dma_map_ops *arch_dma_ops;
>> +static struct dma_map_ops brcm_dma_ops;
>> +
>> +static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
>> + gfp_t gfp, unsigned long attrs)
>> +{
>> + void *ret;
>> +
>> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
>> + if (ret)
>> + *handle = brcm_to_pci(*handle);
>> + return ret;
>> +}
>> +
>> +static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
>> + dma_addr_t handle, unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
>> +}
>> +
>> +static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
>> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
>> + unsigned long attrs)
>> +{
>> + dma_addr = brcm_to_cpu(dma_addr);
>> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
>> +}
>> +
>> +static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
>> + void *cpu_addr, dma_addr_t handle, size_t size,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
>> + attrs);
>> +}
>> +
>> +static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
>> + dir, attrs));
>> +}
>> +
>> +static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
>> +}
>> +
>> +static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
>> + int nents, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + int ret, i;
>> + struct scatterlist *sg;
>> +
>> + ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
>> + /* The ARM and MIPS implementations of map_sg and unmap_sg
>> + * make calls to ops->map_page(), which we already intercept.
>> + * The ARM64 does not, so we must iterate through the SG list
>> + * and convert each dma_address to one that is compatible
>> + * with our PCI RC implementation.
>> + */
>
> That's a pretty fragile assumption given that arch code is free to
> change, and anyone doing so is unlikely to be aware of your driver.
> You'd be better off implementing these in terms of {brcm_dma_}map_page
> directly.
>
Will fix.
>> + if (IS_ENABLED(CONFIG_ARM64))
>> + for_each_sg(sgl, sg, ret, i)
>> + sg->dma_address = brcm_to_pci(sg->dma_address);
>> + return ret;
>> +}
>> +
>> +static void brcm_dma_unmap_sg(struct device *dev,
>> + struct scatterlist *sgl, int nents,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + int i;
>> + struct scatterlist *sg;
>> +
>> + /* The ARM and MIPS implementations of map_sg and unmap_sg
>> + * make calls to ops->map_page(), which we already intercept.
>> + * The ARM64 does not, so we must iterate through the SG list
>> + * and convert each dma_address to one that is compatible
>> + * with our PCI RC implementation.
>> + */
>> + if (IS_ENABLED(CONFIG_ARM64))
>> + for_each_sg(sgl, sg, nents, i)
>> + sg->dma_address = brcm_to_cpu(sg->dma_address);
>> + arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
>> +}
>> +
>> +static void brcm_dma_sync_single_for_cpu(struct device *dev,
>> + dma_addr_t handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
>> +}
>> +
>> +static void brcm_dma_sync_single_for_device(struct device *dev,
>> + dma_addr_t handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
>> +}
>
> And sync_sg_*()? They might not be that commonly used by in-tree
> drivers, but who knows what lurks beyond?
>
Will fix.
>> +
>> +static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
>> + size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return brcm_to_pci(arch_dma_ops->map_resource
>> + (dev, phys, size, dir, attrs));
>> +}
>> +
>> +static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
>> +}
>> +
>> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
>> +{
>> + return dma_addr == BRCMSTB_ERROR_CODE;
>
> Huh? How do you know this will work correctly with every platform's
> ->map_page implementation (hint: it doesn't).
>
Will fix.
>> +}
>> +
>> +static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
>> +{
>> +#if defined(CONFIG_MIPS)
>> + return mips_dma_map_ops;
>> +#elif defined(CONFIG_ARM)
>> + return &arm_dma_ops;
>> +#elif defined(CONFIG_ARM64)
>> + /* swiotlb_dma_ops is a static var, so we get ahold
>> + * of it by calling arch_setup_dma_ops(...).
>> + */
>> + arch_setup_dma_ops(dev, 0, 0, NULL, false);
>> + return dev->dma_ops;
>> +#endif
>> + return 0;
>> +}
>
> As mentioned earlier, no. There are theoretical cases where it might not
> be true, but in practice you can assume all PCI devices are going to get
> the same DMA ops as their associated host controller (and that's still a
> better assumption that what you have here), so you can just grab those
> at the point you install the notifier.
>
Yes, for some reason I did not know of get_dma_ops() and I wrote my
own, poorly. Will fix.
>> +
>> +static void brcm_set_dma_ops(struct device *dev)
>> +{
>> + arch_dma_ops = brcm_get_arch_dma_ops(dev);
>> + if (!arch_dma_ops)
>> + return;
>> +
>> + /* Set all of the base operations; some will be overridden */
>> + brcm_dma_ops = *arch_dma_ops;
>> +
>> + /* Insert the Brcm-specific override operations */
>> + brcm_dma_ops.alloc = brcm_dma_alloc;
>> + brcm_dma_ops.free = brcm_dma_free;
>> + brcm_dma_ops.mmap = brcm_dma_mmap;
>> + brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
>> + brcm_dma_ops.map_page = brcm_dma_map_page;
>> + brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
>> + brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
>> + brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
>> + brcm_dma_ops.map_sg = brcm_dma_map_sg;
>> + brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
>> + if (arch_dma_ops->map_resource)
>> + brcm_dma_ops.map_resource = brcm_dma_map_resource;
>> + if (arch_dma_ops->unmap_resource)
>> + brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
>> + brcm_dma_ops.mapping_error = brcm_mapping_error;
>> +
>> + /* Use our brcm_dma_ops for this driver */
>> + set_dma_ops(dev, &brcm_dma_ops);
>> +}
>
> Just have a static const set of ops like everyone else - you can handle
> the conditionality of ->{map,unmap}_resource inside the brcm_* wrappers.
>
Will fix.
>> +
>> +static int brcmstb_platform_notifier(struct notifier_block *nb,
>> + unsigned long event, void *__dev)
>> +{
>> + struct device *dev = __dev;
>> +
>> + if (event != BUS_NOTIFY_ADD_DEVICE)
>> + return NOTIFY_DONE;
>> +
>> + brcm_set_dma_ops(dev);
>> + return NOTIFY_OK;
>> +}
>> +
>> +struct notifier_block brcmstb_platform_nb = {
>> + .notifier_call = brcmstb_platform_notifier,
>> +};
>> +EXPORT_SYMBOL(brcmstb_platform_nb);
>> diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
>> index f4cd6e7..03c0da9 100644
>> --- a/drivers/pci/host/pci-brcmstb.c
>> +++ b/drivers/pci/host/pci-brcmstb.c
>> @@ -343,6 +343,8 @@ struct brcm_pcie {
>>
>> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
>> static phys_addr_t scb_size[BRCM_MAX_SCB];
>> +static struct of_pci_range *dma_ranges;
>> +static int num_dma_ranges;
>> static int num_memc;
>> static DEFINE_MUTEX(brcm_pcie_lock);
>>
>> @@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
>> {
>> mutex_lock(&brcm_pcie_lock);
>> snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
>> + if (list_empty(&brcm_pcie))
>> + bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
>> list_add_tail(&pcie->list, &brcm_pcie);
>> mutex_unlock(&brcm_pcie_lock);
>>
>> @@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
>> tmp = list_entry(pos, struct brcm_pcie, list);
>> if (tmp == pcie) {
>> list_del(pos);
>> - if (list_empty(&brcm_pcie))
>> + if (list_empty(&brcm_pcie)) {
>> + bus_unregister_notifier(&pci_bus_type,
>> + &brcmstb_platform_nb);
>> + kfree(dma_ranges);
>> + dma_ranges = NULL;
>> + num_dma_ranges = 0;
>> num_memc = 0;
>> + }
>> break;
>> }
>> }
>> @@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
>> return 0;
>> }
>>
>> +dma_addr_t brcm_to_pci(dma_addr_t addr)
>> +{
>> + struct of_pci_range *p;
>> +
>> + if (!num_dma_ranges)
>> + return addr;
>> +
>> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
>> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
>> + return addr - p->cpu_addr + p->pci_addr;
>> +
>> + return BRCMSTB_ERROR_CODE;
>> +}
>> +EXPORT_SYMBOL(brcm_to_pci);
>
> AFAICS it doesn't make much sense for anyone outside this driver to ever
> be calling these.
>
Will fix.
>> +dma_addr_t brcm_to_cpu(dma_addr_t addr)
>> +{
>> + struct of_pci_range *p;
>> +
>> + if (!num_dma_ranges)
>> + return addr;
>> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
>> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
>> + return addr - p->pci_addr + p->cpu_addr;
>> +
>> + return addr;
>> +}
>> +EXPORT_SYMBOL(brcm_to_cpu);
>> +
>> static u32 mdio_form_pkt(int port, int regad, int cmd)
>> {
>> u32 pkt = 0;
>> @@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
>> return 0;
>> }
>>
>> +static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>> + struct device_node *node)
>> +{
>> + const int na = 3, ns = 2;
>> + int rlen;
>> +
>> + parser->node = node;
>> + parser->pna = of_n_addr_cells(node);
>> + parser->np = parser->pna + na + ns;
>> +
>> + parser->range = of_get_property(node, "dma-ranges", &rlen);
>> + if (!parser->range)
>> + return -ENOENT;
>> +
>> + parser->end = parser->range + rlen / sizeof(__be32);
>> +
>> + return 0;
>> +}
>
> Note that we've got a factored-out helper for this queued in -next
> already - see here:
>
> https://patchwork.kernel.org/patch/9927541/
>
I will submit a change when it gets merged.
>> +
>> +static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
>> +{
>> + int i, ret = 0;
>> + struct of_pci_range_parser parser;
>> + struct device_node *dn = pcie->dn;
>> +
>> + mutex_lock(&brcm_pcie_lock);
>> + if (dma_ranges)
>> + goto done;
>> +
>> + /* Parse dma-ranges property if present. If there are multiple
>> + * PCI controllers, we only have to parse from one of them since
>> + * the others will have an identical mapping.
>> + */
>> + if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
>> + unsigned int max_ranges
>> + = (parser.end - parser.range) / parser.np;
>> +
>> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
>> + GFP_KERNEL);
>> + if (!dma_ranges) {
>> + ret = -ENOMEM;
>> + goto done;
>> + }
>> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
>> + i++)
>> + num_dma_ranges++;
>> + }
>> +
>> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
>> + u64 size = brcmstb_memory_memc_size(i);
>> +
>> + if (size == (u64)-1) {
>> + dev_err(pcie->dev, "cannot get memc%d size", i);
>> + ret = -EINVAL;
>> + goto done;
>> + } else if (size) {
>> + scb_size[i] = roundup_pow_of_two_64(size);
>> + num_memc++;
>> + } else {
>> + break;
>> + }
>> + }
>> +
>> +done:
>> + mutex_unlock(&brcm_pcie_lock);
>> + return ret;
>> +}
>> +
>> static void set_regulators(struct brcm_pcie *pcie, bool on)
>> {
>> struct list_head *pos;
>> @@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
>> */
>> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>>
>> - /* Set simple configuration based on memory sizes
>> - * only. We always start the viewport at address 0.
>> - */
>> - rc_bar2_offset = 0;
>> + if (dma_ranges) {
>> + /* The best-case scenario is to place the inbound
>> + * region in the first 4GB of pci-space, as some
>> + * legacy devices can only address 32bits.
>> + * We would also like to put the MSI under 4GB
>> + * as well, since some devices require a 32bit
>> + * MSI target address.
>> + */
>> + if (total_mem_size <= 0xc0000000ULL &&
>> + rc_bar2_size <= 0x100000000ULL) {
>> + rc_bar2_offset = 0;
>> + } else {
>> + /* The system memory is 4GB or larger so we
>> + * cannot start the inbound region at location
>> + * 0 (since we have to allow some space for
>> + * outbound memory @ 3GB). So instead we
>> + * start it at the 1x multiple of its size
>> + */
>> + rc_bar2_offset = rc_bar2_size;
>> + }
>> +
>> + } else {
>> + /* Set simple configuration based on memory sizes
>> + * only. We always start the viewport at address 0,
>> + * and set the MSI target address accordingly.
>> + */
>> + rc_bar2_offset = 0;
>> + }
>>
>> tmp = lower_32_bits(rc_bar2_offset);
>> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
>> @@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>> return -EINVAL;
>> }
>>
>> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
>> - pr_err("cannot yet handle dma-ranges\n");
>> - return -EINVAL;
>> - }
>> -
>> data = of_id->data;
>> pcie->reg_offsets = data->offsets;
>> pcie->reg_field_info = data->reg_field_info;
>> @@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> + ret = brcm_parse_dma_ranges(pcie);
>> + if (ret)
>> + return ret;
>> +
>> ret = clk_prepare_enable(pcie->clk);
>> if (ret) {
>> dev_err(&pdev->dev, "could not enable clock\n");
>> diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
>> index 86f9cd1..4851be8 100644
>> --- a/drivers/pci/host/pci-brcmstb.h
>> +++ b/drivers/pci/host/pci-brcmstb.h
>> @@ -21,6 +21,13 @@
>> /* Broadcom PCIE Offsets */
>> #define PCIE_INTR2_CPU_BASE 0x4300
>>
>> +dma_addr_t brcm_to_pci(dma_addr_t addr);
>> +dma_addr_t brcm_to_cpu(dma_addr_t addr);
>> +
>> +extern struct notifier_block brcmstb_platform_nb;
>
> It seems a bit weird to have the notifier code split across two
> compilation units in the way which requires this - it seems more
> reasonable to have it all together on one side or the other, with the
> common interface being either the callback for setting the ops or a
> function for installing the notifier, depending on where things fall.
Okay, I'll try to rework this.
Thanks Robin,
Jim
>
> Robin.
>
>> +
>> +#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
>> +
>> #if defined(CONFIG_MIPS)
>> /* Broadcom MIPs HW implicitly does the swapping if necessary */
>> #define bcm_readl(a) __raw_readl(a)
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-12 21:43 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-12 21:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 12, 2017 at 2:04 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> [+DMA API maintainers]
>
> On 11/10/17 23:34, Jim Quinlan wrote:
>> The Broadcom STB PCIe host controller is intimately related to the
>> memory subsystem. This close relationship adds complexity to how cpu
>> system memory is mapped to PCIe memory. Ideally, this mapping is an
>> identity mapping, or an identity mapping off by a constant. Not so in
>> this case.
>>
>> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
>> of system memory. Here is how the PCIe controller maps the
>> system memory to PCIe memory:
>>
>> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
>> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
>> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
>> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
>> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> Although there are some "gaps" that can be added between the
>> individual mappings by software, the permutation of memory regions for
>> the most part is fixed by HW. The solution of having something close
>> to an identity mapping is not possible.
>>
>> The idea behind this HW design is that the same PCIe module can
>> act as an RC or EP, and if it acts as an EP it concatenates all
>> of system memory into a BAR so anything can be accessed. Unfortunately,
>> when the PCIe block is in the role of an RC it also presents this
>> "BAR" to downstream PCIe devices, rather than offering an identity map
>> between its system memory and PCIe space.
>>
>> Suppose that an endpoint driver allocs some DMA memory. Suppose this
>> memory is located at 0x6000_0000, which is in the middle of memc1-a.
>> The driver wants a dma_addr_t value that it can pass on to the EP to
>> use. Without doing any custom mapping, the EP will use this value for
>> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
>> won't work; the device needs a dma_addr_t that reflects the PCIe space
>> address, namely 0xa000_0000.
>>
>> So, essentially the solution to this problem must modify the
>> dma_addr_t returned by the DMA routines routines. There are two
>> ways (I know of) of doing this:
>>
>> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
>> that are used by the dma_ops routines. This is the approach of
>>
>> arch/mips/cavium-octeon/dma-octeon.c
>>
>> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
>> as static inline functions.
>>
>> (b) Subscribe to a notifier that notifies when a device is added to a
>> bus. When this happens, set_dma_ops() can be called for the device.
>> This method is mentioned in:
>>
>> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>>
>> where it says as a comment
>>
>> "In case if platform code need to use own special DMA
>> configuration, it can use Platform bus notifier and
>> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
>> configuration."
>>
>> Solution (b) is what this commit does. It uses the native dma_ops
>> as the base set of operations, and overrides some with custom
>> functions that translate the address and then call the base
>> function.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> drivers/pci/host/Makefile | 3 +-
>> drivers/pci/host/pci-brcmstb-dma.c | 219 +++++++++++++++++++++++++++++++++++++
>> drivers/pci/host/pci-brcmstb.c | 150 +++++++++++++++++++++++--
>> drivers/pci/host/pci-brcmstb.h | 7 ++
>> 4 files changed, 368 insertions(+), 11 deletions(-)
>> create mode 100644 drivers/pci/host/pci-brcmstb-dma.c
>>
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index 4398d2c..c283321 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -21,7 +21,8 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
>> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
>> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>> obj-$(CONFIG_VMD) += vmd.o
>> -obj-$(CONFIG_PCI_BRCMSTB) += pci-brcmstb.o
>> +obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>> +brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>>
>> # The following drivers are for devices that use the generic ACPI
>> # pci_root.c driver but don't support standard ECAM config access.
>> diff --git a/drivers/pci/host/pci-brcmstb-dma.c b/drivers/pci/host/pci-brcmstb-dma.c
>> new file mode 100644
>> index 0000000..81ce122
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-brcmstb-dma.c
>> @@ -0,0 +1,219 @@
>> +/*
>> + * Copyright (C) 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +#include <linux/dma-mapping.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of_address.h>
>> +#include <linux/pci.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/smp.h>
>> +
>> +#include "pci-brcmstb.h"
>> +
>> +static const struct dma_map_ops *arch_dma_ops;
>> +static struct dma_map_ops brcm_dma_ops;
>> +
>> +static void *brcm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
>> + gfp_t gfp, unsigned long attrs)
>> +{
>> + void *ret;
>> +
>> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
>> + if (ret)
>> + *handle = brcm_to_pci(*handle);
>> + return ret;
>> +}
>> +
>> +static void brcm_dma_free(struct device *dev, size_t size, void *cpu_addr,
>> + dma_addr_t handle, unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
>> +}
>> +
>> +static int brcm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
>> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
>> + unsigned long attrs)
>> +{
>> + dma_addr = brcm_to_cpu(dma_addr);
>> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
>> +}
>> +
>> +static int brcm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
>> + void *cpu_addr, dma_addr_t handle, size_t size,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
>> + attrs);
>> +}
>> +
>> +static dma_addr_t brcm_dma_map_page(struct device *dev, struct page *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
>> + dir, attrs));
>> +}
>> +
>> +static void brcm_dma_unmap_page(struct device *dev, dma_addr_t handle,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
>> +}
>> +
>> +static int brcm_dma_map_sg(struct device *dev, struct scatterlist *sgl,
>> + int nents, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + int ret, i;
>> + struct scatterlist *sg;
>> +
>> + ret = arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
>> + /* The ARM and MIPS implementations of map_sg and unmap_sg
>> + * make calls to ops->map_page(), which we already intercept.
>> + * The ARM64 does not, so we must iterate through the SG list
>> + * and convert each dma_address to one that is compatible
>> + * with our PCI RC implementation.
>> + */
>
> That's a pretty fragile assumption given that arch code is free to
> change, and anyone doing so is unlikely to be aware of your driver.
> You'd be better off implementing these in terms of {brcm_dma_}map_page
> directly.
>
Will fix.
>> + if (IS_ENABLED(CONFIG_ARM64))
>> + for_each_sg(sgl, sg, ret, i)
>> + sg->dma_address = brcm_to_pci(sg->dma_address);
>> + return ret;
>> +}
>> +
>> +static void brcm_dma_unmap_sg(struct device *dev,
>> + struct scatterlist *sgl, int nents,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + int i;
>> + struct scatterlist *sg;
>> +
>> + /* The ARM and MIPS implementations of map_sg and unmap_sg
>> + * make calls to ops->map_page(), which we already intercept.
>> + * The ARM64 does not, so we must iterate through the SG list
>> + * and convert each dma_address to one that is compatible
>> + * with our PCI RC implementation.
>> + */
>> + if (IS_ENABLED(CONFIG_ARM64))
>> + for_each_sg(sgl, sg, nents, i)
>> + sg->dma_address = brcm_to_cpu(sg->dma_address);
>> + arch_dma_ops->map_sg(dev, sgl, nents, dir, attrs);
>> +}
>> +
>> +static void brcm_dma_sync_single_for_cpu(struct device *dev,
>> + dma_addr_t handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
>> +}
>> +
>> +static void brcm_dma_sync_single_for_device(struct device *dev,
>> + dma_addr_t handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
>> +}
>
> And sync_sg_*()? They might not be that commonly used by in-tree
> drivers, but who knows what lurks beyond?
>
Will fix.
>> +
>> +static dma_addr_t brcm_dma_map_resource(struct device *dev, phys_addr_t phys,
>> + size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return brcm_to_pci(arch_dma_ops->map_resource
>> + (dev, phys, size, dir, attrs));
>> +}
>> +
>> +static void brcm_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + handle = brcm_to_cpu(handle);
>> + arch_dma_ops->unmap_resource(dev, handle, size, dir, attrs);
>> +}
>> +
>> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
>> +{
>> + return dma_addr == BRCMSTB_ERROR_CODE;
>
> Huh? How do you know this will work correctly with every platform's
> ->map_page implementation (hint: it doesn't).
>
Will fix.
>> +}
>> +
>> +static const struct dma_map_ops *brcm_get_arch_dma_ops(struct device *dev)
>> +{
>> +#if defined(CONFIG_MIPS)
>> + return mips_dma_map_ops;
>> +#elif defined(CONFIG_ARM)
>> + return &arm_dma_ops;
>> +#elif defined(CONFIG_ARM64)
>> + /* swiotlb_dma_ops is a static var, so we get ahold
>> + * of it by calling arch_setup_dma_ops(...).
>> + */
>> + arch_setup_dma_ops(dev, 0, 0, NULL, false);
>> + return dev->dma_ops;
>> +#endif
>> + return 0;
>> +}
>
> As mentioned earlier, no. There are theoretical cases where it might not
> be true, but in practice you can assume all PCI devices are going to get
> the same DMA ops as their associated host controller (and that's still a
> better assumption that what you have here), so you can just grab those
> at the point you install the notifier.
>
Yes, for some reason I did not know of get_dma_ops() and I wrote my
own, poorly. Will fix.
>> +
>> +static void brcm_set_dma_ops(struct device *dev)
>> +{
>> + arch_dma_ops = brcm_get_arch_dma_ops(dev);
>> + if (!arch_dma_ops)
>> + return;
>> +
>> + /* Set all of the base operations; some will be overridden */
>> + brcm_dma_ops = *arch_dma_ops;
>> +
>> + /* Insert the Brcm-specific override operations */
>> + brcm_dma_ops.alloc = brcm_dma_alloc;
>> + brcm_dma_ops.free = brcm_dma_free;
>> + brcm_dma_ops.mmap = brcm_dma_mmap;
>> + brcm_dma_ops.get_sgtable = brcm_dma_get_sgtable;
>> + brcm_dma_ops.map_page = brcm_dma_map_page;
>> + brcm_dma_ops.unmap_page = brcm_dma_unmap_page;
>> + brcm_dma_ops.sync_single_for_cpu = brcm_dma_sync_single_for_cpu;
>> + brcm_dma_ops.sync_single_for_device = brcm_dma_sync_single_for_device;
>> + brcm_dma_ops.map_sg = brcm_dma_map_sg;
>> + brcm_dma_ops.unmap_sg = brcm_dma_unmap_sg;
>> + if (arch_dma_ops->map_resource)
>> + brcm_dma_ops.map_resource = brcm_dma_map_resource;
>> + if (arch_dma_ops->unmap_resource)
>> + brcm_dma_ops.unmap_resource = brcm_dma_unmap_resource;
>> + brcm_dma_ops.mapping_error = brcm_mapping_error;
>> +
>> + /* Use our brcm_dma_ops for this driver */
>> + set_dma_ops(dev, &brcm_dma_ops);
>> +}
>
> Just have a static const set of ops like everyone else - you can handle
> the conditionality of ->{map,unmap}_resource inside the brcm_* wrappers.
>
Will fix.
>> +
>> +static int brcmstb_platform_notifier(struct notifier_block *nb,
>> + unsigned long event, void *__dev)
>> +{
>> + struct device *dev = __dev;
>> +
>> + if (event != BUS_NOTIFY_ADD_DEVICE)
>> + return NOTIFY_DONE;
>> +
>> + brcm_set_dma_ops(dev);
>> + return NOTIFY_OK;
>> +}
>> +
>> +struct notifier_block brcmstb_platform_nb = {
>> + .notifier_call = brcmstb_platform_notifier,
>> +};
>> +EXPORT_SYMBOL(brcmstb_platform_nb);
>> diff --git a/drivers/pci/host/pci-brcmstb.c b/drivers/pci/host/pci-brcmstb.c
>> index f4cd6e7..03c0da9 100644
>> --- a/drivers/pci/host/pci-brcmstb.c
>> +++ b/drivers/pci/host/pci-brcmstb.c
>> @@ -343,6 +343,8 @@ struct brcm_pcie {
>>
>> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
>> static phys_addr_t scb_size[BRCM_MAX_SCB];
>> +static struct of_pci_range *dma_ranges;
>> +static int num_dma_ranges;
>> static int num_memc;
>> static DEFINE_MUTEX(brcm_pcie_lock);
>>
>> @@ -362,6 +364,8 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
>> {
>> mutex_lock(&brcm_pcie_lock);
>> snprintf(pcie->name, sizeof(pcie->name) - 1, "PCIe%d", pcie->id);
>> + if (list_empty(&brcm_pcie))
>> + bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
>> list_add_tail(&pcie->list, &brcm_pcie);
>> mutex_unlock(&brcm_pcie_lock);
>>
>> @@ -378,8 +382,14 @@ static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
>> tmp = list_entry(pos, struct brcm_pcie, list);
>> if (tmp == pcie) {
>> list_del(pos);
>> - if (list_empty(&brcm_pcie))
>> + if (list_empty(&brcm_pcie)) {
>> + bus_unregister_notifier(&pci_bus_type,
>> + &brcmstb_platform_nb);
>> + kfree(dma_ranges);
>> + dma_ranges = NULL;
>> + num_dma_ranges = 0;
>> num_memc = 0;
>> + }
>> break;
>> }
>> }
>> @@ -403,6 +413,35 @@ int encode_ibar_size(u64 size)
>> return 0;
>> }
>>
>> +dma_addr_t brcm_to_pci(dma_addr_t addr)
>> +{
>> + struct of_pci_range *p;
>> +
>> + if (!num_dma_ranges)
>> + return addr;
>> +
>> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
>> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
>> + return addr - p->cpu_addr + p->pci_addr;
>> +
>> + return BRCMSTB_ERROR_CODE;
>> +}
>> +EXPORT_SYMBOL(brcm_to_pci);
>
> AFAICS it doesn't make much sense for anyone outside this driver to ever
> be calling these.
>
Will fix.
>> +dma_addr_t brcm_to_cpu(dma_addr_t addr)
>> +{
>> + struct of_pci_range *p;
>> +
>> + if (!num_dma_ranges)
>> + return addr;
>> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
>> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
>> + return addr - p->pci_addr + p->cpu_addr;
>> +
>> + return addr;
>> +}
>> +EXPORT_SYMBOL(brcm_to_cpu);
>> +
>> static u32 mdio_form_pkt(int port, int regad, int cmd)
>> {
>> u32 pkt = 0;
>> @@ -652,6 +691,74 @@ static int brcm_parse_ranges(struct brcm_pcie *pcie)
>> return 0;
>> }
>>
>> +static int brcm_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>> + struct device_node *node)
>> +{
>> + const int na = 3, ns = 2;
>> + int rlen;
>> +
>> + parser->node = node;
>> + parser->pna = of_n_addr_cells(node);
>> + parser->np = parser->pna + na + ns;
>> +
>> + parser->range = of_get_property(node, "dma-ranges", &rlen);
>> + if (!parser->range)
>> + return -ENOENT;
>> +
>> + parser->end = parser->range + rlen / sizeof(__be32);
>> +
>> + return 0;
>> +}
>
> Note that we've got a factored-out helper for this queued in -next
> already - see here:
>
> https://patchwork.kernel.org/patch/9927541/
>
I will submit a change when it gets merged.
>> +
>> +static int brcm_parse_dma_ranges(struct brcm_pcie *pcie)
>> +{
>> + int i, ret = 0;
>> + struct of_pci_range_parser parser;
>> + struct device_node *dn = pcie->dn;
>> +
>> + mutex_lock(&brcm_pcie_lock);
>> + if (dma_ranges)
>> + goto done;
>> +
>> + /* Parse dma-ranges property if present. If there are multiple
>> + * PCI controllers, we only have to parse from one of them since
>> + * the others will have an identical mapping.
>> + */
>> + if (!brcm_pci_dma_range_parser_init(&parser, dn)) {
>> + unsigned int max_ranges
>> + = (parser.end - parser.range) / parser.np;
>> +
>> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
>> + GFP_KERNEL);
>> + if (!dma_ranges) {
>> + ret = -ENOMEM;
>> + goto done;
>> + }
>> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
>> + i++)
>> + num_dma_ranges++;
>> + }
>> +
>> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
>> + u64 size = brcmstb_memory_memc_size(i);
>> +
>> + if (size == (u64)-1) {
>> + dev_err(pcie->dev, "cannot get memc%d size", i);
>> + ret = -EINVAL;
>> + goto done;
>> + } else if (size) {
>> + scb_size[i] = roundup_pow_of_two_64(size);
>> + num_memc++;
>> + } else {
>> + break;
>> + }
>> + }
>> +
>> +done:
>> + mutex_unlock(&brcm_pcie_lock);
>> + return ret;
>> +}
>> +
>> static void set_regulators(struct brcm_pcie *pcie, bool on)
>> {
>> struct list_head *pos;
>> @@ -728,10 +835,34 @@ static void brcm_pcie_setup_prep(struct brcm_pcie *pcie)
>> */
>> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>>
>> - /* Set simple configuration based on memory sizes
>> - * only. We always start the viewport at address 0.
>> - */
>> - rc_bar2_offset = 0;
>> + if (dma_ranges) {
>> + /* The best-case scenario is to place the inbound
>> + * region in the first 4GB of pci-space, as some
>> + * legacy devices can only address 32bits.
>> + * We would also like to put the MSI under 4GB
>> + * as well, since some devices require a 32bit
>> + * MSI target address.
>> + */
>> + if (total_mem_size <= 0xc0000000ULL &&
>> + rc_bar2_size <= 0x100000000ULL) {
>> + rc_bar2_offset = 0;
>> + } else {
>> + /* The system memory is 4GB or larger so we
>> + * cannot start the inbound region at location
>> + * 0 (since we have to allow some space for
>> + * outbound memory @ 3GB). So instead we
>> + * start it at the 1x multiple of its size
>> + */
>> + rc_bar2_offset = rc_bar2_size;
>> + }
>> +
>> + } else {
>> + /* Set simple configuration based on memory sizes
>> + * only. We always start the viewport at address 0,
>> + * and set the MSI target address accordingly.
>> + */
>> + rc_bar2_offset = 0;
>> + }
>>
>> tmp = lower_32_bits(rc_bar2_offset);
>> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
>> @@ -1040,11 +1171,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>> return -EINVAL;
>> }
>>
>> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
>> - pr_err("cannot yet handle dma-ranges\n");
>> - return -EINVAL;
>> - }
>> -
>> data = of_id->data;
>> pcie->reg_offsets = data->offsets;
>> pcie->reg_field_info = data->reg_field_info;
>> @@ -1113,6 +1239,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> + ret = brcm_parse_dma_ranges(pcie);
>> + if (ret)
>> + return ret;
>> +
>> ret = clk_prepare_enable(pcie->clk);
>> if (ret) {
>> dev_err(&pdev->dev, "could not enable clock\n");
>> diff --git a/drivers/pci/host/pci-brcmstb.h b/drivers/pci/host/pci-brcmstb.h
>> index 86f9cd1..4851be8 100644
>> --- a/drivers/pci/host/pci-brcmstb.h
>> +++ b/drivers/pci/host/pci-brcmstb.h
>> @@ -21,6 +21,13 @@
>> /* Broadcom PCIE Offsets */
>> #define PCIE_INTR2_CPU_BASE 0x4300
>>
>> +dma_addr_t brcm_to_pci(dma_addr_t addr);
>> +dma_addr_t brcm_to_cpu(dma_addr_t addr);
>> +
>> +extern struct notifier_block brcmstb_platform_nb;
>
> It seems a bit weird to have the notifier code split across two
> compilation units in the way which requires this - it seems more
> reasonable to have it all together on one side or the other, with the
> common interface being either the callback for setting the ops or a
> function for installing the notifier, depending on where things fall.
Okay, I'll try to rework this.
Thanks Robin,
Jim
>
> Robin.
>
>> +
>> +#define BRCMSTB_ERROR_CODE (~(dma_addr_t)0x0)
>> +
>> #if defined(CONFIG_MIPS)
>> /* Broadcom MIPs HW implicitly does the swapping if necessary */
>> #define bcm_readl(a) __raw_readl(a)
>>
>
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-12 18:04 ` Robin Murphy
(?)
@ 2017-10-17 8:14 ` Christoph Hellwig
-1 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-17 8:14 UTC (permalink / raw)
To: Robin Murphy
Cc: Jim Quinlan, linux-kernel, Mark Rutland, linux-mips,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Christoph Hellwig, Marek Szyprowski, iommu
Just took a quick look over this and I basically agree with the comments
from Robin.
What I don't understand is why you're even trying to do all these
hacky things.
It seems like the controller should simply set dma_pfn_offset for
each device hanging off it, and all the supported architectures
should be updated to obey that if they don't do so yet, and
you're done without needing this giant mess.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-17 8:14 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-17 8:14 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, Rob Herring, iommu, Jim Quinlan,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
Just took a quick look over this and I basically agree with the comments
from Robin.
What I don't understand is why you're even trying to do all these
hacky things.
It seems like the controller should simply set dma_pfn_offset for
each device hanging off it, and all the supported architectures
should be updated to obey that if they don't do so yet, and
you're done without needing this giant mess.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-17 8:14 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-17 8:14 UTC (permalink / raw)
To: linux-arm-kernel
Just took a quick look over this and I basically agree with the comments
from Robin.
What I don't understand is why you're even trying to do all these
hacky things.
It seems like the controller should simply set dma_pfn_offset for
each device hanging off it, and all the supported architectures
should be updated to obey that if they don't do so yet, and
you're done without needing this giant mess.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
2017-10-11 22:34 ` Jim Quinlan
(?)
@ 2017-10-17 8:24 ` Christoph Hellwig
-1 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-17 8:24 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
linux-mips, devicetree, linux-pci, Florian Fainelli,
Ralf Baechle, Catalin Marinas, Will Deacon, Bjorn Helgaas,
Rob Herring, Mark Rutland, Gregory Fong, Kevin Cernekee,
Brian Norris
> +/* Macros to help extract property data */
> +#define U8TOU32(b, offs) \
> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
> + (((u32)b[3 + offs] << 24) & 0xff000000))
Please us helpers like get_unaligned_le32 instead opencoding them.
> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
And together with this it looks really whacky. So you're converting
from le to native first and then do another conversion from be to cpu?
Something doesn't work out here.
> +/* -------------------- Functions -------------------- */
Please remove pointless comments like this one.
> +
> +/*
> + * If the DT nodes are handy, determine which MEMC holds the specified
> + * physical address.
> + */
> +#ifdef CONFIG_ARCH_BRCMSTB
> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
Please move this into the arm arch code.
> +#elif defined(CONFIG_MIPS)
And this into the mips arch code.
> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
Why is this exported?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-17 8:24 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-17 8:24 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel
> +/* Macros to help extract property data */
> +#define U8TOU32(b, offs) \
> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
> + (((u32)b[3 + offs] << 24) & 0xff000000))
Please us helpers like get_unaligned_le32 instead opencoding them.
> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
And together with this it looks really whacky. So you're converting
from le to native first and then do another conversion from be to cpu?
Something doesn't work out here.
> +/* -------------------- Functions -------------------- */
Please remove pointless comments like this one.
> +
> +/*
> + * If the DT nodes are handy, determine which MEMC holds the specified
> + * physical address.
> + */
> +#ifdef CONFIG_ARCH_BRCMSTB
> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
Please move this into the arm arch code.
> +#elif defined(CONFIG_MIPS)
And this into the mips arch code.
> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
Why is this exported?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-17 8:24 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-17 8:24 UTC (permalink / raw)
To: linux-arm-kernel
> +/* Macros to help extract property data */
> +#define U8TOU32(b, offs) \
> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
> + (((u32)b[3 + offs] << 24) & 0xff000000))
Please us helpers like get_unaligned_le32 instead opencoding them.
> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
And together with this it looks really whacky. So you're converting
from le to native first and then do another conversion from be to cpu?
Something doesn't work out here.
> +/* -------------------- Functions -------------------- */
Please remove pointless comments like this one.
> +
> +/*
> + * If the DT nodes are handy, determine which MEMC holds the specified
> + * physical address.
> + */
> +#ifdef CONFIG_ARCH_BRCMSTB
> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
Please move this into the arm arch code.
> +#elif defined(CONFIG_MIPS)
And this into the mips arch code.
> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
Why is this exported?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-17 8:14 ` Christoph Hellwig
(?)
@ 2017-10-17 16:11 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-17 16:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robin Murphy, linux-kernel, Mark Rutland, linux-mips,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Marek Szyprowski, iommu
On Tue, Oct 17, 2017 at 4:14 AM, Christoph Hellwig <hch@lst.de> wrote:
> Just took a quick look over this and I basically agree with the comments
> from Robin.
>
> What I don't understand is why you're even trying to do all these
> hacky things.
>
> It seems like the controller should simply set dma_pfn_offset for
> each device hanging off it, and all the supported architectures
> should be updated to obey that if they don't do so yet, and
> you're done without needing this giant mess.
My understanding is that dma_pfn_offset is that it is a single
constant offset from RAM, in our case, to map to PCIe space. But in
my commit message I detail how our PCIe controller presents memory
with multiple regions with multiple different offsets. If an EP device
maps to a region on the host memory, yes we can set the dma_pfn_offset
for that device for that location within that range,. But if the
device then unmaps and allocates from another region with a different
offset, it won't work. If I set dma_pfn_offset I have to assume that
the device is using only one region of memory only, not more than one,
and that it is not unmapping that region and mapping another (with a
different offset). Can I make those assumptions?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-17 16:11 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-17 16:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, linux-arm-kernel, Marek Szyprowski
On Tue, Oct 17, 2017 at 4:14 AM, Christoph Hellwig <hch@lst.de> wrote:
> Just took a quick look over this and I basically agree with the comments
> from Robin.
>
> What I don't understand is why you're even trying to do all these
> hacky things.
>
> It seems like the controller should simply set dma_pfn_offset for
> each device hanging off it, and all the supported architectures
> should be updated to obey that if they don't do so yet, and
> you're done without needing this giant mess.
My understanding is that dma_pfn_offset is that it is a single
constant offset from RAM, in our case, to map to PCIe space. But in
my commit message I detail how our PCIe controller presents memory
with multiple regions with multiple different offsets. If an EP device
maps to a region on the host memory, yes we can set the dma_pfn_offset
for that device for that location within that range,. But if the
device then unmaps and allocates from another region with a different
offset, it won't work. If I set dma_pfn_offset I have to assume that
the device is using only one region of memory only, not more than one,
and that it is not unmapping that region and mapping another (with a
different offset). Can I make those assumptions?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-17 16:11 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-17 16:11 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 17, 2017 at 4:14 AM, Christoph Hellwig <hch@lst.de> wrote:
> Just took a quick look over this and I basically agree with the comments
> from Robin.
>
> What I don't understand is why you're even trying to do all these
> hacky things.
>
> It seems like the controller should simply set dma_pfn_offset for
> each device hanging off it, and all the supported architectures
> should be updated to obey that if they don't do so yet, and
> you're done without needing this giant mess.
My understanding is that dma_pfn_offset is that it is a single
constant offset from RAM, in our case, to map to PCIe space. But in
my commit message I detail how our PCIe controller presents memory
with multiple regions with multiple different offsets. If an EP device
maps to a region on the host memory, yes we can set the dma_pfn_offset
for that device for that location within that range,. But if the
device then unmaps and allocates from another region with a different
offset, it won't work. If I set dma_pfn_offset I have to assume that
the device is using only one region of memory only, not more than one,
and that it is not unmapping that region and mapping another (with a
different offset). Can I make those assumptions?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
2017-10-17 8:24 ` Christoph Hellwig
(?)
@ 2017-10-17 16:12 ` Florian Fainelli
-1 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-17 16:12 UTC (permalink / raw)
To: Christoph Hellwig, Jim Quinlan
Cc: linux-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
linux-mips, devicetree, linux-pci, Florian Fainelli,
Ralf Baechle, Catalin Marinas, Will Deacon, Bjorn Helgaas,
Rob Herring, Mark Rutland, Gregory Fong, Kevin Cernekee,
Brian Norris
On 10/17/2017 01:24 AM, Christoph Hellwig wrote:
>> +/* Macros to help extract property data */
>> +#define U8TOU32(b, offs) \
>> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
>> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
>> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
>> + (((u32)b[3 + offs] << 24) & 0xff000000))
>
> Please us helpers like get_unaligned_le32 instead opencoding them.
>
>> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
>
> And together with this it looks really whacky. So you're converting
> from le to native first and then do another conversion from be to cpu?
>
> Something doesn't work out here.
>
>> +/* -------------------- Functions -------------------- */
>
> Please remove pointless comments like this one.
>
>> +
>> +/*
>> + * If the DT nodes are handy, determine which MEMC holds the specified
>> + * physical address.
>> + */
>> +#ifdef CONFIG_ARCH_BRCMSTB
>> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
>
> Please move this into the arm arch code.
No, this needs to work on both ARM and ARM64, hence the reason why this
is in a reasonably architecture neutral place.
>
>> +#elif defined(CONFIG_MIPS)
>
> And this into the mips arch code.
Same reason as above.
>
>> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
>
>> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
>
> Why is this exported?
Because the PCIE RC driver can be built as a module.
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-17 16:12 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-17 16:12 UTC (permalink / raw)
To: Christoph Hellwig, Jim Quinlan
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel
On 10/17/2017 01:24 AM, Christoph Hellwig wrote:
>> +/* Macros to help extract property data */
>> +#define U8TOU32(b, offs) \
>> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
>> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
>> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
>> + (((u32)b[3 + offs] << 24) & 0xff000000))
>
> Please us helpers like get_unaligned_le32 instead opencoding them.
>
>> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
>
> And together with this it looks really whacky. So you're converting
> from le to native first and then do another conversion from be to cpu?
>
> Something doesn't work out here.
>
>> +/* -------------------- Functions -------------------- */
>
> Please remove pointless comments like this one.
>
>> +
>> +/*
>> + * If the DT nodes are handy, determine which MEMC holds the specified
>> + * physical address.
>> + */
>> +#ifdef CONFIG_ARCH_BRCMSTB
>> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
>
> Please move this into the arm arch code.
No, this needs to work on both ARM and ARM64, hence the reason why this
is in a reasonably architecture neutral place.
>
>> +#elif defined(CONFIG_MIPS)
>
> And this into the mips arch code.
Same reason as above.
>
>> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
>
>> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
>
> Why is this exported?
Because the PCIE RC driver can be built as a module.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-17 16:12 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-17 16:12 UTC (permalink / raw)
To: linux-arm-kernel
On 10/17/2017 01:24 AM, Christoph Hellwig wrote:
>> +/* Macros to help extract property data */
>> +#define U8TOU32(b, offs) \
>> + ((((u32)b[0 + offs] << 0) & 0x000000ff) | \
>> + (((u32)b[1 + offs] << 8) & 0x0000ff00) | \
>> + (((u32)b[2 + offs] << 16) & 0x00ff0000) | \
>> + (((u32)b[3 + offs] << 24) & 0xff000000))
>
> Please us helpers like get_unaligned_le32 instead opencoding them.
>
>> +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(U8TOU32(b, offs)))
>
> And together with this it looks really whacky. So you're converting
> from le to native first and then do another conversion from be to cpu?
>
> Something doesn't work out here.
>
>> +/* -------------------- Functions -------------------- */
>
> Please remove pointless comments like this one.
>
>> +
>> +/*
>> + * If the DT nodes are handy, determine which MEMC holds the specified
>> + * physical address.
>> + */
>> +#ifdef CONFIG_ARCH_BRCMSTB
>> +int __brcmstb_memory_phys_addr_to_memc(phys_addr_t pa, void __iomem *base)
>
> Please move this into the arm arch code.
No, this needs to work on both ARM and ARM64, hence the reason why this
is in a reasonably architecture neutral place.
>
>> +#elif defined(CONFIG_MIPS)
>
> And this into the mips arch code.
Same reason as above.
>
>> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
>
>> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
>
> Why is this exported?
Because the PCIE RC driver can be built as a module.
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
2017-10-11 22:34 ` Jim Quinlan
(?)
@ 2017-10-17 20:24 ` Rob Herring
-1 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-17 20:24 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel, Mark Rutland, linux-mips, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
> 1 file changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 0000000..2f699da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,106 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Introduction:
> + The brcmstb host controller closely follows the example set in
> +
> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> +
> + The rest of this document explains some added customizations and
> + offers an example Brcmstb PCIe host controller DT node.
> +
> +Required Properties:
> + reg -- the register start address and length for the PCIe block.
> + Additional start,length pairs may be specified for clock addresses.
Kind of vague and why do you need clock addresses and the clock binding?
Also, typically the config space is defined here? Is that missing or you
don't support memory mapped config space?
> + interrupts -- two interrupts are specified; the first interrupt is for
> + the PCI host controller and the second is for MSI if the built-in
> + MSI controller is to be used.
> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
> + or "brcm,bcm7278-pcie".
One compatible per line.
> + #address-cells -- the number of address cells for PCI-space.
> + #size-cells -- the number of size cells for PCI-space.
> + ranges -- See [1]; a specification of the outbound windows for the host
> + controller. Each outbound window is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + Due to hardware limitations, there may be a maximum of four
> + non-contiguous ranges specified.
> + #interrupt-cells -- number of cells used to describe the interrupt.
How many cells?
> + interrupt-map-mask -- see [1]; four cells, the first three are zero
> + for our uses and the fourth cell is the mask (val = 0x7) for
> + the legacy interrupt number [1..4].
> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
> + plus the size of the interrupt specifier.
> + linux,pci-domain -- the domain of the host controller.
> +
> +Optional Properties:
> + clocks -- list of clock phandles. If specified, this should list one
> + clock.
> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
> + that if the 'clocks' property is given, 'clock-names' is mandatory,
> + and the name of the clock is expected to be "sw_pcie".
> + dma-ranges -- Similar in structure to ranges, each dma region is
> + specified with a n-tuple. Dma-regions describe the inbound
> + accesses from EP to RC; it translates the pci address that the
> + EP "sees" to the CPU address in memory. This property is needed
> + because the design of the Brcmstb memory subsystem often precludes
> + idenity-mapping between CPU address space and PCIe address space.
> + Each range is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
There's no need to describe standard properties. Just put whatever is
specific to your platform. That applies throughout this doc.
> + msi-parent -- if MSI is to be used, this must be a phandle to the
> + msi-parent. If this prop is set to the phandle of the PCIe
> + node, or if the msi-parent prop is missing, the PCIE controller
> + will attempt to use its built in MSI controller.
> + msi-controller -- this property should only be specified if the
> + PCIe controller is using its internal MSI controller.
> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
> + brcm,gen -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
We have a standard property for this IIRC.
> + supply-names -- the names of voltage regulators that the root
> + complex should turn off/on/on on suspend/resume/boot. This
> + is a string list.
> + supplies -- A collection of phandles to a regulator nodes, see
> + Documentation/devicetree/bindings/regulator/ for specific
> + bindings. The number and order of phandles must match
> + exactly the number of strings in the "supply-names" property.
This is not the regulator binding. Use the standard binding.
> +
> +Example Node:
> +
> +pcie0: pcie@f0460000 {
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
> + compatible = "brcm,pci-plat-dev";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 47 3
> + 0 0 0 2 &intc 0 48 3
> + 0 0 0 3 &intc 0 49 3
> + 0 0 0 4 &intc 0 50 3>;
> + interrupt-names = "pcie_0_inta",
> + "pcie_0_intb",
> + "pcie_0_intc",
> + "pcie_0_intd";
> + clocks = <&sw_pcie0>;
> + clock-names = "sw_pcie";
> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
> + msi-controller; /* use PCIe's internal MSI controller */
> + brcm,ssc;
> + brcm,gen = <1>;
> + supply-names = "vreg-wifi-pwr";
> + supplies = <&vreg-wifi-pwr>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-17 20:24 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-17 20:24 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
> 1 file changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 0000000..2f699da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,106 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Introduction:
> + The brcmstb host controller closely follows the example set in
> +
> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> +
> + The rest of this document explains some added customizations and
> + offers an example Brcmstb PCIe host controller DT node.
> +
> +Required Properties:
> + reg -- the register start address and length for the PCIe block.
> + Additional start,length pairs may be specified for clock addresses.
Kind of vague and why do you need clock addresses and the clock binding?
Also, typically the config space is defined here? Is that missing or you
don't support memory mapped config space?
> + interrupts -- two interrupts are specified; the first interrupt is for
> + the PCI host controller and the second is for MSI if the built-in
> + MSI controller is to be used.
> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
> + or "brcm,bcm7278-pcie".
One compatible per line.
> + #address-cells -- the number of address cells for PCI-space.
> + #size-cells -- the number of size cells for PCI-space.
> + ranges -- See [1]; a specification of the outbound windows for the host
> + controller. Each outbound window is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + Due to hardware limitations, there may be a maximum of four
> + non-contiguous ranges specified.
> + #interrupt-cells -- number of cells used to describe the interrupt.
How many cells?
> + interrupt-map-mask -- see [1]; four cells, the first three are zero
> + for our uses and the fourth cell is the mask (val = 0x7) for
> + the legacy interrupt number [1..4].
> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
> + plus the size of the interrupt specifier.
> + linux,pci-domain -- the domain of the host controller.
> +
> +Optional Properties:
> + clocks -- list of clock phandles. If specified, this should list one
> + clock.
> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
> + that if the 'clocks' property is given, 'clock-names' is mandatory,
> + and the name of the clock is expected to be "sw_pcie".
> + dma-ranges -- Similar in structure to ranges, each dma region is
> + specified with a n-tuple. Dma-regions describe the inbound
> + accesses from EP to RC; it translates the pci address that the
> + EP "sees" to the CPU address in memory. This property is needed
> + because the design of the Brcmstb memory subsystem often precludes
> + idenity-mapping between CPU address space and PCIe address space.
> + Each range is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
There's no need to describe standard properties. Just put whatever is
specific to your platform. That applies throughout this doc.
> + msi-parent -- if MSI is to be used, this must be a phandle to the
> + msi-parent. If this prop is set to the phandle of the PCIe
> + node, or if the msi-parent prop is missing, the PCIE controller
> + will attempt to use its built in MSI controller.
> + msi-controller -- this property should only be specified if the
> + PCIe controller is using its internal MSI controller.
> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
> + brcm,gen -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
We have a standard property for this IIRC.
> + supply-names -- the names of voltage regulators that the root
> + complex should turn off/on/on on suspend/resume/boot. This
> + is a string list.
> + supplies -- A collection of phandles to a regulator nodes, see
> + Documentation/devicetree/bindings/regulator/ for specific
> + bindings. The number and order of phandles must match
> + exactly the number of strings in the "supply-names" property.
This is not the regulator binding. Use the standard binding.
> +
> +Example Node:
> +
> +pcie0: pcie@f0460000 {
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
> + compatible = "brcm,pci-plat-dev";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 47 3
> + 0 0 0 2 &intc 0 48 3
> + 0 0 0 3 &intc 0 49 3
> + 0 0 0 4 &intc 0 50 3>;
> + interrupt-names = "pcie_0_inta",
> + "pcie_0_intb",
> + "pcie_0_intc",
> + "pcie_0_intd";
> + clocks = <&sw_pcie0>;
> + clock-names = "sw_pcie";
> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
> + msi-controller; /* use PCIe's internal MSI controller */
> + brcm,ssc;
> + brcm,gen = <1>;
> + supply-names = "vreg-wifi-pwr";
> + supplies = <&vreg-wifi-pwr>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-17 20:24 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-17 20:24 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
> 1 file changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 0000000..2f699da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,106 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Introduction:
> + The brcmstb host controller closely follows the example set in
> +
> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
> +
> + The rest of this document explains some added customizations and
> + offers an example Brcmstb PCIe host controller DT node.
> +
> +Required Properties:
> + reg -- the register start address and length for the PCIe block.
> + Additional start,length pairs may be specified for clock addresses.
Kind of vague and why do you need clock addresses and the clock binding?
Also, typically the config space is defined here? Is that missing or you
don't support memory mapped config space?
> + interrupts -- two interrupts are specified; the first interrupt is for
> + the PCI host controller and the second is for MSI if the built-in
> + MSI controller is to be used.
> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
> + or "brcm,bcm7278-pcie".
One compatible per line.
> + #address-cells -- the number of address cells for PCI-space.
> + #size-cells -- the number of size cells for PCI-space.
> + ranges -- See [1]; a specification of the outbound windows for the host
> + controller. Each outbound window is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
> + Due to hardware limitations, there may be a maximum of four
> + non-contiguous ranges specified.
> + #interrupt-cells -- number of cells used to describe the interrupt.
How many cells?
> + interrupt-map-mask -- see [1]; four cells, the first three are zero
> + for our uses and the fourth cell is the mask (val = 0x7) for
> + the legacy interrupt number [1..4].
> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
> + plus the size of the interrupt specifier.
> + linux,pci-domain -- the domain of the host controller.
> +
> +Optional Properties:
> + clocks -- list of clock phandles. If specified, this should list one
> + clock.
> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
> + that if the 'clocks' property is given, 'clock-names' is mandatory,
> + and the name of the clock is expected to be "sw_pcie".
> + dma-ranges -- Similar in structure to ranges, each dma region is
> + specified with a n-tuple. Dma-regions describe the inbound
> + accesses from EP to RC; it translates the pci address that the
> + EP "sees" to the CPU address in memory. This property is needed
> + because the design of the Brcmstb memory subsystem often precludes
> + idenity-mapping between CPU address space and PCIe address space.
> + Each range is described by a n-tuple:
> + (3 cells) -- PCIe space start address; one cell for attributes
> + and two cells for the 64-bit PCIe address.
> + (x cells) -- CPU/System start address, number of cells is determined
> + by the parent node's #address-cells.
> + (y cells) -- Size of region, number of cells determined by the
> + parent node's #size-cells.
There's no need to describe standard properties. Just put whatever is
specific to your platform. That applies throughout this doc.
> + msi-parent -- if MSI is to be used, this must be a phandle to the
> + msi-parent. If this prop is set to the phandle of the PCIe
> + node, or if the msi-parent prop is missing, the PCIE controller
> + will attempt to use its built in MSI controller.
> + msi-controller -- this property should only be specified if the
> + PCIe controller is using its internal MSI controller.
> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
> + brcm,gen -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
We have a standard property for this IIRC.
> + supply-names -- the names of voltage regulators that the root
> + complex should turn off/on/on on suspend/resume/boot. This
> + is a string list.
> + supplies -- A collection of phandles to a regulator nodes, see
> + Documentation/devicetree/bindings/regulator/ for specific
> + bindings. The number and order of phandles must match
> + exactly the number of strings in the "supply-names" property.
This is not the regulator binding. Use the standard binding.
> +
> +Example Node:
> +
> +pcie0: pcie at f0460000 {
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
> + compatible = "brcm,pci-plat-dev";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &intc 0 47 3
> + 0 0 0 2 &intc 0 48 3
> + 0 0 0 3 &intc 0 49 3
> + 0 0 0 4 &intc 0 50 3>;
> + interrupt-names = "pcie_0_inta",
> + "pcie_0_intb",
> + "pcie_0_intc",
> + "pcie_0_intd";
> + clocks = <&sw_pcie0>;
> + clock-names = "sw_pcie";
> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
> + msi-controller; /* use PCIe's internal MSI controller */
> + brcm,ssc;
> + brcm,gen = <1>;
> + supply-names = "vreg-wifi-pwr";
> + supplies = <&vreg-wifi-pwr>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
2017-10-17 20:24 ` Rob Herring
(?)
@ 2017-10-17 22:42 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-17 22:42 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, Mark Rutland, linux-mips, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>> The DT bindings description of the Brcmstb PCIe device is described. This
>> node can be used by almost all Broadcom settop box chips, using
>> ARM, ARM64, or MIPS CPU architectures.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> new file mode 100644
>> index 0000000..2f699da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> @@ -0,0 +1,106 @@
>> +Brcmstb PCIe Host Controller Device Tree Bindings
>> +We don't; this line is erroneous.
>> +Introduction:
>> + The brcmstb host controller closely follows the example set in
>> +
>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>> +
>> + The rest of this document explains some added customizations and
>> + offers an example Brcmstb PCIe host controller DT node.
>> +
>> +Required Properties:
>> + reg -- the register start address and length for the PCIe block.
>> + Additional start,length pairs may be specified for clock addresses.
>
> Kind of vague and why do you need clock addresses and the clock binding?
>
We don't; this line is erroneous and will be removed.
> Also, typically the config space is defined here? Is that missing or you
> don't support memory mapped config space?
>
We do not support memory mapped config space.
>> + interrupts -- two interrupts are specified; the first interrupt is for
>> + the PCI host controller and the second is for MSI if the built-in
>> + MSI controller is to be used.
>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>> + or "brcm,bcm7278-pcie".
>
> One compatible per line.
>
Will fix.
>> + #address-cells -- the number of address cells for PCI-space.
>> + #size-cells -- the number of size cells for PCI-space.
>> + ranges -- See [1]; a specification of the outbound windows for the host
>> + controller. Each outbound window is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + Due to hardware limitations, there may be a maximum of four
>> + non-contiguous ranges specified.We don't; this line is erroneous.
>> + #interrupt-cells -- number of cells used to describe the interrupt.
>
> How many cells?
>
This line will be removed.
>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>> + for our uses and the fourth cell is the mask (val = 0x7) for
>> + the legacy interrupt number [1..4].
>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>> + plus the size of the interrupt specifier.
>> + linux,pci-domain -- the domain of the host controller.
>> +
>> +Optional Properties:
>> + clocks -- list of clock phandles. If specified, this should list one
>> + clock.
>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>> + and the name of the clock is expected to be "sw_pcie".
>> + dma-ranges -- Similar in structure to ranges, each dma region is
>> + specified with a n-tuple. Dma-regions describe the inbound
>> + accesses from EP to RC; it translates the pci address that the
>> + EP "sees" to the CPU address in memory. This property is needed
>> + because the design of the Brcmstb memory subsystem often precludes
>> + idenity-mapping between CPU address space and PCIe address space.
>> + Each range is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>
> There's no need to describe standard properties. Just put whatever is
> specific to your platform. That applies throughout this doc.
>
Will fix.
>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>> + msi-parent. If this prop is set to the phandle of the PCIe
>> + node, or if the msi-parent prop is missing, the PCIE controller
>> + will attempt to use its built in MSI controller.
>> + msi-controller -- this property should only be specified if the
>> + PCIe controller is using its internal MSI controller.
>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>> + brcm,gen -- (integer) indicates desired generation of link:
>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>
> We have a standard property for this IIRC.
>
Yes, BrianN pointed that out and it will be fixed.
>> + supply-names -- the names of voltage regulators that the root
>> + complex should turn off/on/on on suspend/resume/boot. This
>> + is a string list.
>> + supplies -- A collection of phandles to a regulator nodes, see
>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>> + bindings. The number and order of phandles must match
>> + exactly the number of strings in the "supply-names" property.
>
> This is not the regulator binding. Use the standard binding.
>
The reason we do it this way is because the PCIe controller does not
know or care what the names of the supplies are, or how many there
will be. The list of regulators can be different for each board we
support, as these regulators turn on/off the downstream EP device.
All the PCIe controller does is turn on/off this list of regulators
when booting,resuming/suspending.
An alternative would have the node specifying the standard properties
xyz-supply = <&xyz_reg>;
abc-supply = <&abc_reg>;
pdq-supply = <&pdq_reg>;
...
and then have this driver search all of the properties in the PCIe
node for names matching /-supply$/, and then create a list of phandles
from that. Is that what you would like?
Thanks, Jim
>> +
>> +Example Node:
>> +
>> +pcie0: pcie@f0460000 {
>> + reg = <0x0 0xf0460000 0x0 0x9310>;
>> + interrupts = <0x0 0x0 0x4>;
>> + compatible = "brcm,pci-plat-dev";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
>> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &intc 0 47 3
>> + 0 0 0 2 &intc 0 48 3
>> + 0 0 0 3 &intc 0 49 3
>> + 0 0 0 4 &intc 0 50 3>;
>> + interrupt-names = "pcie_0_inta",
>> + "pcie_0_intb",
>> + "pcie_0_intc",
>> + "pcie_0_intd";
>> + clocks = <&sw_pcie0>;
>> + clock-names = "sw_pcie";
>> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
>> + msi-controller; /* use PCIe's internal MSI controller */
>> + brcm,ssc;
>> + brcm,gen = <1>;
>> + supply-names = "vreg-wifi-pwr";
>> + supplies = <&vreg-wifi-pwr>;
>> + linux,pci-domain = <0>;
>> + };
>> --
>> 1.9.0.138.g2de3478
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-17 22:42 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-17 22:42 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>> The DT bindings description of the Brcmstb PCIe device is described. This
>> node can be used by almost all Broadcom settop box chips, using
>> ARM, ARM64, or MIPS CPU architectures.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> new file mode 100644
>> index 0000000..2f699da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> @@ -0,0 +1,106 @@
>> +Brcmstb PCIe Host Controller Device Tree Bindings
>> +We don't; this line is erroneous.
>> +Introduction:
>> + The brcmstb host controller closely follows the example set in
>> +
>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>> +
>> + The rest of this document explains some added customizations and
>> + offers an example Brcmstb PCIe host controller DT node.
>> +
>> +Required Properties:
>> + reg -- the register start address and length for the PCIe block.
>> + Additional start,length pairs may be specified for clock addresses.
>
> Kind of vague and why do you need clock addresses and the clock binding?
>
We don't; this line is erroneous and will be removed.
> Also, typically the config space is defined here? Is that missing or you
> don't support memory mapped config space?
>
We do not support memory mapped config space.
>> + interrupts -- two interrupts are specified; the first interrupt is for
>> + the PCI host controller and the second is for MSI if the built-in
>> + MSI controller is to be used.
>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>> + or "brcm,bcm7278-pcie".
>
> One compatible per line.
>
Will fix.
>> + #address-cells -- the number of address cells for PCI-space.
>> + #size-cells -- the number of size cells for PCI-space.
>> + ranges -- See [1]; a specification of the outbound windows for the host
>> + controller. Each outbound window is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + Due to hardware limitations, there may be a maximum of four
>> + non-contiguous ranges specified.We don't; this line is erroneous.
>> + #interrupt-cells -- number of cells used to describe the interrupt.
>
> How many cells?
>
This line will be removed.
>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>> + for our uses and the fourth cell is the mask (val = 0x7) for
>> + the legacy interrupt number [1..4].
>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>> + plus the size of the interrupt specifier.
>> + linux,pci-domain -- the domain of the host controller.
>> +
>> +Optional Properties:
>> + clocks -- list of clock phandles. If specified, this should list one
>> + clock.
>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>> + and the name of the clock is expected to be "sw_pcie".
>> + dma-ranges -- Similar in structure to ranges, each dma region is
>> + specified with a n-tuple. Dma-regions describe the inbound
>> + accesses from EP to RC; it translates the pci address that the
>> + EP "sees" to the CPU address in memory. This property is needed
>> + because the design of the Brcmstb memory subsystem often precludes
>> + idenity-mapping between CPU address space and PCIe address space.
>> + Each range is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>
> There's no need to describe standard properties. Just put whatever is
> specific to your platform. That applies throughout this doc.
>
Will fix.
>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>> + msi-parent. If this prop is set to the phandle of the PCIe
>> + node, or if the msi-parent prop is missing, the PCIE controller
>> + will attempt to use its built in MSI controller.
>> + msi-controller -- this property should only be specified if the
>> + PCIe controller is using its internal MSI controller.
>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>> + brcm,gen -- (integer) indicates desired generation of link:
>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>
> We have a standard property for this IIRC.
>
Yes, BrianN pointed that out and it will be fixed.
>> + supply-names -- the names of voltage regulators that the root
>> + complex should turn off/on/on on suspend/resume/boot. This
>> + is a string list.
>> + supplies -- A collection of phandles to a regulator nodes, see
>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>> + bindings. The number and order of phandles must match
>> + exactly the number of strings in the "supply-names" property.
>
> This is not the regulator binding. Use the standard binding.
>
The reason we do it this way is because the PCIe controller does not
know or care what the names of the supplies are, or how many there
will be. The list of regulators can be different for each board we
support, as these regulators turn on/off the downstream EP device.
All the PCIe controller does is turn on/off this list of regulators
when booting,resuming/suspending.
An alternative would have the node specifying the standard properties
xyz-supply = <&xyz_reg>;
abc-supply = <&abc_reg>;
pdq-supply = <&pdq_reg>;
...
and then have this driver search all of the properties in the PCIe
node for names matching /-supply$/, and then create a list of phandles
from that. Is that what you would like?
Thanks, Jim
>> +
>> +Example Node:
>> +
>> +pcie0: pcie@f0460000 {
>> + reg = <0x0 0xf0460000 0x0 0x9310>;
>> + interrupts = <0x0 0x0 0x4>;
>> + compatible = "brcm,pci-plat-dev";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
>> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &intc 0 47 3
>> + 0 0 0 2 &intc 0 48 3
>> + 0 0 0 3 &intc 0 49 3
>> + 0 0 0 4 &intc 0 50 3>;
>> + interrupt-names = "pcie_0_inta",
>> + "pcie_0_intb",
>> + "pcie_0_intc",
>> + "pcie_0_intd";
>> + clocks = <&sw_pcie0>;
>> + clock-names = "sw_pcie";
>> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
>> + msi-controller; /* use PCIe's internal MSI controller */
>> + brcm,ssc;
>> + brcm,gen = <1>;
>> + supply-names = "vreg-wifi-pwr";
>> + supplies = <&vreg-wifi-pwr>;
>> + linux,pci-domain = <0>;
>> + };
>> --
>> 1.9.0.138.g2de3478
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-17 22:42 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-17 22:42 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>> The DT bindings description of the Brcmstb PCIe device is described. This
>> node can be used by almost all Broadcom settop box chips, using
>> ARM, ARM64, or MIPS CPU architectures.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> new file mode 100644
>> index 0000000..2f699da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>> @@ -0,0 +1,106 @@
>> +Brcmstb PCIe Host Controller Device Tree Bindings
>> +We don't; this line is erroneous.
>> +Introduction:
>> + The brcmstb host controller closely follows the example set in
>> +
>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>> +
>> + The rest of this document explains some added customizations and
>> + offers an example Brcmstb PCIe host controller DT node.
>> +
>> +Required Properties:
>> + reg -- the register start address and length for the PCIe block.
>> + Additional start,length pairs may be specified for clock addresses.
>
> Kind of vague and why do you need clock addresses and the clock binding?
>
We don't; this line is erroneous and will be removed.
> Also, typically the config space is defined here? Is that missing or you
> don't support memory mapped config space?
>
We do not support memory mapped config space.
>> + interrupts -- two interrupts are specified; the first interrupt is for
>> + the PCI host controller and the second is for MSI if the built-in
>> + MSI controller is to be used.
>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>> + or "brcm,bcm7278-pcie".
>
> One compatible per line.
>
Will fix.
>> + #address-cells -- the number of address cells for PCI-space.
>> + #size-cells -- the number of size cells for PCI-space.
>> + ranges -- See [1]; a specification of the outbound windows for the host
>> + controller. Each outbound window is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>> + Due to hardware limitations, there may be a maximum of four
>> + non-contiguous ranges specified.We don't; this line is erroneous.
>> + #interrupt-cells -- number of cells used to describe the interrupt.
>
> How many cells?
>
This line will be removed.
>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>> + for our uses and the fourth cell is the mask (val = 0x7) for
>> + the legacy interrupt number [1..4].
>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>> + plus the size of the interrupt specifier.
>> + linux,pci-domain -- the domain of the host controller.
>> +
>> +Optional Properties:
>> + clocks -- list of clock phandles. If specified, this should list one
>> + clock.
>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>> + and the name of the clock is expected to be "sw_pcie".
>> + dma-ranges -- Similar in structure to ranges, each dma region is
>> + specified with a n-tuple. Dma-regions describe the inbound
>> + accesses from EP to RC; it translates the pci address that the
>> + EP "sees" to the CPU address in memory. This property is needed
>> + because the design of the Brcmstb memory subsystem often precludes
>> + idenity-mapping between CPU address space and PCIe address space.
>> + Each range is described by a n-tuple:
>> + (3 cells) -- PCIe space start address; one cell for attributes
>> + and two cells for the 64-bit PCIe address.
>> + (x cells) -- CPU/System start address, number of cells is determined
>> + by the parent node's #address-cells.
>> + (y cells) -- Size of region, number of cells determined by the
>> + parent node's #size-cells.
>
> There's no need to describe standard properties. Just put whatever is
> specific to your platform. That applies throughout this doc.
>
Will fix.
>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>> + msi-parent. If this prop is set to the phandle of the PCIe
>> + node, or if the msi-parent prop is missing, the PCIE controller
>> + will attempt to use its built in MSI controller.
>> + msi-controller -- this property should only be specified if the
>> + PCIe controller is using its internal MSI controller.
>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>> + brcm,gen -- (integer) indicates desired generation of link:
>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>
> We have a standard property for this IIRC.
>
Yes, BrianN pointed that out and it will be fixed.
>> + supply-names -- the names of voltage regulators that the root
>> + complex should turn off/on/on on suspend/resume/boot. This
>> + is a string list.
>> + supplies -- A collection of phandles to a regulator nodes, see
>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>> + bindings. The number and order of phandles must match
>> + exactly the number of strings in the "supply-names" property.
>
> This is not the regulator binding. Use the standard binding.
>
The reason we do it this way is because the PCIe controller does not
know or care what the names of the supplies are, or how many there
will be. The list of regulators can be different for each board we
support, as these regulators turn on/off the downstream EP device.
All the PCIe controller does is turn on/off this list of regulators
when booting,resuming/suspending.
An alternative would have the node specifying the standard properties
xyz-supply = <&xyz_reg>;
abc-supply = <&abc_reg>;
pdq-supply = <&pdq_reg>;
...
and then have this driver search all of the properties in the PCIe
node for names matching /-supply$/, and then create a list of phandles
from that. Is that what you would like?
Thanks, Jim
>> +
>> +Example Node:
>> +
>> +pcie0: pcie at f0460000 {
>> + reg = <0x0 0xf0460000 0x0 0x9310>;
>> + interrupts = <0x0 0x0 0x4>;
>> + compatible = "brcm,pci-plat-dev";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x02000000 0x00000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x08000000
>> + 0x02000000 0x00000000 0x08000000 0x00000000 0xc8000000 0x00000000 0x08000000>;
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &intc 0 47 3
>> + 0 0 0 2 &intc 0 48 3
>> + 0 0 0 3 &intc 0 49 3
>> + 0 0 0 4 &intc 0 50 3>;
>> + interrupt-names = "pcie_0_inta",
>> + "pcie_0_intb",
>> + "pcie_0_intc",
>> + "pcie_0_intd";
>> + clocks = <&sw_pcie0>;
>> + clock-names = "sw_pcie";
>> + msi-parent = <&pcie0>; /* use PCIe's internal MSI controller */
>> + msi-controller; /* use PCIe's internal MSI controller */
>> + brcm,ssc;
>> + brcm,gen = <1>;
>> + supply-names = "vreg-wifi-pwr";
>> + supplies = <&vreg-wifi-pwr>;
>> + linux,pci-domain = <0>;
>> + };
>> --
>> 1.9.0.138.g2de3478
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
2017-10-17 16:12 ` Florian Fainelli
(?)
@ 2017-10-18 6:46 ` Christoph Hellwig
-1 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-18 6:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: Christoph Hellwig, Jim Quinlan, linux-kernel,
bcm-kernel-feedback-list, linux-arm-kernel, linux-mips,
devicetree, linux-pci, Ralf Baechle, Catalin Marinas,
Will Deacon, Bjorn Helgaas, Rob Herring, Mark Rutland,
Gregory Fong, Kevin Cernekee, Brian Norris
On Tue, Oct 17, 2017 at 09:12:22AM -0700, Florian Fainelli wrote:
> > Please move this into the arm arch code.
>
> No, this needs to work on both ARM and ARM64, hence the reason why this
> is in a reasonably architecture neutral place.
So there is no other shared code between the ARM and ARM64 ports for
this SOC?
> >> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> >
> >> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
> >
> > Why is this exported?
>
> Because the PCIE RC driver can be built as a module.
Hmm, supporting PCIE RC as module sounds odd, but it seems like there
are a few others like that. At least make it EXPORT_SYMBOL_GPL() then
to document the internal nature.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-18 6:46 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-18 6:46 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, linux-mips, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, linux-kernel, Ralf Baechle, Christoph Hellwig,
Rob Herring, Jim Quinlan, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Tue, Oct 17, 2017 at 09:12:22AM -0700, Florian Fainelli wrote:
> > Please move this into the arm arch code.
>
> No, this needs to work on both ARM and ARM64, hence the reason why this
> is in a reasonably architecture neutral place.
So there is no other shared code between the ARM and ARM64 ports for
this SOC?
> >> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> >
> >> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
> >
> > Why is this exported?
>
> Because the PCIE RC driver can be built as a module.
Hmm, supporting PCIE RC as module sounds odd, but it seems like there
are a few others like that. At least make it EXPORT_SYMBOL_GPL() then
to document the internal nature.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-18 6:46 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-18 6:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 17, 2017 at 09:12:22AM -0700, Florian Fainelli wrote:
> > Please move this into the arm arch code.
>
> No, this needs to work on both ARM and ARM64, hence the reason why this
> is in a reasonably architecture neutral place.
So there is no other shared code between the ARM and ARM64 ports for
this SOC?
> >> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
> >
> >> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
> >
> > Why is this exported?
>
> Because the PCIE RC driver can be built as a module.
Hmm, supporting PCIE RC as module sounds odd, but it seems like there
are a few others like that. At least make it EXPORT_SYMBOL_GPL() then
to document the internal nature.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-18 6:53 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-18 6:53 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
linux-mips, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
> My understanding is that dma_pfn_offset is that it is a single
> constant offset from RAM, in our case, to map to PCIe space.
Yes.
> But in
> my commit message I detail how our PCIe controller presents memory
> with multiple regions with multiple different offsets. If an EP device
> maps to a region on the host memory, yes we can set the dma_pfn_offset
> for that device for that location within that range,. But if the
> device then unmaps and allocates from another region with a different
> offset, it won't work. If I set dma_pfn_offset I have to assume that
> the device is using only one region of memory only, not more than one,
> and that it is not unmapping that region and mapping another (with a
> different offset). Can I make those assumptions?
No, we can't make that assumption unfortunately. But how is your
code going to work if the mapping spans multiple of your translation
regions?
Also I really don't think the stacking of dma_ops as in this patch
is a good idea. For MIPS you should do the variant suggested in
the patch description and hook into dma_to_phys/phys_to_dma helpers,
and for ARM/ARM64 you should talk to the maintainers on how they
want the translation integrated.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-18 6:53 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-18 6:53 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
Florian Fainelli, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci,
Kevin Cernekee, Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Ralf Baechle, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, Christoph Hellwig,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
> My understanding is that dma_pfn_offset is that it is a single
> constant offset from RAM, in our case, to map to PCIe space.
Yes.
> But in
> my commit message I detail how our PCIe controller presents memory
> with multiple regions with multiple different offsets. If an EP device
> maps to a region on the host memory, yes we can set the dma_pfn_offset
> for that device for that location within that range,. But if the
> device then unmaps and allocates from another region with a different
> offset, it won't work. If I set dma_pfn_offset I have to assume that
> the device is using only one region of memory only, not more than one,
> and that it is not unmapping that region and mapping another (with a
> different offset). Can I make those assumptions?
No, we can't make that assumption unfortunately. But how is your
code going to work if the mapping spans multiple of your translation
regions?
Also I really don't think the stacking of dma_ops as in this patch
is a good idea. For MIPS you should do the variant suggested in
the patch description and hook into dma_to_phys/phys_to_dma helpers,
and for ARM/ARM64 you should talk to the maintainers on how they
want the translation integrated.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-18 6:53 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-18 6:53 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
> My understanding is that dma_pfn_offset is that it is a single
> constant offset from RAM, in our case, to map to PCIe space.
Yes.
> But in
> my commit message I detail how our PCIe controller presents memory
> with multiple regions with multiple different offsets. If an EP device
> maps to a region on the host memory, yes we can set the dma_pfn_offset
> for that device for that location within that range,. But if the
> device then unmaps and allocates from another region with a different
> offset, it won't work. If I set dma_pfn_offset I have to assume that
> the device is using only one region of memory only, not more than one,
> and that it is not unmapping that region and mapping another (with a
> different offset). Can I make those assumptions?
No, we can't make that assumption unfortunately. But how is your
code going to work if the mapping spans multiple of your translation
regions?
Also I really don't think the stacking of dma_ops as in this patch
is a good idea. For MIPS you should do the variant suggested in
the patch description and hook into dma_to_phys/phys_to_dma helpers,
and for ARM/ARM64 you should talk to the maintainers on how they
want the translation integrated.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-18 6:53 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-18 6:53 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
> My understanding is that dma_pfn_offset is that it is a single
> constant offset from RAM, in our case, to map to PCIe space.
Yes.
> But in
> my commit message I detail how our PCIe controller presents memory
> with multiple regions with multiple different offsets. If an EP device
> maps to a region on the host memory, yes we can set the dma_pfn_offset
> for that device for that location within that range,. But if the
> device then unmaps and allocates from another region with a different
> offset, it won't work. If I set dma_pfn_offset I have to assume that
> the device is using only one region of memory only, not more than one,
> and that it is not unmapping that region and mapping another (with a
> different offset). Can I make those assumptions?
No, we can't make that assumption unfortunately. But how is your
code going to work if the mapping spans multiple of your translation
regions?
Also I really don't think the stacking of dma_ops as in this patch
is a good idea. For MIPS you should do the variant suggested in
the patch description and hook into dma_to_phys/phys_to_dma helpers,
and for ARM/ARM64 you should talk to the maintainers on how they
want the translation integrated.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-18 14:41 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-18 14:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robin Murphy, linux-kernel, Mark Rutland, linux-mips,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Marek Szyprowski, iommu
On Wed, Oct 18, 2017 at 2:53 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
>> My understanding is that dma_pfn_offset is that it is a single
>> constant offset from RAM, in our case, to map to PCIe space.
>
> Yes.
>
>> But in
>> my commit message I detail how our PCIe controller presents memory
>> with multiple regions with multiple different offsets. If an EP device
>> maps to a region on the host memory, yes we can set the dma_pfn_offset
>> for that device for that location within that range,. But if the
>> device then unmaps and allocates from another region with a different
>> offset, it won't work. If I set dma_pfn_offset I have to assume that
>> the device is using only one region of memory only, not more than one,
>> and that it is not unmapping that region and mapping another (with a
>> different offset). Can I make those assumptions?
>
> No, we can't make that assumption unfortunately. But how is your
> code going to work if the mapping spans multiple of your translation
> regions?
That's what brcm_to_{pci,cpu} are for -- they keep a list of the
dma-ranges given in the PCIe DT node, and translate from system memory
addresses to pci-space addresses, and vice versa. As long as people
are using the DMA API it should work. It works for all of the ARM,
ARM64, and MIPS Broadcom systems I've tested, using eight different EP
devices. Note that I am not thrilled to be advocating this mechanism
but it seemed the best alternative.
>memorymaintiners
> Also I really don't think the stacking of dma_ops as in this patch
> is a good idea. For MIPS you should do the variant suggested in
> the patch description and hook into dma_to_phys/phys_to_dma helpers,
> and for ARM/ARM64 you should talk to the maintainers on how they
> want the translation integrated.
I would prefer that the same code work for all three architectures.
What I would like from ARM/ARM64 is the ability to override
phys_to_dma() and dma_to_phys(); I thought the chances of that being
accepted would be slim. But you are right, I should ask the
maintainers.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-18 14:41 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-18 14:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Rutland, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
Florian Fainelli, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci,
Kevin Cernekee, Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Ralf Baechle, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Oct 18, 2017 at 2:53 AM, Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> wrote:
> On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
>> My understanding is that dma_pfn_offset is that it is a single
>> constant offset from RAM, in our case, to map to PCIe space.
>
> Yes.
>
>> But in
>> my commit message I detail how our PCIe controller presents memory
>> with multiple regions with multiple different offsets. If an EP device
>> maps to a region on the host memory, yes we can set the dma_pfn_offset
>> for that device for that location within that range,. But if the
>> device then unmaps and allocates from another region with a different
>> offset, it won't work. If I set dma_pfn_offset I have to assume that
>> the device is using only one region of memory only, not more than one,
>> and that it is not unmapping that region and mapping another (with a
>> different offset). Can I make those assumptions?
>
> No, we can't make that assumption unfortunately. But how is your
> code going to work if the mapping spans multiple of your translation
> regions?
That's what brcm_to_{pci,cpu} are for -- they keep a list of the
dma-ranges given in the PCIe DT node, and translate from system memory
addresses to pci-space addresses, and vice versa. As long as people
are using the DMA API it should work. It works for all of the ARM,
ARM64, and MIPS Broadcom systems I've tested, using eight different EP
devices. Note that I am not thrilled to be advocating this mechanism
but it seemed the best alternative.
>memorymaintiners
> Also I really don't think the stacking of dma_ops as in this patch
> is a good idea. For MIPS you should do the variant suggested in
> the patch description and hook into dma_to_phys/phys_to_dma helpers,
> and for ARM/ARM64 you should talk to the maintainers on how they
> want the translation integrated.
I would prefer that the same code work for all three architectures.
What I would like from ARM/ARM64 is the ability to override
phys_to_dma() and dma_to_phys(); I thought the chances of that being
accepted would be slim. But you are right, I should ask the
maintainers.
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-18 14:41 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-18 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 18, 2017 at 2:53 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Tue, Oct 17, 2017 at 12:11:55PM -0400, Jim Quinlan wrote:
>> My understanding is that dma_pfn_offset is that it is a single
>> constant offset from RAM, in our case, to map to PCIe space.
>
> Yes.
>
>> But in
>> my commit message I detail how our PCIe controller presents memory
>> with multiple regions with multiple different offsets. If an EP device
>> maps to a region on the host memory, yes we can set the dma_pfn_offset
>> for that device for that location within that range,. But if the
>> device then unmaps and allocates from another region with a different
>> offset, it won't work. If I set dma_pfn_offset I have to assume that
>> the device is using only one region of memory only, not more than one,
>> and that it is not unmapping that region and mapping another (with a
>> different offset). Can I make those assumptions?
>
> No, we can't make that assumption unfortunately. But how is your
> code going to work if the mapping spans multiple of your translation
> regions?
That's what brcm_to_{pci,cpu} are for -- they keep a list of the
dma-ranges given in the PCIe DT node, and translate from system memory
addresses to pci-space addresses, and vice versa. As long as people
are using the DMA API it should work. It works for all of the ARM,
ARM64, and MIPS Broadcom systems I've tested, using eight different EP
devices. Note that I am not thrilled to be advocating this mechanism
but it seemed the best alternative.
>memorymaintiners
> Also I really don't think the stacking of dma_ops as in this patch
> is a good idea. For MIPS you should do the variant suggested in
> the patch description and hook into dma_to_phys/phys_to_dma helpers,
> and for ARM/ARM64 you should talk to the maintainers on how they
> want the translation integrated.
I would prefer that the same code work for all three architectures.
What I would like from ARM/ARM64 is the ability to override
phys_to_dma() and dma_to_phys(); I thought the chances of that being
accepted would be slim. But you are right, I should ask the
maintainers.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 1/9] SOC: brcmstb: add memory API
2017-10-18 6:46 ` Christoph Hellwig
@ 2017-10-18 16:47 ` Florian Fainelli
-1 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-18 16:47 UTC (permalink / raw)
To: Christoph Hellwig, Florian Fainelli
Cc: Jim Quinlan, linux-kernel, bcm-kernel-feedback-list,
linux-arm-kernel, linux-mips, devicetree, linux-pci,
Ralf Baechle, Catalin Marinas, Will Deacon, Bjorn Helgaas,
Rob Herring, Mark Rutland, Gregory Fong, Kevin Cernekee,
Brian Norris
On 10/17/2017 11:46 PM, Christoph Hellwig wrote:
> On Tue, Oct 17, 2017 at 09:12:22AM -0700, Florian Fainelli wrote:
>>> Please move this into the arm arch code.
>>
>> No, this needs to work on both ARM and ARM64, hence the reason why this
>> is in a reasonably architecture neutral place.
>
> So there is no other shared code between the ARM and ARM64 ports for
> this SOC?
The biuctrl.c file is also shared, and there are pending changes for
v4.15-rc1 that also bring more shared files to this directory.
>
>>>> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
>>>
>>>> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
>>>
>>> Why is this exported?
>>
>> Because the PCIE RC driver can be built as a module.
>
> Hmm, supporting PCIE RC as module sounds odd, but it seems like there
> are a few others like that. At least make it EXPORT_SYMBOL_GPL() then
> to document the internal nature.
Fair enough. Thanks
--
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 1/9] SOC: brcmstb: add memory API
@ 2017-10-18 16:47 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-18 16:47 UTC (permalink / raw)
To: linux-arm-kernel
On 10/17/2017 11:46 PM, Christoph Hellwig wrote:
> On Tue, Oct 17, 2017 at 09:12:22AM -0700, Florian Fainelli wrote:
>>> Please move this into the arm arch code.
>>
>> No, this needs to work on both ARM and ARM64, hence the reason why this
>> is in a reasonably architecture neutral place.
>
> So there is no other shared code between the ARM and ARM64 ports for
> this SOC?
The biuctrl.c file is also shared, and there are pending changes for
v4.15-rc1 that also bring more shared files to this directory.
>
>>>> +EXPORT_SYMBOL(brcmstb_memory_phys_addr_to_memc);
>>>
>>>> +EXPORT_SYMBOL(brcmstb_memory_memc_size);
>>>
>>> Why is this exported?
>>
>> Because the PCIE RC driver can be built as a module.
>
> Hmm, supporting PCIE RC as module sounds odd, but it seems like there
> are a few others like that. At least make it EXPORT_SYMBOL_GPL() then
> to document the internal nature.
Fair enough. Thanks
--
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-19 9:16 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-19 9:16 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
linux-mips, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
> dma-ranges given in the PCIe DT node, and translate from system memory
> addresses to pci-space addresses, and vice versa. As long as people
> are using the DMA API it should work. It works for all of the ARM,
> ARM64, and MIPS Broadcom systems I've tested, using eight different EP
> devices. Note that I am not thrilled to be advocating this mechanism
> but it seemed the best alternative.
Say we are using your original example ranges:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
and now you get a dma mapping request for physical addresses
3fffff00 to 4000000f, which would span two of your ranges. How
is this going to work?
> I would prefer that the same code work for all three architectures.
> What I would like from ARM/ARM64 is the ability to override
> phys_to_dma() and dma_to_phys(); I thought the chances of that being
> accepted would be slim. But you are right, I should ask the
> maintainers.
It is still better than trying to stack dma ops, which is a receipe
for problems down the road.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-19 9:16 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-19 9:16 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
Florian Fainelli, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci,
Kevin Cernekee, Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Ralf Baechle, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, Christoph Hellwig,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
> dma-ranges given in the PCIe DT node, and translate from system memory
> addresses to pci-space addresses, and vice versa. As long as people
> are using the DMA API it should work. It works for all of the ARM,
> ARM64, and MIPS Broadcom systems I've tested, using eight different EP
> devices. Note that I am not thrilled to be advocating this mechanism
> but it seemed the best alternative.
Say we are using your original example ranges:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
and now you get a dma mapping request for physical addresses
3fffff00 to 4000000f, which would span two of your ranges. How
is this going to work?
> I would prefer that the same code work for all three architectures.
> What I would like from ARM/ARM64 is the ability to override
> phys_to_dma() and dma_to_phys(); I thought the chances of that being
> accepted would be slim. But you are right, I should ask the
> maintainers.
It is still better than trying to stack dma ops, which is a receipe
for problems down the road.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-19 9:16 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-19 9:16 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
> dma-ranges given in the PCIe DT node, and translate from system memory
> addresses to pci-space addresses, and vice versa. As long as people
> are using the DMA API it should work. It works for all of the ARM,
> ARM64, and MIPS Broadcom systems I've tested, using eight different EP
> devices. Note that I am not thrilled to be advocating this mechanism
> but it seemed the best alternative.
Say we are using your original example ranges:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
and now you get a dma mapping request for physical addresses
3fffff00 to 4000000f, which would span two of your ranges. How
is this going to work?
> I would prefer that the same code work for all three architectures.
> What I would like from ARM/ARM64 is the ability to override
> phys_to_dma() and dma_to_phys(); I thought the chances of that being
> accepted would be slim. But you are right, I should ask the
> maintainers.
It is still better than trying to stack dma ops, which is a receipe
for problems down the road.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-19 9:16 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-19 9:16 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
> dma-ranges given in the PCIe DT node, and translate from system memory
> addresses to pci-space addresses, and vice versa. As long as people
> are using the DMA API it should work. It works for all of the ARM,
> ARM64, and MIPS Broadcom systems I've tested, using eight different EP
> devices. Note that I am not thrilled to be advocating this mechanism
> but it seemed the best alternative.
Say we are using your original example ranges:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
and now you get a dma mapping request for physical addresses
3fffff00 to 4000000f, which would span two of your ranges. How
is this going to work?
> I would prefer that the same code work for all three architectures.
> What I would like from ARM/ARM64 is the ability to override
> phys_to_dma() and dma_to_phys(); I thought the chances of that being
> accepted would be slim. But you are right, I should ask the
> maintainers.
It is still better than trying to stack dma ops, which is a receipe
for problems down the road.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
2017-10-17 22:42 ` Jim Quinlan
(?)
(?)
@ 2017-10-19 21:49 ` Rob Herring
-1 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-19 21:49 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel, Mark Rutland, Linux-MIPS, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>> node can be used by almost all Broadcom settop box chips, using
>>> ARM, ARM64, or MIPS CPU architectures.
>>>
>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>> ---
>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>> 1 file changed, 106 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> new file mode 100644
>>> index 0000000..2f699da
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> @@ -0,0 +1,106 @@
>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>> +We don't; this line is erroneous.
>>> +Introduction:
>>> + The brcmstb host controller closely follows the example set in
>>> +
>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>> +
>>> + The rest of this document explains some added customizations and
>>> + offers an example Brcmstb PCIe host controller DT node.
>>> +
>>> +Required Properties:
>>> + reg -- the register start address and length for the PCIe block.
>>> + Additional start,length pairs may be specified for clock addresses.
>>
>> Kind of vague and why do you need clock addresses and the clock binding?
>>
> We don't; this line is erroneous and will be removed.
>
>> Also, typically the config space is defined here? Is that missing or you
>> don't support memory mapped config space?
>>
> We do not support memory mapped config space.
>
>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>> + the PCI host controller and the second is for MSI if the built-in
>>> + MSI controller is to be used.
>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>> + or "brcm,bcm7278-pcie".
>>
>> One compatible per line.
>>
> Will fix.
>
>>> + #address-cells -- the number of address cells for PCI-space.
>>> + #size-cells -- the number of size cells for PCI-space.
>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>> + controller. Each outbound window is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>> + Due to hardware limitations, there may be a maximum of four
>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>
>> How many cells?
>>
> This line will be removed.
Humm, why? You need it to have interrupt-map. You just need to say
what the value is, not what the property is.
>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>> + the legacy interrupt number [1..4].
>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>> + plus the size of the interrupt specifier.
>>> + linux,pci-domain -- the domain of the host controller.
>>> +
>>> +Optional Properties:
>>> + clocks -- list of clock phandles. If specified, this should list one
>>> + clock.
>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>> + and the name of the clock is expected to be "sw_pcie".
>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>> + specified with a n-tuple. Dma-regions describe the inbound
>>> + accesses from EP to RC; it translates the pci address that the
>>> + EP "sees" to the CPU address in memory. This property is needed
>>> + because the design of the Brcmstb memory subsystem often precludes
>>> + idenity-mapping between CPU address space and PCIe address space.
>>> + Each range is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>
>> There's no need to describe standard properties. Just put whatever is
>> specific to your platform. That applies throughout this doc.
>>
> Will fix.
>
>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>> + will attempt to use its built in MSI controller.
>>> + msi-controller -- this property should only be specified if the
>>> + PCIe controller is using its internal MSI controller.
>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>> + brcm,gen -- (integer) indicates desired generation of link:
>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>
>> We have a standard property for this IIRC.
>>
> Yes, BrianN pointed that out and it will be fixed.
>
>>> + supply-names -- the names of voltage regulators that the root
>>> + complex should turn off/on/on on suspend/resume/boot. This
>>> + is a string list.
>>> + supplies -- A collection of phandles to a regulator nodes, see
>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>> + bindings. The number and order of phandles must match
>>> + exactly the number of strings in the "supply-names" property.
>>
>> This is not the regulator binding. Use the standard binding.
>>
> The reason we do it this way is because the PCIe controller does not
> know or care what the names of the supplies are, or how many there
> will be. The list of regulators can be different for each board we
> support, as these regulators turn on/off the downstream EP device.
> All the PCIe controller does is turn on/off this list of regulators
> when booting,resuming/suspending.
>
> An alternative would have the node specifying the standard properties
>
> xyz-supply = <&xyz_reg>;
> abc-supply = <&abc_reg>;
> pdq-supply = <&pdq_reg>;
> ...
>
> and then have this driver search all of the properties in the PCIe
> node for names matching /-supply$/, and then create a list of phandles
> from that. Is that what you would like?
Really, you should have child nodes of the PCIe devices and have the
supplies in there.
The driver could do what you describe, but you've still got to define
the names here.
Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 21:49 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-19 21:49 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel, Mark Rutland, Linux-MIPS, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>> node can be used by almost all Broadcom settop box chips, using
>>> ARM, ARM64, or MIPS CPU architectures.
>>>
>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>> ---
>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>> 1 file changed, 106 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> new file mode 100644
>>> index 0000000..2f699da
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> @@ -0,0 +1,106 @@
>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>> +We don't; this line is erroneous.
>>> +Introduction:
>>> + The brcmstb host controller closely follows the example set in
>>> +
>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>> +
>>> + The rest of this document explains some added customizations and
>>> + offers an example Brcmstb PCIe host controller DT node.
>>> +
>>> +Required Properties:
>>> + reg -- the register start address and length for the PCIe block.
>>> + Additional start,length pairs may be specified for clock addresses.
>>
>> Kind of vague and why do you need clock addresses and the clock binding?
>>
> We don't; this line is erroneous and will be removed.
>
>> Also, typically the config space is defined here? Is that missing or you
>> don't support memory mapped config space?
>>
> We do not support memory mapped config space.
>
>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>> + the PCI host controller and the second is for MSI if the built-in
>>> + MSI controller is to be used.
>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>> + or "brcm,bcm7278-pcie".
>>
>> One compatible per line.
>>
> Will fix.
>
>>> + #address-cells -- the number of address cells for PCI-space.
>>> + #size-cells -- the number of size cells for PCI-space.
>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>> + controller. Each outbound window is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>> + Due to hardware limitations, there may be a maximum of four
>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>
>> How many cells?
>>
> This line will be removed.
Humm, why? You need it to have interrupt-map. You just need to say
what the value is, not what the property is.
>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>> + the legacy interrupt number [1..4].
>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>> + plus the size of the interrupt specifier.
>>> + linux,pci-domain -- the domain of the host controller.
>>> +
>>> +Optional Properties:
>>> + clocks -- list of clock phandles. If specified, this should list one
>>> + clock.
>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>> + and the name of the clock is expected to be "sw_pcie".
>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>> + specified with a n-tuple. Dma-regions describe the inbound
>>> + accesses from EP to RC; it translates the pci address that the
>>> + EP "sees" to the CPU address in memory. This property is needed
>>> + because the design of the Brcmstb memory subsystem often precludes
>>> + idenity-mapping between CPU address space and PCIe address space.
>>> + Each range is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>
>> There's no need to describe standard properties. Just put whatever is
>> specific to your platform. That applies throughout this doc.
>>
> Will fix.
>
>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>> + will attempt to use its built in MSI controller.
>>> + msi-controller -- this property should only be specified if the
>>> + PCIe controller is using its internal MSI controller.
>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>> + brcm,gen -- (integer) indicates desired generation of link:
>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>
>> We have a standard property for this IIRC.
>>
> Yes, BrianN pointed that out and it will be fixed.
>
>>> + supply-names -- the names of voltage regulators that the root
>>> + complex should turn off/on/on on suspend/resume/boot. This
>>> + is a string list.
>>> + supplies -- A collection of phandles to a regulator nodes, see
>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>> + bindings. The number and order of phandles must match
>>> + exactly the number of strings in the "supply-names" property.
>>
>> This is not the regulator binding. Use the standard binding.
>>
> The reason we do it this way is because the PCIe controller does not
> know or care what the names of the supplies are, or how many there
> will be. The list of regulators can be different for each board we
> support, as these regulators turn on/off the downstream EP device.
> All the PCIe controller does is turn on/off this list of regulators
> when booting,resuming/suspending.
>
> An alternative would have the node specifying the standard properties
>
> xyz-supply = <&xyz_reg>;
> abc-supply = <&abc_reg>;
> pdq-supply = <&pdq_reg>;
> ...
>
> and then have this driver search all of the properties in the PCIe
> node for names matching /-supply$/, and then create a list of phandles
> from that. Is that what you would like?
Really, you should have child nodes of the PCIe devices and have the
supplies in there.
The driver could do what you describe, but you've still got to define
the names here.
Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 21:49 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-19 21:49 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>> node can be used by almost all Broadcom settop box chips, using
>>> ARM, ARM64, or MIPS CPU architectures.
>>>
>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>> ---
>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>> 1 file changed, 106 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> new file mode 100644
>>> index 0000000..2f699da
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> @@ -0,0 +1,106 @@
>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>> +We don't; this line is erroneous.
>>> +Introduction:
>>> + The brcmstb host controller closely follows the example set in
>>> +
>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>> +
>>> + The rest of this document explains some added customizations and
>>> + offers an example Brcmstb PCIe host controller DT node.
>>> +
>>> +Required Properties:
>>> + reg -- the register start address and length for the PCIe block.
>>> + Additional start,length pairs may be specified for clock addresses.
>>
>> Kind of vague and why do you need clock addresses and the clock binding?
>>
> We don't; this line is erroneous and will be removed.
>
>> Also, typically the config space is defined here? Is that missing or you
>> don't support memory mapped config space?
>>
> We do not support memory mapped config space.
>
>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>> + the PCI host controller and the second is for MSI if the built-in
>>> + MSI controller is to be used.
>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>> + or "brcm,bcm7278-pcie".
>>
>> One compatible per line.
>>
> Will fix.
>
>>> + #address-cells -- the number of address cells for PCI-space.
>>> + #size-cells -- the number of size cells for PCI-space.
>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>> + controller. Each outbound window is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>> + Due to hardware limitations, there may be a maximum of four
>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>
>> How many cells?
>>
> This line will be removed.
Humm, why? You need it to have interrupt-map. You just need to say
what the value is, not what the property is.
>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>> + the legacy interrupt number [1..4].
>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>> + plus the size of the interrupt specifier.
>>> + linux,pci-domain -- the domain of the host controller.
>>> +
>>> +Optional Properties:
>>> + clocks -- list of clock phandles. If specified, this should list one
>>> + clock.
>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>> + and the name of the clock is expected to be "sw_pcie".
>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>> + specified with a n-tuple. Dma-regions describe the inbound
>>> + accesses from EP to RC; it translates the pci address that the
>>> + EP "sees" to the CPU address in memory. This property is needed
>>> + because the design of the Brcmstb memory subsystem often precludes
>>> + idenity-mapping between CPU address space and PCIe address space.
>>> + Each range is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>
>> There's no need to describe standard properties. Just put whatever is
>> specific to your platform. That applies throughout this doc.
>>
> Will fix.
>
>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>> + will attempt to use its built in MSI controller.
>>> + msi-controller -- this property should only be specified if the
>>> + PCIe controller is using its internal MSI controller.
>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>> + brcm,gen -- (integer) indicates desired generation of link:
>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>
>> We have a standard property for this IIRC.
>>
> Yes, BrianN pointed that out and it will be fixed.
>
>>> + supply-names -- the names of voltage regulators that the root
>>> + complex should turn off/on/on on suspend/resume/boot. This
>>> + is a string list.
>>> + supplies -- A collection of phandles to a regulator nodes, see
>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>> + bindings. The number and order of phandles must match
>>> + exactly the number of strings in the "supply-names" property.
>>
>> This is not the regulator binding. Use the standard binding.
>>
> The reason we do it this way is because the PCIe controller does not
> know or care what the names of the supplies are, or how many there
> will be. The list of regulators can be different for each board we
> support, as these regulators turn on/off the downstream EP device.
> All the PCIe controller does is turn on/off this list of regulators
> when booting,resuming/suspending.
>
> An alternative would have the node specifying the standard properties
>
> xyz-supply = <&xyz_reg>;
> abc-supply = <&abc_reg>;
> pdq-supply = <&pdq_reg>;
> ...
>
> and then have this driver search all of the properties in the PCIe
> node for names matching /-supply$/, and then create a list of phandles
> from that. Is that what you would like?
Really, you should have child nodes of the PCIe devices and have the
supplies in there.
The driver could do what you describe, but you've still got to define
the names here.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 21:49 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-19 21:49 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>> node can be used by almost all Broadcom settop box chips, using
>>> ARM, ARM64, or MIPS CPU architectures.
>>>
>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>> ---
>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>> 1 file changed, 106 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> new file mode 100644
>>> index 0000000..2f699da
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>> @@ -0,0 +1,106 @@
>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>> +We don't; this line is erroneous.
>>> +Introduction:
>>> + The brcmstb host controller closely follows the example set in
>>> +
>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>> +
>>> + The rest of this document explains some added customizations and
>>> + offers an example Brcmstb PCIe host controller DT node.
>>> +
>>> +Required Properties:
>>> + reg -- the register start address and length for the PCIe block.
>>> + Additional start,length pairs may be specified for clock addresses.
>>
>> Kind of vague and why do you need clock addresses and the clock binding?
>>
> We don't; this line is erroneous and will be removed.
>
>> Also, typically the config space is defined here? Is that missing or you
>> don't support memory mapped config space?
>>
> We do not support memory mapped config space.
>
>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>> + the PCI host controller and the second is for MSI if the built-in
>>> + MSI controller is to be used.
>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>> + or "brcm,bcm7278-pcie".
>>
>> One compatible per line.
>>
> Will fix.
>
>>> + #address-cells -- the number of address cells for PCI-space.
>>> + #size-cells -- the number of size cells for PCI-space.
>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>> + controller. Each outbound window is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>> + Due to hardware limitations, there may be a maximum of four
>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>
>> How many cells?
>>
> This line will be removed.
Humm, why? You need it to have interrupt-map. You just need to say
what the value is, not what the property is.
>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>> + the legacy interrupt number [1..4].
>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>> + plus the size of the interrupt specifier.
>>> + linux,pci-domain -- the domain of the host controller.
>>> +
>>> +Optional Properties:
>>> + clocks -- list of clock phandles. If specified, this should list one
>>> + clock.
>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>> + and the name of the clock is expected to be "sw_pcie".
>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>> + specified with a n-tuple. Dma-regions describe the inbound
>>> + accesses from EP to RC; it translates the pci address that the
>>> + EP "sees" to the CPU address in memory. This property is needed
>>> + because the design of the Brcmstb memory subsystem often precludes
>>> + idenity-mapping between CPU address space and PCIe address space.
>>> + Each range is described by a n-tuple:
>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>> + and two cells for the 64-bit PCIe address.
>>> + (x cells) -- CPU/System start address, number of cells is determined
>>> + by the parent node's #address-cells.
>>> + (y cells) -- Size of region, number of cells determined by the
>>> + parent node's #size-cells.
>>
>> There's no need to describe standard properties. Just put whatever is
>> specific to your platform. That applies throughout this doc.
>>
> Will fix.
>
>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>> + will attempt to use its built in MSI controller.
>>> + msi-controller -- this property should only be specified if the
>>> + PCIe controller is using its internal MSI controller.
>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>> + brcm,gen -- (integer) indicates desired generation of link:
>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>
>> We have a standard property for this IIRC.
>>
> Yes, BrianN pointed that out and it will be fixed.
>
>>> + supply-names -- the names of voltage regulators that the root
>>> + complex should turn off/on/on on suspend/resume/boot. This
>>> + is a string list.
>>> + supplies -- A collection of phandles to a regulator nodes, see
>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>> + bindings. The number and order of phandles must match
>>> + exactly the number of strings in the "supply-names" property.
>>
>> This is not the regulator binding. Use the standard binding.
>>
> The reason we do it this way is because the PCIe controller does not
> know or care what the names of the supplies are, or how many there
> will be. The list of regulators can be different for each board we
> support, as these regulators turn on/off the downstream EP device.
> All the PCIe controller does is turn on/off this list of regulators
> when booting,resuming/suspending.
>
> An alternative would have the node specifying the standard properties
>
> xyz-supply = <&xyz_reg>;
> abc-supply = <&abc_reg>;
> pdq-supply = <&pdq_reg>;
> ...
>
> and then have this driver search all of the properties in the PCIe
> node for names matching /-supply$/, and then create a list of phandles
> from that. Is that what you would like?
Really, you should have child nodes of the PCIe devices and have the
supplies in there.
The driver could do what you describe, but you've still got to define
the names here.
Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
2017-10-19 21:49 ` Rob Herring
(?)
(?)
@ 2017-10-19 21:58 ` Florian Fainelli
-1 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-19 21:58 UTC (permalink / raw)
To: Rob Herring, Jim Quinlan
Cc: linux-kernel, Mark Rutland, Linux-MIPS, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On 10/19/2017 02:49 PM, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
While that would be technically more correct this poses a number of issues:
- there is precedence in that area, and you already Acked binding
documents proposing the same thing:
* Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
c26ebe98a103479dae9284fe0a86a95af4a5cd46)
* Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
(which may indicate those should also be corrected, at the possible
expense of creating incompatibilities)
- there is a chicken and egg problem, you can't detect the EP without
turning its regulator on, and if you can't create a pci_device, you
certainly won't be able to associate it with an device_node counterpart
- PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
that would be guaranteed to match any physically attached PCIE EP which
is discovered by the PCI bus layer (and then back to issue #2)
If we can solve #2 and #3, it would be reasonable to move the regulator
to a PCIE EP node. Ideally, we may want the generic PCI layer to be
responsible for managing regulators within pci_enable_device() and
pci_disable_device() for instance?
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
>
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 21:58 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-19 21:58 UTC (permalink / raw)
To: Rob Herring, Jim Quinlan
Cc: linux-kernel, Mark Rutland, Linux-MIPS, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On 10/19/2017 02:49 PM, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
While that would be technically more correct this poses a number of issues:
- there is precedence in that area, and you already Acked binding
documents proposing the same thing:
* Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
c26ebe98a103479dae9284fe0a86a95af4a5cd46)
* Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
(which may indicate those should also be corrected, at the possible
expense of creating incompatibilities)
- there is a chicken and egg problem, you can't detect the EP without
turning its regulator on, and if you can't create a pci_device, you
certainly won't be able to associate it with an device_node counterpart
- PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
that would be guaranteed to match any physically attached PCIE EP which
is discovered by the PCI bus layer (and then back to issue #2)
If we can solve #2 and #3, it would be reasonable to move the regulator
to a PCIE EP node. Ideally, we may want the generic PCI layer to be
responsible for managing regulators within pci_enable_device() and
pci_disable_device() for instance?
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
>
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 21:58 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-19 21:58 UTC (permalink / raw)
To: Rob Herring, Jim Quinlan
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On 10/19/2017 02:49 PM, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
While that would be technically more correct this poses a number of issues:
- there is precedence in that area, and you already Acked binding
documents proposing the same thing:
* Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
c26ebe98a103479dae9284fe0a86a95af4a5cd46)
* Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
(which may indicate those should also be corrected, at the possible
expense of creating incompatibilities)
- there is a chicken and egg problem, you can't detect the EP without
turning its regulator on, and if you can't create a pci_device, you
certainly won't be able to associate it with an device_node counterpart
- PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
that would be guaranteed to match any physically attached PCIE EP which
is discovered by the PCI bus layer (and then back to issue #2)
If we can solve #2 and #3, it would be reasonable to move the regulator
to a PCIE EP node. Ideally, we may want the generic PCI layer to be
responsible for managing regulators within pci_enable_device() and
pci_disable_device() for instance?
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 21:58 ` Florian Fainelli
0 siblings, 0 replies; 146+ messages in thread
From: Florian Fainelli @ 2017-10-19 21:58 UTC (permalink / raw)
To: linux-arm-kernel
On 10/19/2017 02:49 PM, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
While that would be technically more correct this poses a number of issues:
- there is precedence in that area, and you already Acked binding
documents proposing the same thing:
* Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
c26ebe98a103479dae9284fe0a86a95af4a5cd46)
* Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
(which may indicate those should also be corrected, at the possible
expense of creating incompatibilities)
- there is a chicken and egg problem, you can't detect the EP without
turning its regulator on, and if you can't create a pci_device, you
certainly won't be able to associate it with an device_node counterpart
- PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
that would be guaranteed to match any physically attached PCIE EP which
is discovered by the PCI bus layer (and then back to issue #2)
If we can solve #2 and #3, it would be reasonable to move the regulator
to a PCIE EP node. Ideally, we may want the generic PCI layer to be
responsible for managing regulators within pci_enable_device() and
pci_disable_device() for instance?
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
>
--
Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-19 9:16 ` Christoph Hellwig
(?)
@ 2017-10-19 22:47 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 22:47 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robin Murphy, linux-kernel, Mark Rutland, linux-mips,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Marek Szyprowski, iommu
On Thu, Oct 19, 2017 at 5:16 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
>> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
>> dma-ranges given in the PCIe DT node, and translate from system memory
>> addresses to pci-space addresses, and vice versa. As long as people
>> are using the DMA API it should work. It works for all of the ARM,
>> ARM64, and MIPS Broadcom systems I've tested, using eight different EP
>> devices. Note that I am not thrilled to be advocating this mechanism
>> but it seemed the best alternative.
>
> Say we are using your original example ranges:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> and now you get a dma mapping request for physical addresses
> 3fffff00 to 4000000f, which would span two of your ranges. How
> is this going to work?
The only way to prevent this is to reserve a single page at the end of
the first memory region of any pair that are adjacent in physical
memory. A hack, yes, but I don't see an easier way out of this. Many
if not most of our boards do not have adjacent regions and would not
need this.
Overriding phys_to_dma/dma_to_phys comes with the same overlap problem
(MIPS solution and possible ARM/ARM64 solution).
>
>> I would prefer that the same code work for all three architectures.
>> What I would like from ARM/ARM64 is the ability to override
>> phys_to_dma() and dma_to_phys(); I thought the chances of that being
>> accepted would be slim. But you are right, I should ask the
>> maintainers.
>
> It is still better than trying to stack dma ops, which is a receipe
> for problems down the road.
Let me send out V2 of my patchset and also send it to the ARM/ARM64
maintainers as you suggested; perhaps there is an alternative.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-19 22:47 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 22:47 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, linux-arm-kernel, Marek Szyprowski
On Thu, Oct 19, 2017 at 5:16 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
>> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
>> dma-ranges given in the PCIe DT node, and translate from system memory
>> addresses to pci-space addresses, and vice versa. As long as people
>> are using the DMA API it should work. It works for all of the ARM,
>> ARM64, and MIPS Broadcom systems I've tested, using eight different EP
>> devices. Note that I am not thrilled to be advocating this mechanism
>> but it seemed the best alternative.
>
> Say we are using your original example ranges:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> and now you get a dma mapping request for physical addresses
> 3fffff00 to 4000000f, which would span two of your ranges. How
> is this going to work?
The only way to prevent this is to reserve a single page at the end of
the first memory region of any pair that are adjacent in physical
memory. A hack, yes, but I don't see an easier way out of this. Many
if not most of our boards do not have adjacent regions and would not
need this.
Overriding phys_to_dma/dma_to_phys comes with the same overlap problem
(MIPS solution and possible ARM/ARM64 solution).
>
>> I would prefer that the same code work for all three architectures.
>> What I would like from ARM/ARM64 is the ability to override
>> phys_to_dma() and dma_to_phys(); I thought the chances of that being
>> accepted would be slim. But you are right, I should ask the
>> maintainers.
>
> It is still better than trying to stack dma ops, which is a receipe
> for problems down the road.
Let me send out V2 of my patchset and also send it to the ARM/ARM64
maintainers as you suggested; perhaps there is an alternative.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-19 22:47 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 22:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 19, 2017 at 5:16 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Oct 18, 2017 at 10:41:17AM -0400, Jim Quinlan wrote:
>> That's what brcm_to_{pci,cpu} are for -- they keep a list of the
>> dma-ranges given in the PCIe DT node, and translate from system memory
>> addresses to pci-space addresses, and vice versa. As long as people
>> are using the DMA API it should work. It works for all of the ARM,
>> ARM64, and MIPS Broadcom systems I've tested, using eight different EP
>> devices. Note that I am not thrilled to be advocating this mechanism
>> but it seemed the best alternative.
>
> Say we are using your original example ranges:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> and now you get a dma mapping request for physical addresses
> 3fffff00 to 4000000f, which would span two of your ranges. How
> is this going to work?
The only way to prevent this is to reserve a single page at the end of
the first memory region of any pair that are adjacent in physical
memory. A hack, yes, but I don't see an easier way out of this. Many
if not most of our boards do not have adjacent regions and would not
need this.
Overriding phys_to_dma/dma_to_phys comes with the same overlap problem
(MIPS solution and possible ARM/ARM64 solution).
>
>> I would prefer that the same code work for all three architectures.
>> What I would like from ARM/ARM64 is the ability to override
>> phys_to_dma() and dma_to_phys(); I thought the chances of that being
>> accepted would be slim. But you are right, I should ask the
>> maintainers.
>
> It is still better than trying to stack dma ops, which is a receipe
> for problems down the road.
Let me send out V2 of my patchset and also send it to the ARM/ARM64
maintainers as you suggested; perhaps there is an alternative.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 23:04 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 23:04 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, Mark Rutland, Linux-MIPS, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Thu, Oct 19, 2017 at 5:49 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
Okay, I got this from
https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping which
says that
"First you'll notice that PCI interrupt numbers use only one cell,
unlike the system interrupt controller which uses 2 cells; one for the
irq number, and one for flags. PCI only needs one cell for interrupts
because PCI interrupts are specified to always be level-low
sensitive." Is that not the convention for legacy PCI interrupts?
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 23:04 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 23:04 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Linux-MIPS,
Florian Fainelli, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thu, Oct 19, 2017 at 5:49 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
Okay, I got this from
https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping which
says that
"First you'll notice that PCI interrupt numbers use only one cell,
unlike the system interrupt controller which uses 2 cells; one for the
irq number, and one for flags. PCI only needs one cell for interrupts
because PCI interrupts are specified to always be level-low
sensitive." Is that not the convention for legacy PCI interrupts?
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 23:04 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 23:04 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Thu, Oct 19, 2017 at 5:49 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
Okay, I got this from
https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping which
says that
"First you'll notice that PCI interrupt numbers use only one cell,
unlike the system interrupt controller which uses 2 cells; one for the
irq number, and one for flags. PCI only needs one cell for interrupts
because PCI interrupts are specified to always be level-low
sensitive." Is that not the convention for legacy PCI interrupts?
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 23:04 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 23:04 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, Mark Rutland, Linux-MIPS, Florian Fainelli,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
On Thu, Oct 19, 2017 at 5:49 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
Okay, I got this from
https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping which
says that
"First you'll notice that PCI interrupt numbers use only one cell,
unlike the system interrupt controller which uses 2 cells; one for the
irq number, and one for flags. PCI only needs one cell for interrupts
because PCI interrupts are specified to always be level-low
sensitive." Is that not the convention for legacy PCI interrupts?
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-19 23:04 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-19 23:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 19, 2017 at 5:49 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Oct 11, 2017 at 06:34:22PM -0400, Jim Quinlan wrote:
>>>> The DT bindings description of the Brcmstb PCIe device is described. This
>>>> node can be used by almost all Broadcom settop box chips, using
>>>> ARM, ARM64, or MIPS CPU architectures.
>>>>
>>>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>>>> ---
>>>> .../devicetree/bindings/pci/brcmstb-pci.txt | 106 +++++++++++++++++++++
>>>> 1 file changed, 106 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> new file mode 100644
>>>> index 0000000..2f699da
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>>>> @@ -0,0 +1,106 @@
>>>> +Brcmstb PCIe Host Controller Device Tree Bindings
>>>> +We don't; this line is erroneous.
>>>> +Introduction:
>>>> + The brcmstb host controller closely follows the example set in
>>>> +
>>>> + [1] http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>> +
>>>> + The rest of this document explains some added customizations and
>>>> + offers an example Brcmstb PCIe host controller DT node.
>>>> +
>>>> +Required Properties:
>>>> + reg -- the register start address and length for the PCIe block.
>>>> + Additional start,length pairs may be specified for clock addresses.
>>>
>>> Kind of vague and why do you need clock addresses and the clock binding?
>>>
>> We don't; this line is erroneous and will be removed.
>>
>>> Also, typically the config space is defined here? Is that missing or you
>>> don't support memory mapped config space?
>>>
>> We do not support memory mapped config space.
>>
>>>> + interrupts -- two interrupts are specified; the first interrupt is for
>>>> + the PCI host controller and the second is for MSI if the built-in
>>>> + MSI controller is to be used.
>>>> + interrupt-names -- names of the interrupts (above): "pcie" and "msi".
>>>> + compatible -- must be one of: "brcm,bcm7425-pcie", "brcm,bcm7435-pcie",
>>>> + or "brcm,bcm7278-pcie".
>>>
>>> One compatible per line.
>>>
>> Will fix.
>>
>>>> + #address-cells -- the number of address cells for PCI-space.
>>>> + #size-cells -- the number of size cells for PCI-space.
>>>> + ranges -- See [1]; a specification of the outbound windows for the host
>>>> + controller. Each outbound window is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>> + Due to hardware limitations, there may be a maximum of four
>>>> + non-contiguous ranges specified.We don't; this line is erroneous.
>>>> + #interrupt-cells -- number of cells used to describe the interrupt.
>>>
>>> How many cells?
>>>
>> This line will be removed.
>
> Humm, why? You need it to have interrupt-map. You just need to say
> what the value is, not what the property is.
Okay, I got this from
https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping which
says that
"First you'll notice that PCI interrupt numbers use only one cell,
unlike the system interrupt controller which uses 2 cells; one for the
irq number, and one for flags. PCI only needs one cell for interrupts
because PCI interrupts are specified to always be level-low
sensitive." Is that not the convention for legacy PCI interrupts?
>
>>>> + interrupt-map-mask -- see [1]; four cells, the first three are zero
>>>> + for our uses and the fourth cell is the mask (val = 0x7) for
>>>> + the legacy interrupt number [1..4].
>>>> + interrupt-map -- See [1]; there are four interrupts (INTA, INTB,
>>>> + INTC, and INTD) to be mapped; each interrupt requires 5 cells
>>>> + plus the size of the interrupt specifier.
>>>> + linux,pci-domain -- the domain of the host controller.
>>>> +
>>>> +Optional Properties:
>>>> + clocks -- list of clock phandles. If specified, this should list one
>>>> + clock.
>>>> + clock-names -- the "local" names of the clocks specified in 'clocks'. Note
>>>> + that if the 'clocks' property is given, 'clock-names' is mandatory,
>>>> + and the name of the clock is expected to be "sw_pcie".
>>>> + dma-ranges -- Similar in structure to ranges, each dma region is
>>>> + specified with a n-tuple. Dma-regions describe the inbound
>>>> + accesses from EP to RC; it translates the pci address that the
>>>> + EP "sees" to the CPU address in memory. This property is needed
>>>> + because the design of the Brcmstb memory subsystem often precludes
>>>> + idenity-mapping between CPU address space and PCIe address space.
>>>> + Each range is described by a n-tuple:
>>>> + (3 cells) -- PCIe space start address; one cell for attributes
>>>> + and two cells for the 64-bit PCIe address.
>>>> + (x cells) -- CPU/System start address, number of cells is determined
>>>> + by the parent node's #address-cells.
>>>> + (y cells) -- Size of region, number of cells determined by the
>>>> + parent node's #size-cells.
>>>
>>> There's no need to describe standard properties. Just put whatever is
>>> specific to your platform. That applies throughout this doc.
>>>
>> Will fix.
>>
>>>> + msi-parent -- if MSI is to be used, this must be a phandle to the
>>>> + msi-parent. If this prop is set to the phandle of the PCIe
>>>> + node, or if the msi-parent prop is missing, the PCIE controller
>>>> + will attempt to use its built in MSI controller.
>>>> + msi-controller -- this property should only be specified if the
>>>> + PCIe controller is using its internal MSI controller.
>>>> + brcm,ssc -- (boolean) indicates usage of spread-spectrum clocking.
>>>> + brcm,gen -- (integer) indicates desired generation of link:
>>>> + 1 => 2.5 Gbps, 2 => 5.0 Gbps, 3 => 8.0 Gbps.
>>>
>>> We have a standard property for this IIRC.
>>>
>> Yes, BrianN pointed that out and it will be fixed.
>>
>>>> + supply-names -- the names of voltage regulators that the root
>>>> + complex should turn off/on/on on suspend/resume/boot. This
>>>> + is a string list.
>>>> + supplies -- A collection of phandles to a regulator nodes, see
>>>> + Documentation/devicetree/bindings/regulator/ for specificWe don't; this line is erroneous.
>>>> + bindings. The number and order of phandles must match
>>>> + exactly the number of strings in the "supply-names" property.
>>>
>>> This is not the regulator binding. Use the standard binding.
>>>
>> The reason we do it this way is because the PCIe controller does not
>> know or care what the names of the supplies are, or how many there
>> will be. The list of regulators can be different for each board we
>> support, as these regulators turn on/off the downstream EP device.
>> All the PCIe controller does is turn on/off this list of regulators
>> when booting,resuming/suspending.
>>
>> An alternative would have the node specifying the standard properties
>>
>> xyz-supply = <&xyz_reg>;
>> abc-supply = <&abc_reg>;
>> pdq-supply = <&pdq_reg>;
>> ...
>>
>> and then have this driver search all of the properties in the PCIe
>> node for names matching /-supply$/, and then create a list of phandles
>> from that. Is that what you would like?
>
> Really, you should have child nodes of the PCIe devices and have the
> supplies in there.
>
> The driver could do what you describe, but you've still got to define
> the names here.
>
> Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 7:37 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 7:37 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
linux-mips, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
> The only way to prevent this is to reserve a single page at the end of
> the first memory region of any pair that are adjacent in physical
> memory. A hack, yes, but I don't see an easier way out of this. Many
> if not most of our boards do not have adjacent regions and would not
> need this.
dma mappings can be much larger than a single page. For the block
world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 7:37 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 7:37 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-mips-6z/3iImG2C8G8FEW9MqTrA, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Marek Szyprowski,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
> The only way to prevent this is to reserve a single page at the end of
> the first memory region of any pair that are adjacent in physical
> memory. A hack, yes, but I don't see an easier way out of this. Many
> if not most of our boards do not have adjacent regions and would not
> need this.
dma mappings can be much larger than a single page. For the block
world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 7:37 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 7:37 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, linux-mips, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
> The only way to prevent this is to reserve a single page at the end of
> the first memory region of any pair that are adjacent in physical
> memory. A hack, yes, but I don't see an easier way out of this. Many
> if not most of our boards do not have adjacent regions and would not
> need this.
dma mappings can be much larger than a single page. For the block
world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 7:37 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 7:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
> The only way to prevent this is to reserve a single page at the end of
> the first memory region of any pair that are adjacent in physical
> memory. A hack, yes, but I don't see an easier way out of this. Many
> if not most of our boards do not have adjacent regions and would not
> need this.
dma mappings can be much larger than a single page. For the block
world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 14:41 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-20 14:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robin Murphy, linux-kernel, Mark Rutland, Linux-MIPS,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Marek Szyprowski, iommu
On Fri, Oct 20, 2017 at 3:37 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
>> The only way to prevent this is to reserve a single page at the end of
>> the first memory region of any pair that are adjacent in physical
>> memory. A hack, yes, but I don't see an easier way out of this. Many
>> if not most of our boards do not have adjacent regions and would not
>> need this.
>
> dma mappings can be much larger than a single page. For the block
> world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer.
I am not sure I understand your comment -- the size of the request
shouldn't be a factor. Let's look at your example of the DMA request
of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
pages. If we block out the last page [0x3ffff000..0x3fffffff] from
what is available, there is no 15 page span that can happen across the
0x40000000 boundary. For SG, there can be no merge that connects a
page from one region to another region. Can you give an example of
the scenario you are thinking of?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 14:41 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-20 14:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robin Murphy, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
Rob Herring, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Marek Szyprowski,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
On Fri, Oct 20, 2017 at 3:37 AM, Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> wrote:
> On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
>> The only way to prevent this is to reserve a single page at the end of
>> the first memory region of any pair that are adjacent in physical
>> memory. A hack, yes, but I don't see an easier way out of this. Many
>> if not most of our boards do not have adjacent regions and would not
>> need this.
>
> dma mappings can be much larger than a single page. For the block
> world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer.
I am not sure I understand your comment -- the size of the request
shouldn't be a factor. Let's look at your example of the DMA request
of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
pages. If we block out the last page [0x3ffff000..0x3fffffff] from
what is available, there is no 15 page span that can happen across the
0x40000000 boundary. For SG, there can be no merge that connects a
page from one region to another region. Can you give an example of
the scenario you are thinking of?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 14:41 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-20 14:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, linux-arm-kernel, Marek Szyprowski
On Fri, Oct 20, 2017 at 3:37 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
>> The only way to prevent this is to reserve a single page at the end of
>> the first memory region of any pair that are adjacent in physical
>> memory. A hack, yes, but I don't see an easier way out of this. Many
>> if not most of our boards do not have adjacent regions and would not
>> need this.
>
> dma mappings can be much larger than a single page. For the block
> world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer.
I am not sure I understand your comment -- the size of the request
shouldn't be a factor. Let's look at your example of the DMA request
of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
pages. If we block out the last page [0x3ffff000..0x3fffffff] from
what is available, there is no 15 page span that can happen across the
0x40000000 boundary. For SG, there can be no merge that connects a
page from one region to another region. Can you give an example of
the scenario you are thinking of?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 14:41 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-20 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 20, 2017 at 3:37 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Thu, Oct 19, 2017 at 06:47:45PM -0400, Jim Quinlan wrote:
>> The only way to prevent this is to reserve a single page at the end of
>> the first memory region of any pair that are adjacent in physical
>> memory. A hack, yes, but I don't see an easier way out of this. Many
>> if not most of our boards do not have adjacent regions and would not
>> need this.
>
> dma mappings can be much larger than a single page. For the block
> world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer.
I am not sure I understand your comment -- the size of the request
shouldn't be a factor. Let's look at your example of the DMA request
of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
pages. If we block out the last page [0x3ffff000..0x3fffffff] from
what is available, there is no 15 page span that can happen across the
0x40000000 boundary. For SG, there can be no merge that connects a
page from one region to another region. Can you give an example of
the scenario you are thinking of?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-20 14:41 ` Jim Quinlan
(?)
(?)
@ 2017-10-20 14:57 ` Christoph Hellwig
-1 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 14:57 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> I am not sure I understand your comment -- the size of the request
> shouldn't be a factor. Let's look at your example of the DMA request
> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> what is available, there is no 15 page span that can happen across the
> 0x40000000 boundary. For SG, there can be no merge that connects a
> page from one region to another region. Can you give an example of
> the scenario you are thinking of?
What prevents a merge from say the regions of
0....3fffffff and 40000000....7fffffff?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 14:57 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 14:57 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> I am not sure I understand your comment -- the size of the request
> shouldn't be a factor. Let's look at your example of the DMA request
> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> what is available, there is no 15 page span that can happen across the
> 0x40000000 boundary. For SG, there can be no merge that connects a
> page from one region to another region. Can you give an example of
> the scenario you are thinking of?
What prevents a merge from say the regions of
0....3fffffff and 40000000....7fffffff?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 14:57 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 14:57 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> I am not sure I understand your comment -- the size of the request
> shouldn't be a factor. Let's look at your example of the DMA request
> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> what is available, there is no 15 page span that can happen across the
> 0x40000000 boundary. For SG, there can be no merge that connects a
> page from one region to another region. Can you give an example of
> the scenario you are thinking of?
What prevents a merge from say the regions of
0....3fffffff and 40000000....7fffffff?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 14:57 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 14:57 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> I am not sure I understand your comment -- the size of the request
> shouldn't be a factor. Let's look at your example of the DMA request
> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> what is available, there is no 15 page span that can happen across the
> 0x40000000 boundary. For SG, there can be no merge that connects a
> page from one region to another region. Can you give an example of
> the scenario you are thinking of?
What prevents a merge from say the regions of
0....3fffffff and 40000000....7fffffff?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-20 14:57 ` Christoph Hellwig
(?)
@ 2017-10-20 15:27 ` Jim Quinlan
-1 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-20 15:27 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robin Murphy, linux-kernel, Mark Rutland, Linux-MIPS,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Marek Szyprowski, iommu
On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> I am not sure I understand your comment -- the size of the request
>> shouldn't be a factor. Let's look at your example of the DMA request
>> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> what is available, there is no 15 page span that can happen across the
>> 0x40000000 boundary. For SG, there can be no merge that connects a
>> page from one region to another region. Can you give an example of
>> the scenario you are thinking of?
>
> What prevents a merge from say the regions of
> 0....3fffffff and 40000000....7fffffff?
Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
the original example, we now have to tell Linux that these are now our
effective memory regions:
memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
This leaves a one-page gap between phsyical memory regions which would
normally be contiguous. One cannot have a dma alloc that spans any two
regions. This is a drastic step, but I don't see an alternative.
Perhaps I may be missing what you are saying...
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 15:27 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-20 15:27 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, linux-arm-kernel, Marek Szyprowski
On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> I am not sure I understand your comment -- the size of the request
>> shouldn't be a factor. Let's look at your example of the DMA request
>> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> what is available, there is no 15 page span that can happen across the
>> 0x40000000 boundary. For SG, there can be no merge that connects a
>> page from one region to another region. Can you give an example of
>> the scenario you are thinking of?
>
> What prevents a merge from say the regions of
> 0....3fffffff and 40000000....7fffffff?
Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
the original example, we now have to tell Linux that these are now our
effective memory regions:
memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
This leaves a one-page gap between phsyical memory regions which would
normally be contiguous. One cannot have a dma alloc that spans any two
regions. This is a drastic step, but I don't see an alternative.
Perhaps I may be missing what you are saying...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 15:27 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-20 15:27 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> I am not sure I understand your comment -- the size of the request
>> shouldn't be a factor. Let's look at your example of the DMA request
>> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> what is available, there is no 15 page span that can happen across the
>> 0x40000000 boundary. For SG, there can be no merge that connects a
>> page from one region to another region. Can you give an example of
>> the scenario you are thinking of?
>
> What prevents a merge from say the regions of
> 0....3fffffff and 40000000....7fffffff?
Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
the original example, we now have to tell Linux that these are now our
effective memory regions:
memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
This leaves a one-page gap between phsyical memory regions which would
normally be contiguous. One cannot have a dma alloc that spans any two
regions. This is a drastic step, but I don't see an alternative.
Perhaps I may be missing what you are saying...
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-20 15:27 ` Jim Quinlan
(?)
(?)
@ 2017-10-20 16:17 ` Christoph Hellwig
-1 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 16:17 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Fri, Oct 20, 2017 at 11:27:41AM -0400, Jim Quinlan wrote:
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Ok, IFF we are guranteed to always have a gap between physical memory
locations we are fine indeed.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 16:17 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 16:17 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Fri, Oct 20, 2017 at 11:27:41AM -0400, Jim Quinlan wrote:
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Ok, IFF we are guranteed to always have a gap between physical memory
locations we are fine indeed.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 16:17 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 16:17 UTC (permalink / raw)
To: Jim Quinlan
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
On Fri, Oct 20, 2017 at 11:27:41AM -0400, Jim Quinlan wrote:
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Ok, IFF we are guranteed to always have a gap between physical memory
locations we are fine indeed.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-20 16:17 ` Christoph Hellwig
0 siblings, 0 replies; 146+ messages in thread
From: Christoph Hellwig @ 2017-10-20 16:17 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 20, 2017 at 11:27:41AM -0400, Jim Quinlan wrote:
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Ok, IFF we are guranteed to always have a gap between physical memory
locations we are fine indeed.
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 17:27 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-20 17:27 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, Jim Quinlan, linux-kernel, Mark Rutland, Linux-MIPS,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, linux-arm-kernel, Matthias Kaehlcke
Hi,
On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
> On 10/19/2017 02:49 PM, Rob Herring wrote:
> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
> >>> This is not the regulator binding. Use the standard binding.
> >>>
> >> The reason we do it this way is because the PCIe controller does not
> >> know or care what the names of the supplies are, or how many there
> >> will be. The list of regulators can be different for each board we
> >> support, as these regulators turn on/off the downstream EP device.
> >> All the PCIe controller does is turn on/off this list of regulators
> >> when booting,resuming/suspending.
> >>
> >> An alternative would have the node specifying the standard properties
> >>
> >> xyz-supply = <&xyz_reg>;
> >> abc-supply = <&abc_reg>;
> >> pdq-supply = <&pdq_reg>;
> >> ...
> >>
> >> and then have this driver search all of the properties in the PCIe
> >> node for names matching /-supply$/, and then create a list of phandles
> >> from that. Is that what you would like?
> >
> > Really, you should have child nodes of the PCIe devices and have the
> > supplies in there.
>
> While that would be technically more correct this poses a number of issues:
>
> - there is precedence in that area, and you already Acked binding
> documents proposing the same thing:
> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
I can actually speak to the Rockchip binding a bit :)
It actually has a mixture of true controller regulators (e.g., the 1.8V
and 0.9V regulators power analog portions of the SoC's PCIe logic) and
controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
have been misused to represent a little of both, since the regulator
framework is actually quite flexible ;)
That may or may not help, but they are at least partially correct.
The Freescale one does look like it's plainly *not* about the root
controller.
Also, those rails *are* all fairly well defined by the various PCIe
electromechanical specifications, so isn't it reasonable to expect that
a controller can optionally control power for 1 of each of the standard
power types? Or do we really want to represent the flexibility that
there can be up to N of each type for N endpoints?
As a side note: it's also been pretty tough to get the power sequencing
requirements represented correctly for some PCIe endpoints. I've tried
to make use of this previously, but the series took so long (>1 year and
counting!) my team lost interest:
[PATCH v16 2/7] power: add power sequence library
https://www.spinics.net/lists/linux-usb/msg158452.html
It doesn't really solve all of this problem, but it could be worth
looking at.
> (which may indicate those should also be corrected, at the possible
> expense of creating incompatibilities)
If a better way is developed, we can always augment the bindings. The
current bindings aren't that hard to maintain as "deprecated backups."
> - there is a chicken and egg problem, you can't detect the EP without
> turning its regulator on, and if you can't create a pci_device, you
> certainly won't be able to associate it with an device_node counterpart
That's definitely a major problem driving some of the current bindings.
We're just not set up to walk the child devices if we can't probe them.
> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
> that would be guaranteed to match any physically attached PCIE EP which
> is discovered by the PCI bus layer (and then back to issue #2)
Technically, you *can* walk the DT (i.e., 'device_node's) without having
pci_dev's for each yet. Something like of_pci_find_child_device() would
do it. But that still seems kind of wonky, and it's currently neither
precise enough nor flexible enough for this, I don't think.
Brian
> If we can solve #2 and #3, it would be reasonable to move the regulator
> to a PCIE EP node. Ideally, we may want the generic PCI layer to be
> responsible for managing regulators within pci_enable_device() and
> pci_disable_device() for instance?
>
> >
> > The driver could do what you describe, but you've still got to define
> > the names here.
> >
> > Rob
> >
>
>
> --
> Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 17:27 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-20 17:27 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, Jim Quinlan, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mark Rutland, Linux-MIPS, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Matthias Kaehlcke
Hi,
On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
> On 10/19/2017 02:49 PM, Rob Herring wrote:
> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >>> This is not the regulator binding. Use the standard binding.
> >>>
> >> The reason we do it this way is because the PCIe controller does not
> >> know or care what the names of the supplies are, or how many there
> >> will be. The list of regulators can be different for each board we
> >> support, as these regulators turn on/off the downstream EP device.
> >> All the PCIe controller does is turn on/off this list of regulators
> >> when booting,resuming/suspending.
> >>
> >> An alternative would have the node specifying the standard properties
> >>
> >> xyz-supply = <&xyz_reg>;
> >> abc-supply = <&abc_reg>;
> >> pdq-supply = <&pdq_reg>;
> >> ...
> >>
> >> and then have this driver search all of the properties in the PCIe
> >> node for names matching /-supply$/, and then create a list of phandles
> >> from that. Is that what you would like?
> >
> > Really, you should have child nodes of the PCIe devices and have the
> > supplies in there.
>
> While that would be technically more correct this poses a number of issues:
>
> - there is precedence in that area, and you already Acked binding
> documents proposing the same thing:
> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
I can actually speak to the Rockchip binding a bit :)
It actually has a mixture of true controller regulators (e.g., the 1.8V
and 0.9V regulators power analog portions of the SoC's PCIe logic) and
controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
have been misused to represent a little of both, since the regulator
framework is actually quite flexible ;)
That may or may not help, but they are at least partially correct.
The Freescale one does look like it's plainly *not* about the root
controller.
Also, those rails *are* all fairly well defined by the various PCIe
electromechanical specifications, so isn't it reasonable to expect that
a controller can optionally control power for 1 of each of the standard
power types? Or do we really want to represent the flexibility that
there can be up to N of each type for N endpoints?
As a side note: it's also been pretty tough to get the power sequencing
requirements represented correctly for some PCIe endpoints. I've tried
to make use of this previously, but the series took so long (>1 year and
counting!) my team lost interest:
[PATCH v16 2/7] power: add power sequence library
https://www.spinics.net/lists/linux-usb/msg158452.html
It doesn't really solve all of this problem, but it could be worth
looking at.
> (which may indicate those should also be corrected, at the possible
> expense of creating incompatibilities)
If a better way is developed, we can always augment the bindings. The
current bindings aren't that hard to maintain as "deprecated backups."
> - there is a chicken and egg problem, you can't detect the EP without
> turning its regulator on, and if you can't create a pci_device, you
> certainly won't be able to associate it with an device_node counterpart
That's definitely a major problem driving some of the current bindings.
We're just not set up to walk the child devices if we can't probe them.
> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
> that would be guaranteed to match any physically attached PCIE EP which
> is discovered by the PCI bus layer (and then back to issue #2)
Technically, you *can* walk the DT (i.e., 'device_node's) without having
pci_dev's for each yet. Something like of_pci_find_child_device() would
do it. But that still seems kind of wonky, and it's currently neither
precise enough nor flexible enough for this, I don't think.
Brian
> If we can solve #2 and #3, it would be reasonable to move the regulator
> to a PCIE EP node. Ideally, we may want the generic PCI layer to be
> responsible for managing regulators within pci_enable_device() and
> pci_disable_device() for instance?
>
> >
> > The driver could do what you describe, but you've still got to define
> > the names here.
> >
> > Rob
> >
>
>
> --
> Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 17:27 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-20 17:27 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, Rob Herring, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, linux-kernel, Ralf Baechle, Jim Quinlan, Linux-MIPS,
Gregory Fong, Catalin Marinas, Bjorn Helgaas,
bcm-kernel-feedback-list, Matthias Kaehlcke, linux-arm-kernel
Hi,
On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
> On 10/19/2017 02:49 PM, Rob Herring wrote:
> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
> >>> This is not the regulator binding. Use the standard binding.
> >>>
> >> The reason we do it this way is because the PCIe controller does not
> >> know or care what the names of the supplies are, or how many there
> >> will be. The list of regulators can be different for each board we
> >> support, as these regulators turn on/off the downstream EP device.
> >> All the PCIe controller does is turn on/off this list of regulators
> >> when booting,resuming/suspending.
> >>
> >> An alternative would have the node specifying the standard properties
> >>
> >> xyz-supply = <&xyz_reg>;
> >> abc-supply = <&abc_reg>;
> >> pdq-supply = <&pdq_reg>;
> >> ...
> >>
> >> and then have this driver search all of the properties in the PCIe
> >> node for names matching /-supply$/, and then create a list of phandles
> >> from that. Is that what you would like?
> >
> > Really, you should have child nodes of the PCIe devices and have the
> > supplies in there.
>
> While that would be technically more correct this poses a number of issues:
>
> - there is precedence in that area, and you already Acked binding
> documents proposing the same thing:
> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
I can actually speak to the Rockchip binding a bit :)
It actually has a mixture of true controller regulators (e.g., the 1.8V
and 0.9V regulators power analog portions of the SoC's PCIe logic) and
controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
have been misused to represent a little of both, since the regulator
framework is actually quite flexible ;)
That may or may not help, but they are at least partially correct.
The Freescale one does look like it's plainly *not* about the root
controller.
Also, those rails *are* all fairly well defined by the various PCIe
electromechanical specifications, so isn't it reasonable to expect that
a controller can optionally control power for 1 of each of the standard
power types? Or do we really want to represent the flexibility that
there can be up to N of each type for N endpoints?
As a side note: it's also been pretty tough to get the power sequencing
requirements represented correctly for some PCIe endpoints. I've tried
to make use of this previously, but the series took so long (>1 year and
counting!) my team lost interest:
[PATCH v16 2/7] power: add power sequence library
https://www.spinics.net/lists/linux-usb/msg158452.html
It doesn't really solve all of this problem, but it could be worth
looking at.
> (which may indicate those should also be corrected, at the possible
> expense of creating incompatibilities)
If a better way is developed, we can always augment the bindings. The
current bindings aren't that hard to maintain as "deprecated backups."
> - there is a chicken and egg problem, you can't detect the EP without
> turning its regulator on, and if you can't create a pci_device, you
> certainly won't be able to associate it with an device_node counterpart
That's definitely a major problem driving some of the current bindings.
We're just not set up to walk the child devices if we can't probe them.
> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
> that would be guaranteed to match any physically attached PCIE EP which
> is discovered by the PCI bus layer (and then back to issue #2)
Technically, you *can* walk the DT (i.e., 'device_node's) without having
pci_dev's for each yet. Something like of_pci_find_child_device() would
do it. But that still seems kind of wonky, and it's currently neither
precise enough nor flexible enough for this, I don't think.
Brian
> If we can solve #2 and #3, it would be reasonable to move the regulator
> to a PCIE EP node. Ideally, we may want the generic PCI layer to be
> responsible for managing regulators within pci_enable_device() and
> pci_disable_device() for instance?
>
> >
> > The driver could do what you describe, but you've still got to define
> > the names here.
> >
> > Rob
> >
>
>
> --
> Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 17:27 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-20 17:27 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, Jim Quinlan, linux-kernel, Mark Rutland, Linux-MIPS,
devicetree, linux-pci, Kevin Cernekee, Will Deacon, Ralf Baechle,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, linux-arm-kernel, Matthias Kaehlcke
Hi,
On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
> On 10/19/2017 02:49 PM, Rob Herring wrote:
> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
> >>> This is not the regulator binding. Use the standard binding.
> >>>
> >> The reason we do it this way is because the PCIe controller does not
> >> know or care what the names of the supplies are, or how many there
> >> will be. The list of regulators can be different for each board we
> >> support, as these regulators turn on/off the downstream EP device.
> >> All the PCIe controller does is turn on/off this list of regulators
> >> when booting,resuming/suspending.
> >>
> >> An alternative would have the node specifying the standard properties
> >>
> >> xyz-supply = <&xyz_reg>;
> >> abc-supply = <&abc_reg>;
> >> pdq-supply = <&pdq_reg>;
> >> ...
> >>
> >> and then have this driver search all of the properties in the PCIe
> >> node for names matching /-supply$/, and then create a list of phandles
> >> from that. Is that what you would like?
> >
> > Really, you should have child nodes of the PCIe devices and have the
> > supplies in there.
>
> While that would be technically more correct this poses a number of issues:
>
> - there is precedence in that area, and you already Acked binding
> documents proposing the same thing:
> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
I can actually speak to the Rockchip binding a bit :)
It actually has a mixture of true controller regulators (e.g., the 1.8V
and 0.9V regulators power analog portions of the SoC's PCIe logic) and
controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
have been misused to represent a little of both, since the regulator
framework is actually quite flexible ;)
That may or may not help, but they are at least partially correct.
The Freescale one does look like it's plainly *not* about the root
controller.
Also, those rails *are* all fairly well defined by the various PCIe
electromechanical specifications, so isn't it reasonable to expect that
a controller can optionally control power for 1 of each of the standard
power types? Or do we really want to represent the flexibility that
there can be up to N of each type for N endpoints?
As a side note: it's also been pretty tough to get the power sequencing
requirements represented correctly for some PCIe endpoints. I've tried
to make use of this previously, but the series took so long (>1 year and
counting!) my team lost interest:
[PATCH v16 2/7] power: add power sequence library
https://www.spinics.net/lists/linux-usb/msg158452.html
It doesn't really solve all of this problem, but it could be worth
looking at.
> (which may indicate those should also be corrected, at the possible
> expense of creating incompatibilities)
If a better way is developed, we can always augment the bindings. The
current bindings aren't that hard to maintain as "deprecated backups."
> - there is a chicken and egg problem, you can't detect the EP without
> turning its regulator on, and if you can't create a pci_device, you
> certainly won't be able to associate it with an device_node counterpart
That's definitely a major problem driving some of the current bindings.
We're just not set up to walk the child devices if we can't probe them.
> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
> that would be guaranteed to match any physically attached PCIE EP which
> is discovered by the PCI bus layer (and then back to issue #2)
Technically, you *can* walk the DT (i.e., 'device_node's) without having
pci_dev's for each yet. Something like of_pci_find_child_device() would
do it. But that still seems kind of wonky, and it's currently neither
precise enough nor flexible enough for this, I don't think.
Brian
> If we can solve #2 and #3, it would be reasonable to move the regulator
> to a PCIE EP node. Ideally, we may want the generic PCI layer to be
> responsible for managing regulators within pci_enable_device() and
> pci_disable_device() for instance?
>
> >
> > The driver could do what you describe, but you've still got to define
> > the names here.
> >
> > Rob
> >
>
>
> --
> Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 17:27 ` Brian Norris
0 siblings, 0 replies; 146+ messages in thread
From: Brian Norris @ 2017-10-20 17:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
> On 10/19/2017 02:49 PM, Rob Herring wrote:
> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
> >>> This is not the regulator binding. Use the standard binding.
> >>>
> >> The reason we do it this way is because the PCIe controller does not
> >> know or care what the names of the supplies are, or how many there
> >> will be. The list of regulators can be different for each board we
> >> support, as these regulators turn on/off the downstream EP device.
> >> All the PCIe controller does is turn on/off this list of regulators
> >> when booting,resuming/suspending.
> >>
> >> An alternative would have the node specifying the standard properties
> >>
> >> xyz-supply = <&xyz_reg>;
> >> abc-supply = <&abc_reg>;
> >> pdq-supply = <&pdq_reg>;
> >> ...
> >>
> >> and then have this driver search all of the properties in the PCIe
> >> node for names matching /-supply$/, and then create a list of phandles
> >> from that. Is that what you would like?
> >
> > Really, you should have child nodes of the PCIe devices and have the
> > supplies in there.
>
> While that would be technically more correct this poses a number of issues:
>
> - there is precedence in that area, and you already Acked binding
> documents proposing the same thing:
> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
I can actually speak to the Rockchip binding a bit :)
It actually has a mixture of true controller regulators (e.g., the 1.8V
and 0.9V regulators power analog portions of the SoC's PCIe logic) and
controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
have been misused to represent a little of both, since the regulator
framework is actually quite flexible ;)
That may or may not help, but they are at least partially correct.
The Freescale one does look like it's plainly *not* about the root
controller.
Also, those rails *are* all fairly well defined by the various PCIe
electromechanical specifications, so isn't it reasonable to expect that
a controller can optionally control power for 1 of each of the standard
power types? Or do we really want to represent the flexibility that
there can be up to N of each type for N endpoints?
As a side note: it's also been pretty tough to get the power sequencing
requirements represented correctly for some PCIe endpoints. I've tried
to make use of this previously, but the series took so long (>1 year and
counting!) my team lost interest:
[PATCH v16 2/7] power: add power sequence library
https://www.spinics.net/lists/linux-usb/msg158452.html
It doesn't really solve all of this problem, but it could be worth
looking at.
> (which may indicate those should also be corrected, at the possible
> expense of creating incompatibilities)
If a better way is developed, we can always augment the bindings. The
current bindings aren't that hard to maintain as "deprecated backups."
> - there is a chicken and egg problem, you can't detect the EP without
> turning its regulator on, and if you can't create a pci_device, you
> certainly won't be able to associate it with an device_node counterpart
That's definitely a major problem driving some of the current bindings.
We're just not set up to walk the child devices if we can't probe them.
> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
> that would be guaranteed to match any physically attached PCIE EP which
> is discovered by the PCI bus layer (and then back to issue #2)
Technically, you *can* walk the DT (i.e., 'device_node's) without having
pci_dev's for each yet. Something like of_pci_find_child_device() would
do it. But that still seems kind of wonky, and it's currently neither
precise enough nor flexible enough for this, I don't think.
Brian
> If we can solve #2 and #3, it would be reasonable to move the regulator
> to a PCIE EP node. Ideally, we may want the generic PCI layer to be
> responsible for managing regulators within pci_enable_device() and
> pci_disable_device() for instance?
>
> >
> > The driver could do what you describe, but you've still got to define
> > the names here.
> >
> > Rob
> >
>
>
> --
> Florian
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
2017-10-20 17:27 ` Brian Norris
(?)
(?)
@ 2017-10-20 21:39 ` Rob Herring
-1 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-20 21:39 UTC (permalink / raw)
To: Brian Norris
Cc: Florian Fainelli, Jim Quinlan, linux-kernel, Mark Rutland,
Linux-MIPS, devicetree, linux-pci, Kevin Cernekee, Will Deacon,
Ralf Baechle, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, linux-arm-kernel,
Matthias Kaehlcke
On Fri, Oct 20, 2017 at 12:27 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Hi,
>
> On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
>> On 10/19/2017 02:49 PM, Rob Herring wrote:
>> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> >>> This is not the regulator binding. Use the standard binding.
>> >>>
>> >> The reason we do it this way is because the PCIe controller does not
>> >> know or care what the names of the supplies are, or how many there
>> >> will be. The list of regulators can be different for each board we
>> >> support, as these regulators turn on/off the downstream EP device.
>> >> All the PCIe controller does is turn on/off this list of regulators
>> >> when booting,resuming/suspending.
>> >>
>> >> An alternative would have the node specifying the standard properties
>> >>
>> >> xyz-supply = <&xyz_reg>;
>> >> abc-supply = <&abc_reg>;
>> >> pdq-supply = <&pdq_reg>;
>> >> ...
>> >>
>> >> and then have this driver search all of the properties in the PCIe
>> >> node for names matching /-supply$/, and then create a list of phandles
>> >> from that. Is that what you would like?
>> >
>> > Really, you should have child nodes of the PCIe devices and have the
>> > supplies in there.
>>
>> While that would be technically more correct this poses a number of issues:
>>
>> - there is precedence in that area, and you already Acked binding
>> documents proposing the same thing:
>> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
>> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
>> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
>> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
>
> I can actually speak to the Rockchip binding a bit :)
>
> It actually has a mixture of true controller regulators (e.g., the 1.8V
> and 0.9V regulators power analog portions of the SoC's PCIe logic) and
> controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
> have been misused to represent a little of both, since the regulator
> framework is actually quite flexible ;)
>
> That may or may not help, but they are at least partially correct.
>
> The Freescale one does look like it's plainly *not* about the root
> controller.
Maybe not. I don't find that to be obvious reading the binding.
> Also, those rails *are* all fairly well defined by the various PCIe
> electromechanical specifications, so isn't it reasonable to expect that
> a controller can optionally control power for 1 of each of the standard
> power types?
That seems okay. The MMC binding is done that way.
I never said you can't just put things in the host node. That's just
not an ideal match to the h/w and there's a limit to what makes sense.
> Or do we really want to represent the flexibility that
> there can be up to N of each type for N endpoints?
No, then you need to describe the topology.
> As a side note: it's also been pretty tough to get the power sequencing
> requirements represented correctly for some PCIe endpoints. I've tried
> to make use of this previously, but the series took so long (>1 year and
> counting!) my team lost interest:
>
> [PATCH v16 2/7] power: add power sequence library
> https://www.spinics.net/lists/linux-usb/msg158452.html
>
> It doesn't really solve all of this problem, but it could be worth
> looking at.
>
>> (which may indicate those should also be corrected, at the possible
>> expense of creating incompatibilities)
>
> If a better way is developed, we can always augment the bindings. The
> current bindings aren't that hard to maintain as "deprecated backups."
>
>> - there is a chicken and egg problem, you can't detect the EP without
>> turning its regulator on, and if you can't create a pci_device, you
>> certainly won't be able to associate it with an device_node counterpart
>
> That's definitely a major problem driving some of the current bindings.
> We're just not set up to walk the child devices if we can't probe them.
It's common to all the probeable buses that still need DT additions.
>> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
>> that would be guaranteed to match any physically attached PCIE EP which
>> is discovered by the PCI bus layer (and then back to issue #2)
>
> Technically, you *can* walk the DT (i.e., 'device_node's) without having
> pci_dev's for each yet. Something like of_pci_find_child_device() would
> do it. But that still seems kind of wonky, and it's currently neither
> precise enough nor flexible enough for this, I don't think.
That's essentially what the generic power seq stuff tries to do. I
said early on we need some sort of pre-probe hook for drivers. Trying
to handle things generically only gets you so far. There will always
be that special case that needs specific handling.
Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 21:39 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-20 21:39 UTC (permalink / raw)
To: Brian Norris
Cc: Florian Fainelli, Jim Quinlan, linux-kernel, Mark Rutland,
Linux-MIPS, devicetree, linux-pci, Kevin Cernekee, Will Deacon,
Ralf Baechle, bcm-kernel-feedback-list, Gregory Fong,
Catalin Marinas, Bjorn Helgaas, linux-arm-kernel,
Matthias Kaehlcke
On Fri, Oct 20, 2017 at 12:27 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Hi,
>
> On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
>> On 10/19/2017 02:49 PM, Rob Herring wrote:
>> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> >>> This is not the regulator binding. Use the standard binding.
>> >>>
>> >> The reason we do it this way is because the PCIe controller does not
>> >> know or care what the names of the supplies are, or how many there
>> >> will be. The list of regulators can be different for each board we
>> >> support, as these regulators turn on/off the downstream EP device.
>> >> All the PCIe controller does is turn on/off this list of regulators
>> >> when booting,resuming/suspending.
>> >>
>> >> An alternative would have the node specifying the standard properties
>> >>
>> >> xyz-supply = <&xyz_reg>;
>> >> abc-supply = <&abc_reg>;
>> >> pdq-supply = <&pdq_reg>;
>> >> ...
>> >>
>> >> and then have this driver search all of the properties in the PCIe
>> >> node for names matching /-supply$/, and then create a list of phandles
>> >> from that. Is that what you would like?
>> >
>> > Really, you should have child nodes of the PCIe devices and have the
>> > supplies in there.
>>
>> While that would be technically more correct this poses a number of issues:
>>
>> - there is precedence in that area, and you already Acked binding
>> documents proposing the same thing:
>> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
>> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
>> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
>> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
>
> I can actually speak to the Rockchip binding a bit :)
>
> It actually has a mixture of true controller regulators (e.g., the 1.8V
> and 0.9V regulators power analog portions of the SoC's PCIe logic) and
> controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
> have been misused to represent a little of both, since the regulator
> framework is actually quite flexible ;)
>
> That may or may not help, but they are at least partially correct.
>
> The Freescale one does look like it's plainly *not* about the root
> controller.
Maybe not. I don't find that to be obvious reading the binding.
> Also, those rails *are* all fairly well defined by the various PCIe
> electromechanical specifications, so isn't it reasonable to expect that
> a controller can optionally control power for 1 of each of the standard
> power types?
That seems okay. The MMC binding is done that way.
I never said you can't just put things in the host node. That's just
not an ideal match to the h/w and there's a limit to what makes sense.
> Or do we really want to represent the flexibility that
> there can be up to N of each type for N endpoints?
No, then you need to describe the topology.
> As a side note: it's also been pretty tough to get the power sequencing
> requirements represented correctly for some PCIe endpoints. I've tried
> to make use of this previously, but the series took so long (>1 year and
> counting!) my team lost interest:
>
> [PATCH v16 2/7] power: add power sequence library
> https://www.spinics.net/lists/linux-usb/msg158452.html
>
> It doesn't really solve all of this problem, but it could be worth
> looking at.
>
>> (which may indicate those should also be corrected, at the possible
>> expense of creating incompatibilities)
>
> If a better way is developed, we can always augment the bindings. The
> current bindings aren't that hard to maintain as "deprecated backups."
>
>> - there is a chicken and egg problem, you can't detect the EP without
>> turning its regulator on, and if you can't create a pci_device, you
>> certainly won't be able to associate it with an device_node counterpart
>
> That's definitely a major problem driving some of the current bindings.
> We're just not set up to walk the child devices if we can't probe them.
It's common to all the probeable buses that still need DT additions.
>> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
>> that would be guaranteed to match any physically attached PCIE EP which
>> is discovered by the PCI bus layer (and then back to issue #2)
>
> Technically, you *can* walk the DT (i.e., 'device_node's) without having
> pci_dev's for each yet. Something like of_pci_find_child_device() would
> do it. But that still seems kind of wonky, and it's currently neither
> precise enough nor flexible enough for this, I don't think.
That's essentially what the generic power seq stuff tries to do. I
said early on we need some sort of pre-probe hook for drivers. Trying
to handle things generically only gets you so far. There will always
be that special case that needs specific handling.
Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 21:39 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-20 21:39 UTC (permalink / raw)
To: Brian Norris
Cc: Mark Rutland, devicetree, Florian Fainelli, Linux-MIPS,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, Jim Quinlan, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Matthias Kaehlcke,
linux-arm-kernel
On Fri, Oct 20, 2017 at 12:27 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Hi,
>
> On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
>> On 10/19/2017 02:49 PM, Rob Herring wrote:
>> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> >>> This is not the regulator binding. Use the standard binding.
>> >>>
>> >> The reason we do it this way is because the PCIe controller does not
>> >> know or care what the names of the supplies are, or how many there
>> >> will be. The list of regulators can be different for each board we
>> >> support, as these regulators turn on/off the downstream EP device.
>> >> All the PCIe controller does is turn on/off this list of regulators
>> >> when booting,resuming/suspending.
>> >>
>> >> An alternative would have the node specifying the standard properties
>> >>
>> >> xyz-supply = <&xyz_reg>;
>> >> abc-supply = <&abc_reg>;
>> >> pdq-supply = <&pdq_reg>;
>> >> ...
>> >>
>> >> and then have this driver search all of the properties in the PCIe
>> >> node for names matching /-supply$/, and then create a list of phandles
>> >> from that. Is that what you would like?
>> >
>> > Really, you should have child nodes of the PCIe devices and have the
>> > supplies in there.
>>
>> While that would be technically more correct this poses a number of issues:
>>
>> - there is precedence in that area, and you already Acked binding
>> documents proposing the same thing:
>> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
>> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
>> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
>> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
>
> I can actually speak to the Rockchip binding a bit :)
>
> It actually has a mixture of true controller regulators (e.g., the 1.8V
> and 0.9V regulators power analog portions of the SoC's PCIe logic) and
> controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
> have been misused to represent a little of both, since the regulator
> framework is actually quite flexible ;)
>
> That may or may not help, but they are at least partially correct.
>
> The Freescale one does look like it's plainly *not* about the root
> controller.
Maybe not. I don't find that to be obvious reading the binding.
> Also, those rails *are* all fairly well defined by the various PCIe
> electromechanical specifications, so isn't it reasonable to expect that
> a controller can optionally control power for 1 of each of the standard
> power types?
That seems okay. The MMC binding is done that way.
I never said you can't just put things in the host node. That's just
not an ideal match to the h/w and there's a limit to what makes sense.
> Or do we really want to represent the flexibility that
> there can be up to N of each type for N endpoints?
No, then you need to describe the topology.
> As a side note: it's also been pretty tough to get the power sequencing
> requirements represented correctly for some PCIe endpoints. I've tried
> to make use of this previously, but the series took so long (>1 year and
> counting!) my team lost interest:
>
> [PATCH v16 2/7] power: add power sequence library
> https://www.spinics.net/lists/linux-usb/msg158452.html
>
> It doesn't really solve all of this problem, but it could be worth
> looking at.
>
>> (which may indicate those should also be corrected, at the possible
>> expense of creating incompatibilities)
>
> If a better way is developed, we can always augment the bindings. The
> current bindings aren't that hard to maintain as "deprecated backups."
>
>> - there is a chicken and egg problem, you can't detect the EP without
>> turning its regulator on, and if you can't create a pci_device, you
>> certainly won't be able to associate it with an device_node counterpart
>
> That's definitely a major problem driving some of the current bindings.
> We're just not set up to walk the child devices if we can't probe them.
It's common to all the probeable buses that still need DT additions.
>> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
>> that would be guaranteed to match any physically attached PCIE EP which
>> is discovered by the PCI bus layer (and then back to issue #2)
>
> Technically, you *can* walk the DT (i.e., 'device_node's) without having
> pci_dev's for each yet. Something like of_pci_find_child_device() would
> do it. But that still seems kind of wonky, and it's currently neither
> precise enough nor flexible enough for this, I don't think.
That's essentially what the generic power seq stuff tries to do. I
said early on we need some sort of pre-probe hook for drivers. Trying
to handle things generically only gets you so far. There will always
be that special case that needs specific handling.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device
@ 2017-10-20 21:39 ` Rob Herring
0 siblings, 0 replies; 146+ messages in thread
From: Rob Herring @ 2017-10-20 21:39 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 20, 2017 at 12:27 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> Hi,
>
> On Thu, Oct 19, 2017 at 02:58:55PM -0700, Florian Fainelli wrote:
>> On 10/19/2017 02:49 PM, Rob Herring wrote:
>> > On Tue, Oct 17, 2017 at 5:42 PM, Jim Quinlan <jim2101024@gmail.com> wrote:
>> >> On Tue, Oct 17, 2017 at 4:24 PM, Rob Herring <robh@kernel.org> wrote:
>> >>> This is not the regulator binding. Use the standard binding.
>> >>>
>> >> The reason we do it this way is because the PCIe controller does not
>> >> know or care what the names of the supplies are, or how many there
>> >> will be. The list of regulators can be different for each board we
>> >> support, as these regulators turn on/off the downstream EP device.
>> >> All the PCIe controller does is turn on/off this list of regulators
>> >> when booting,resuming/suspending.
>> >>
>> >> An alternative would have the node specifying the standard properties
>> >>
>> >> xyz-supply = <&xyz_reg>;
>> >> abc-supply = <&abc_reg>;
>> >> pdq-supply = <&pdq_reg>;
>> >> ...
>> >>
>> >> and then have this driver search all of the properties in the PCIe
>> >> node for names matching /-supply$/, and then create a list of phandles
>> >> from that. Is that what you would like?
>> >
>> > Really, you should have child nodes of the PCIe devices and have the
>> > supplies in there.
>>
>> While that would be technically more correct this poses a number of issues:
>>
>> - there is precedence in that area, and you already Acked binding
>> documents proposing the same thing:
>> * Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt (commit
>> c26ebe98a103479dae9284fe0a86a95af4a5cd46)
>> * Documentation/devicetree/bindings/pci/rockchip-pcie.txt (commit
>> 828bdcfbdb98eeb97facb05fe6c96ba0aed65c4a and before)
>
> I can actually speak to the Rockchip binding a bit :)
>
> It actually has a mixture of true controller regulators (e.g., the 1.8V
> and 0.9V regulators power analog portions of the SoC's PCIe logic) and
> controls for the PCIe endpoints (e.g., 12V). Additionally, some of these
> have been misused to represent a little of both, since the regulator
> framework is actually quite flexible ;)
>
> That may or may not help, but they are at least partially correct.
>
> The Freescale one does look like it's plainly *not* about the root
> controller.
Maybe not. I don't find that to be obvious reading the binding.
> Also, those rails *are* all fairly well defined by the various PCIe
> electromechanical specifications, so isn't it reasonable to expect that
> a controller can optionally control power for 1 of each of the standard
> power types?
That seems okay. The MMC binding is done that way.
I never said you can't just put things in the host node. That's just
not an ideal match to the h/w and there's a limit to what makes sense.
> Or do we really want to represent the flexibility that
> there can be up to N of each type for N endpoints?
No, then you need to describe the topology.
> As a side note: it's also been pretty tough to get the power sequencing
> requirements represented correctly for some PCIe endpoints. I've tried
> to make use of this previously, but the series took so long (>1 year and
> counting!) my team lost interest:
>
> [PATCH v16 2/7] power: add power sequence library
> https://www.spinics.net/lists/linux-usb/msg158452.html
>
> It doesn't really solve all of this problem, but it could be worth
> looking at.
>
>> (which may indicate those should also be corrected, at the possible
>> expense of creating incompatibilities)
>
> If a better way is developed, we can always augment the bindings. The
> current bindings aren't that hard to maintain as "deprecated backups."
>
>> - there is a chicken and egg problem, you can't detect the EP without
>> turning its regulator on, and if you can't create a pci_device, you
>> certainly won't be able to associate it with an device_node counterpart
>
> That's definitely a major problem driving some of the current bindings.
> We're just not set up to walk the child devices if we can't probe them.
It's common to all the probeable buses that still need DT additions.
>> - PCIe being dynamic by nature, can you have "wildcard" PCIE EP DT node
>> that would be guaranteed to match any physically attached PCIE EP which
>> is discovered by the PCI bus layer (and then back to issue #2)
>
> Technically, you *can* walk the DT (i.e., 'device_node's) without having
> pci_dev's for each yet. Something like of_pci_find_child_device() would
> do it. But that still seems kind of wonky, and it's currently neither
> precise enough nor flexible enough for this, I don't think.
That's essentially what the generic power seq stuff tries to do. I
said early on we need some sort of pre-probe hook for drivers. Trying
to handle things generically only gets you so far. There will always
be that special case that needs specific handling.
Rob
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-23 9:06 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-23 9:06 UTC (permalink / raw)
To: 'Jim Quinlan', Christoph Hellwig
Cc: Robin Murphy, linux-kernel, Mark Rutland, Linux-MIPS,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Marek Szyprowski, iommu
From: Jim Quinlan
> Sent: 20 October 2017 16:28
> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> >> I am not sure I understand your comment -- the size of the request
> >> shouldn't be a factor. Let's look at your example of the DMA request
> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> >> what is available, there is no 15 page span that can happen across the
> >> 0x40000000 boundary. For SG, there can be no merge that connects a
> >> page from one region to another region. Can you give an example of
> >> the scenario you are thinking of?
> >
> > What prevents a merge from say the regions of
> > 0....3fffffff and 40000000....7fffffff?
>
> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
> the original example, we now have to tell Linux that these are now our
> effective memory regions:
>
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Isn't this all unnecessary?
Both kmalloc() and dma_alloc() are constrained to allocate memory
that doesn't cross an address boundary that is larger than the size.
So if you allocate 16k it won't cross a 16k physical address boundary.
David
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-23 9:06 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-23 9:06 UTC (permalink / raw)
To: 'Jim Quinlan', Christoph Hellwig
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci, Kevin Cernekee,
Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ralf Baechle,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
From: Jim Quinlan
> Sent: 20 October 2017 16:28
> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> wrote:
> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> >> I am not sure I understand your comment -- the size of the request
> >> shouldn't be a factor. Let's look at your example of the DMA request
> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> >> what is available, there is no 15 page span that can happen across the
> >> 0x40000000 boundary. For SG, there can be no merge that connects a
> >> page from one region to another region. Can you give an example of
> >> the scenario you are thinking of?
> >
> > What prevents a merge from say the regions of
> > 0....3fffffff and 40000000....7fffffff?
>
> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
> the original example, we now have to tell Linux that these are now our
> effective memory regions:
>
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Isn't this all unnecessary?
Both kmalloc() and dma_alloc() are constrained to allocate memory
that doesn't cross an address boundary that is larger than the size.
So if you allocate 16k it won't cross a 16k physical address boundary.
David
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-23 9:06 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-23 9:06 UTC (permalink / raw)
To: 'Jim Quinlan', Christoph Hellwig
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, linux-arm-kernel, Marek Szyprowski
From: Jim Quinlan
> Sent: 20 October 2017 16:28
> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> >> I am not sure I understand your comment -- the size of the request
> >> shouldn't be a factor. Let's look at your example of the DMA request
> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> >> what is available, there is no 15 page span that can happen across the
> >> 0x40000000 boundary. For SG, there can be no merge that connects a
> >> page from one region to another region. Can you give an example of
> >> the scenario you are thinking of?
> >
> > What prevents a merge from say the regions of
> > 0....3fffffff and 40000000....7fffffff?
>
> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
> the original example, we now have to tell Linux that these are now our
> effective memory regions:
>
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Isn't this all unnecessary?
Both kmalloc() and dma_alloc() are constrained to allocate memory
that doesn't cross an address boundary that is larger than the size.
So if you allocate 16k it won't cross a 16k physical address boundary.
David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-23 9:06 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-23 9:06 UTC (permalink / raw)
To: 'Jim Quinlan', Christoph Hellwig
Cc: Robin Murphy, linux-kernel, Mark Rutland, Linux-MIPS,
Florian Fainelli, devicetree, linux-pci, Kevin Cernekee,
Will Deacon, Ralf Baechle, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
linux-arm-kernel, Marek Szyprowski, iommu
From: Jim Quinlan
> Sent: 20 October 2017 16:28
> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> >> I am not sure I understand your comment -- the size of the request
> >> shouldn't be a factor. Let's look at your example of the DMA request
> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> >> what is available, there is no 15 page span that can happen across the
> >> 0x40000000 boundary. For SG, there can be no merge that connects a
> >> page from one region to another region. Can you give an example of
> >> the scenario you are thinking of?
> >
> > What prevents a merge from say the regions of
> > 0....3fffffff and 40000000....7fffffff?
>
> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
> the original example, we now have to tell Linux that these are now our
> effective memory regions:
>
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Isn't this all unnecessary?
Both kmalloc() and dma_alloc() are constrained to allocate memory
that doesn't cross an address boundary that is larger than the size.
So if you allocate 16k it won't cross a 16k physical address boundary.
David
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-23 9:06 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-23 9:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Jim Quinlan
> Sent: 20 October 2017 16:28
> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
> >> I am not sure I understand your comment -- the size of the request
> >> shouldn't be a factor. Let's look at your example of the DMA request
> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
> >> what is available, there is no 15 page span that can happen across the
> >> 0x40000000 boundary. For SG, there can be no merge that connects a
> >> page from one region to another region. Can you give an example of
> >> the scenario you are thinking of?
> >
> > What prevents a merge from say the regions of
> > 0....3fffffff and 40000000....7fffffff?
>
> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
> the original example, we now have to tell Linux that these are now our
> effective memory regions:
>
> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> This leaves a one-page gap between phsyical memory regions which would
> normally be contiguous. One cannot have a dma alloc that spans any two
> regions. This is a drastic step, but I don't see an alternative.
> Perhaps I may be missing what you are saying...
Isn't this all unnecessary?
Both kmalloc() and dma_alloc() are constrained to allocate memory
that doesn't cross an address boundary that is larger than the size.
So if you allocate 16k it won't cross a 16k physical address boundary.
David
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-24 18:08 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-24 18:08 UTC (permalink / raw)
To: David Laight
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Mon, Oct 23, 2017 at 5:06 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Jim Quinlan
>> Sent: 20 October 2017 16:28
>> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
>> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> >> I am not sure I understand your comment -- the size of the request
>> >> shouldn't be a factor. Let's look at your example of the DMA request
>> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> >> what is available, there is no 15 page span that can happen across the
>> >> 0x40000000 boundary. For SG, there can be no merge that connects a
>> >> page from one region to another region. Can you give an example of
>> >> the scenario you are thinking of?
>> >
>> > What prevents a merge from say the regions of
>> > 0....3fffffff and 40000000....7fffffff?
>>
>> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
>> the original example, we now have to tell Linux that these are now our
>> effective memory regions:
>>
>> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
>> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
>> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
>> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
>> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> This leaves a one-page gap between phsyical memory regions which would
>> normally be contiguous. One cannot have a dma alloc that spans any two
>> regions. This is a drastic step, but I don't see an alternative.
>> Perhaps I may be missing what you are saying...
>
> Isn't this all unnecessary?
> Both kmalloc() and dma_alloc() are constrained to allocate memory
> that doesn't cross an address boundary that is larger than the size.
> So if you allocate 16k it won't cross a 16k physical address boundary.
>
> David
>
Hi David, Christoph was also concerned about this:
"For the block world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer."
Do you consider this a non-issue as well or can this happen and span
memory regions?
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-24 18:08 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-24 18:08 UTC (permalink / raw)
To: David Laight
Cc: Christoph Hellwig, Robin Murphy,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Linux-MIPS,
Florian Fainelli, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Oct 23, 2017 at 5:06 AM, David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org> wrote:
> From: Jim Quinlan
>> Sent: 20 October 2017 16:28
>> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> wrote:
>> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> >> I am not sure I understand your comment -- the size of the request
>> >> shouldn't be a factor. Let's look at your example of the DMA request
>> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> >> what is available, there is no 15 page span that can happen across the
>> >> 0x40000000 boundary. For SG, there can be no merge that connects a
>> >> page from one region to another region. Can you give an example of
>> >> the scenario you are thinking of?
>> >
>> > What prevents a merge from say the regions of
>> > 0....3fffffff and 40000000....7fffffff?
>>
>> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
>> the original example, we now have to tell Linux that these are now our
>> effective memory regions:
>>
>> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
>> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
>> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
>> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
>> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> This leaves a one-page gap between phsyical memory regions which would
>> normally be contiguous. One cannot have a dma alloc that spans any two
>> regions. This is a drastic step, but I don't see an alternative.
>> Perhaps I may be missing what you are saying...
>
> Isn't this all unnecessary?
> Both kmalloc() and dma_alloc() are constrained to allocate memory
> that doesn't cross an address boundary that is larger than the size.
> So if you allocate 16k it won't cross a 16k physical address boundary.
>
> David
>
Hi David, Christoph was also concerned about this:
"For the block world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer."
Do you consider this a non-issue as well or can this happen and span
memory regions?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-24 18:08 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-24 18:08 UTC (permalink / raw)
To: David Laight
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
On Mon, Oct 23, 2017 at 5:06 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Jim Quinlan
>> Sent: 20 October 2017 16:28
>> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
>> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> >> I am not sure I understand your comment -- the size of the request
>> >> shouldn't be a factor. Let's look at your example of the DMA request
>> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> >> what is available, there is no 15 page span that can happen across the
>> >> 0x40000000 boundary. For SG, there can be no merge that connects a
>> >> page from one region to another region. Can you give an example of
>> >> the scenario you are thinking of?
>> >
>> > What prevents a merge from say the regions of
>> > 0....3fffffff and 40000000....7fffffff?
>>
>> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
>> the original example, we now have to tell Linux that these are now our
>> effective memory regions:
>>
>> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
>> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
>> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
>> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
>> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> This leaves a one-page gap between phsyical memory regions which would
>> normally be contiguous. One cannot have a dma alloc that spans any two
>> regions. This is a drastic step, but I don't see an alternative.
>> Perhaps I may be missing what you are saying...
>
> Isn't this all unnecessary?
> Both kmalloc() and dma_alloc() are constrained to allocate memory
> that doesn't cross an address boundary that is larger than the size.
> So if you allocate 16k it won't cross a 16k physical address boundary.
>
> David
>
Hi David, Christoph was also concerned about this:
"For the block world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer."
Do you consider this a non-issue as well or can this happen and span
memory regions?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* Re: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-24 18:08 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-24 18:08 UTC (permalink / raw)
To: David Laight
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
On Mon, Oct 23, 2017 at 5:06 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Jim Quinlan
>> Sent: 20 October 2017 16:28
>> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
>> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> >> I am not sure I understand your comment -- the size of the request
>> >> shouldn't be a factor. Let's look at your example of the DMA request
>> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> >> what is available, there is no 15 page span that can happen across the
>> >> 0x40000000 boundary. For SG, there can be no merge that connects a
>> >> page from one region to another region. Can you give an example of
>> >> the scenario you are thinking of?
>> >
>> > What prevents a merge from say the regions of
>> > 0....3fffffff and 40000000....7fffffff?
>>
>> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
>> the original example, we now have to tell Linux that these are now our
>> effective memory regions:
>>
>> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
>> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
>> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
>> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
>> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> This leaves a one-page gap between phsyical memory regions which would
>> normally be contiguous. One cannot have a dma alloc that spans any two
>> regions. This is a drastic step, but I don't see an alternative.
>> Perhaps I may be missing what you are saying...
>
> Isn't this all unnecessary?
> Both kmalloc() and dma_alloc() are constrained to allocate memory
> that doesn't cross an address boundary that is larger than the size.
> So if you allocate 16k it won't cross a 16k physical address boundary.
>
> David
>
Hi David, Christoph was also concerned about this:
"For the block world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer."
Do you consider this a non-issue as well or can this happen and span
memory regions?
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-24 18:08 ` Jim Quinlan
0 siblings, 0 replies; 146+ messages in thread
From: Jim Quinlan @ 2017-10-24 18:08 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 23, 2017 at 5:06 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Jim Quinlan
>> Sent: 20 October 2017 16:28
>> On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig <hch@lst.de> wrote:
>> > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote:
>> >> I am not sure I understand your comment -- the size of the request
>> >> shouldn't be a factor. Let's look at your example of the DMA request
>> >> of 3fffff00 to 4000000f (physical memory). Lets say it is for 15
>> >> pages. If we block out the last page [0x3ffff000..0x3fffffff] from
>> >> what is available, there is no 15 page span that can happen across the
>> >> 0x40000000 boundary. For SG, there can be no merge that connects a
>> >> page from one region to another region. Can you give an example of
>> >> the scenario you are thinking of?
>> >
>> > What prevents a merge from say the regions of
>> > 0....3fffffff and 40000000....7fffffff?
>>
>> Huh? [0x3ffff000...x3ffffff] is not available to be used. Drawing from
>> the original example, we now have to tell Linux that these are now our
>> effective memory regions:
>>
>> memc0-a@[ 0....3fffefff] <=> pci@[ 0....3fffefff]
>> memc0-b@[100000000...13fffefff] <=> pci@[ 40000000....7fffefff]
>> memc1-a@[ 40000000....7fffefff] <=> pci@[ 80000000....bfffefff]
>> memc1-b@[300000000...33fffefff] <=> pci@[ c0000000....ffffefff]
>> memc2-a@[ 80000000....bfffefff] <=> pci@[100000000...13fffefff]
>> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>
>> This leaves a one-page gap between phsyical memory regions which would
>> normally be contiguous. One cannot have a dma alloc that spans any two
>> regions. This is a drastic step, but I don't see an alternative.
>> Perhaps I may be missing what you are saying...
>
> Isn't this all unnecessary?
> Both kmalloc() and dma_alloc() are constrained to allocate memory
> that doesn't cross an address boundary that is larger than the size.
> So if you allocate 16k it won't cross a 16k physical address boundary.
>
> David
>
Hi David, Christoph was also concerned about this:
"For the block world take a look at __blk_segment_map_sg which does the merging
of contiguous pages into a single SG segment. You'd have to override
BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
architectures for the block layer."
Do you consider this a non-issue as well or can this happen and span
memory regions?
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
2017-10-24 18:08 ` Jim Quinlan
` (2 preceding siblings ...)
(?)
@ 2017-10-25 9:36 ` David Laight
-1 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-25 9:36 UTC (permalink / raw)
To: 'Jim Quinlan'
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
From: Jim Quinla
> Sent: 24 October 2017 19:08
...
> Hi David, Christoph was also concerned about this:
>
> "For the block world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer."
>
> Do you consider this a non-issue as well or can this happen and span
> memory regions?
Probably easiest to have an architecture limit on the addresses that
can be merged.
My guess is that this code only really ever merges pages that were
allocated contiguously, but have got converted to a list of VA.
So stopping merging over even 1MB boundaries would have minimal effect
(even if done unconditionally).
I even wonder if the merging is actually worthwhile at all?
Maybe if any code has limits on the SG list length.
(or reducing the number of cache lines the get dirtied...)
David
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-25 9:36 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-25 9:36 UTC (permalink / raw)
To: 'Jim Quinlan'
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel
From: Jim Quinla
> Sent: 24 October 2017 19:08
...
> Hi David, Christoph was also concerned about this:
>
> "For the block world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer."
>
> Do you consider this a non-issue as well or can this happen and span
> memory regions?
Probably easiest to have an architecture limit on the addresses that
can be merged.
My guess is that this code only really ever merges pages that were
allocated contiguously, but have got converted to a list of VA.
So stopping merging over even 1MB boundaries would have minimal effect
(even if done unconditionally).
I even wonder if the merging is actually worthwhile at all?
Maybe if any code has limits on the SG list length.
(or reducing the number of cache lines the get dirtied...)
David
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-25 9:36 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-25 9:36 UTC (permalink / raw)
To: 'Jim Quinlan'
Cc: Mark Rutland, Linux-MIPS, Florian Fainelli, devicetree,
linux-pci, Kevin Cernekee, Will Deacon, linux-kernel,
Ralf Baechle, iommu, Rob Herring, bcm-kernel-feedback-list,
Gregory Fong, Catalin Marinas, Bjorn Helgaas, Brian Norris,
Robin Murphy, Christoph Hellwig, linux-arm-kernel,
Marek Szyprowski
From: Jim Quinla
> Sent: 24 October 2017 19:08
...
> Hi David, Christoph was also concerned about this:
>
> "For the block world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer."
>
> Do you consider this a non-issue as well or can this happen and span
> memory regions?
Probably easiest to have an architecture limit on the addresses that
can be merged.
My guess is that this code only really ever merges pages that were
allocated contiguously, but have got converted to a list of VA.
So stopping merging over even 1MB boundaries would have minimal effect
(even if done unconditionally).
I even wonder if the merging is actually worthwhile at all?
Maybe if any code has limits on the SG list length.
(or reducing the number of cache lines the get dirtied...)
David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 146+ messages in thread
* RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-25 9:36 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-25 9:36 UTC (permalink / raw)
To: 'Jim Quinlan'
Cc: Christoph Hellwig, Robin Murphy, linux-kernel, Mark Rutland,
Linux-MIPS, Florian Fainelli, devicetree, linux-pci,
Kevin Cernekee, Will Deacon, Ralf Baechle, Rob Herring,
bcm-kernel-feedback-list, Gregory Fong, Catalin Marinas,
Bjorn Helgaas, Brian Norris, linux-arm-kernel, Marek Szyprowski,
iommu
From: Jim Quinla
> Sent: 24 October 2017 19:08
...
> Hi David, Christoph was also concerned about this:
>
> "For the block world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer."
>
> Do you consider this a non-issue as well or can this happen and span
> memory regions?
Probably easiest to have an architecture limit on the addresses that
can be merged.
My guess is that this code only really ever merges pages that were
allocated contiguously, but have got converted to a list of VA.
So stopping merging over even 1MB boundaries would have minimal effect
(even if done unconditionally).
I even wonder if the merging is actually worthwhile at all?
Maybe if any code has limits on the SG list length.
(or reducing the number of cache lines the get dirtied...)
David
^ permalink raw reply [flat|nested] 146+ messages in thread
* [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic
@ 2017-10-25 9:36 ` David Laight
0 siblings, 0 replies; 146+ messages in thread
From: David Laight @ 2017-10-25 9:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Jim Quinla
> Sent: 24 October 2017 19:08
...
> Hi David, Christoph was also concerned about this:
>
> "For the block world take a look at __blk_segment_map_sg which does the merging
> of contiguous pages into a single SG segment. You'd have to override
> BIOVEC_PHYS_MERGEABLE to prevent this from happening in your supported
> architectures for the block layer."
>
> Do you consider this a non-issue as well or can this happen and span
> memory regions?
Probably easiest to have an architecture limit on the addresses that
can be merged.
My guess is that this code only really ever merges pages that were
allocated contiguously, but have got converted to a list of VA.
So stopping merging over even 1MB boundaries would have minimal effect
(even if done unconditionally).
I even wonder if the merging is actually worthwhile at all?
Maybe if any code has limits on the SG list length.
(or reducing the number of cache lines the get dirtied...)
David
^ permalink raw reply [flat|nested] 146+ messages in thread
end of thread, other threads:[~2017-10-25 9:36 UTC | newest]
Thread overview: 146+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-11 22:34 PCI: brcmstb: Add Broadcom Settopbox PCIe support Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` [PATCH 1/9] SOC: brcmstb: add memory API Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-12 14:41 ` Julien Thierry
2017-10-12 14:41 ` Julien Thierry
2017-10-12 14:41 ` Julien Thierry
2017-10-12 16:53 ` Florian Fainelli
2017-10-12 16:53 ` Florian Fainelli
2017-10-12 16:53 ` Florian Fainelli
2017-10-17 8:24 ` Christoph Hellwig
2017-10-17 8:24 ` Christoph Hellwig
2017-10-17 8:24 ` Christoph Hellwig
2017-10-17 16:12 ` Florian Fainelli
2017-10-17 16:12 ` Florian Fainelli
2017-10-17 16:12 ` Florian Fainelli
2017-10-18 6:46 ` Christoph Hellwig
2017-10-18 6:46 ` Christoph Hellwig
2017-10-18 6:46 ` Christoph Hellwig
2017-10-18 16:47 ` Florian Fainelli
2017-10-18 16:47 ` Florian Fainelli
2017-10-11 22:34 ` [PATCH 2/9] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-12 0:55 ` Brian Norris
2017-10-12 0:55 ` Brian Norris
2017-10-12 0:55 ` Brian Norris
2017-10-12 0:55 ` Brian Norris
2017-10-12 17:52 ` Jim Quinlan
2017-10-12 17:52 ` Jim Quinlan
2017-10-12 17:52 ` Jim Quinlan
2017-10-17 20:24 ` Rob Herring
2017-10-17 20:24 ` Rob Herring
2017-10-17 20:24 ` Rob Herring
2017-10-17 22:42 ` Jim Quinlan
2017-10-17 22:42 ` Jim Quinlan
2017-10-17 22:42 ` Jim Quinlan
2017-10-19 21:49 ` Rob Herring
2017-10-19 21:49 ` Rob Herring
2017-10-19 21:49 ` Rob Herring
2017-10-19 21:49 ` Rob Herring
2017-10-19 21:58 ` Florian Fainelli
2017-10-19 21:58 ` Florian Fainelli
2017-10-19 21:58 ` Florian Fainelli
2017-10-19 21:58 ` Florian Fainelli
2017-10-20 17:27 ` Brian Norris
2017-10-20 17:27 ` Brian Norris
2017-10-20 17:27 ` Brian Norris
2017-10-20 17:27 ` Brian Norris
2017-10-20 17:27 ` Brian Norris
2017-10-20 21:39 ` Rob Herring
2017-10-20 21:39 ` Rob Herring
2017-10-20 21:39 ` Rob Herring
2017-10-20 21:39 ` Rob Herring
2017-10-19 23:04 ` Jim Quinlan
2017-10-19 23:04 ` Jim Quinlan
2017-10-19 23:04 ` Jim Quinlan
2017-10-19 23:04 ` Jim Quinlan
2017-10-19 23:04 ` Jim Quinlan
2017-10-11 22:34 ` [PATCH 3/9] PCI: host: brcmstb: Broadcom PCIe Host Controller Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` [PATCH 4/9] arm64: dma-mapping: export symbol arch_setup_dma_ops Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-12 17:06 ` Robin Murphy
2017-10-12 17:06 ` Robin Murphy
2017-10-12 17:06 ` Robin Murphy
2017-10-12 18:15 ` Jim Quinlan
2017-10-12 18:15 ` Jim Quinlan
2017-10-12 18:15 ` Jim Quinlan
2017-10-12 18:15 ` Jim Quinlan
2017-10-11 22:34 ` [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-12 18:04 ` Robin Murphy
2017-10-12 18:04 ` Robin Murphy
2017-10-12 18:04 ` Robin Murphy
2017-10-12 18:04 ` Robin Murphy
2017-10-12 21:43 ` Jim Quinlan
2017-10-12 21:43 ` Jim Quinlan
2017-10-12 21:43 ` Jim Quinlan
2017-10-17 8:14 ` Christoph Hellwig
2017-10-17 8:14 ` Christoph Hellwig
2017-10-17 8:14 ` Christoph Hellwig
2017-10-17 16:11 ` Jim Quinlan
2017-10-17 16:11 ` Jim Quinlan
2017-10-17 16:11 ` Jim Quinlan
2017-10-18 6:53 ` Christoph Hellwig
2017-10-18 6:53 ` Christoph Hellwig
2017-10-18 6:53 ` Christoph Hellwig
2017-10-18 6:53 ` Christoph Hellwig
2017-10-18 14:41 ` Jim Quinlan
2017-10-18 14:41 ` Jim Quinlan
2017-10-18 14:41 ` Jim Quinlan
2017-10-19 9:16 ` Christoph Hellwig
2017-10-19 9:16 ` Christoph Hellwig
2017-10-19 9:16 ` Christoph Hellwig
2017-10-19 9:16 ` Christoph Hellwig
2017-10-19 22:47 ` Jim Quinlan
2017-10-19 22:47 ` Jim Quinlan
2017-10-19 22:47 ` Jim Quinlan
2017-10-20 7:37 ` Christoph Hellwig
2017-10-20 7:37 ` Christoph Hellwig
2017-10-20 7:37 ` Christoph Hellwig
2017-10-20 7:37 ` Christoph Hellwig
2017-10-20 14:41 ` Jim Quinlan
2017-10-20 14:41 ` Jim Quinlan
2017-10-20 14:41 ` Jim Quinlan
2017-10-20 14:41 ` Jim Quinlan
2017-10-20 14:57 ` Christoph Hellwig
2017-10-20 14:57 ` Christoph Hellwig
2017-10-20 14:57 ` Christoph Hellwig
2017-10-20 14:57 ` Christoph Hellwig
2017-10-20 15:27 ` Jim Quinlan
2017-10-20 15:27 ` Jim Quinlan
2017-10-20 15:27 ` Jim Quinlan
2017-10-20 16:17 ` Christoph Hellwig
2017-10-20 16:17 ` Christoph Hellwig
2017-10-20 16:17 ` Christoph Hellwig
2017-10-20 16:17 ` Christoph Hellwig
2017-10-23 9:06 ` David Laight
2017-10-23 9:06 ` David Laight
2017-10-23 9:06 ` David Laight
2017-10-23 9:06 ` David Laight
2017-10-23 9:06 ` David Laight
2017-10-24 18:08 ` Jim Quinlan
2017-10-24 18:08 ` Jim Quinlan
2017-10-24 18:08 ` Jim Quinlan
2017-10-24 18:08 ` Jim Quinlan
2017-10-24 18:08 ` Jim Quinlan
2017-10-25 9:36 ` David Laight
2017-10-25 9:36 ` David Laight
2017-10-25 9:36 ` David Laight
2017-10-25 9:36 ` David Laight
2017-10-25 9:36 ` David Laight
2017-10-11 22:34 ` [PATCH 6/9] PCI/MSI: Enable PCI_MSI_IRQ_DOMAIN support for MIPS Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` [PATCH 7/9] PCI: host: brcmstb: add MSI capability Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` [PATCH 8/9] MIPS: BMIPS: add PCI bindings for 7425, 7435 Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
2017-10-11 22:34 ` [PATCH 9/9] MIPS: BMIPS: enable PCI Jim Quinlan
2017-10-11 22:34 ` Jim Quinlan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.