* 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-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
* 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
* [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
* 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
* [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 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
* 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
* [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 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
* 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
* [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 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
* 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
* [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 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
* 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
* [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 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
* 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
* [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-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 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
* 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
* [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 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
* 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 (?) @ 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
* [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 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
* 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
* [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 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
* 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
* [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 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
* 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
* [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 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
* 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 (?) (?) @ 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
* [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 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
* 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-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 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: 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-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 (?) (?) @ 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
* [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 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
* 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-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 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: 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-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
* [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-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 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-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 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-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 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
* 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
* [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 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
* 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
* [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 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
* 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
* [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-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 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
* 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
* [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 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
* 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 (?) @ 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
* [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 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
* 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
* [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 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
* 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
* [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 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
* 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
* [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 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
* 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 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
* [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 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
* 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
* [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 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
* 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 (?) @ 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
* [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 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
* 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
* [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 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
* 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 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
* [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 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
* 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 (?) (?) @ 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
* [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 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
* 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 (?) @ 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
* [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 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
* 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
* [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 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
* 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-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-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, 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: 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-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 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: 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-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 ` (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
* [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
* 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
* 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 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 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
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.