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.
V5 Changes:
- V4 had its own DMA ops structure in the PCIe driver which would
override/coexist with the default arch DMA ops. This approach was
scrapped, and this version instead essentially implements custom
definitions of the __phys_to_dma and __dma_to_phys operations for the
three target arches: MIPs, ARM64, ARM. This was the course suggested
by one of the V4 reviewers (ChristophH).
For MIPs and ARM64, the DMA remapping is easily accomplished by having
custom definitions of __phys_to_dma and __dma_to_phys. For
MIPs/BMIPs, ARCH_HAS_PHYS_TO_DMA is already selected and the two
functions are just modified. For ARM64, this driver selects
ARCH_HAS_PHYS_TO_DMA and declares and defines __phys_to_dma() and
__dma_to_phys(). For ARM, things were not so simple. The default
functions like __arch_pfn_to_dma() had to be overridden by custom ones
defined in arch/arm/mach-bcm/include/mach/memory.h. For these
functions to be "seen", we had to declare our own brcmstb_defconfig
and no longer use multi_v7_defconfig. This is unfortunate.
- Commits have been better organized to first implement the main driver,
then add features (MSI, DMA remap infrastructure), and then add
the DMA remapping modifications for MIPs, ARM64, and ARM.
V4 Changes:
- Merged all BrcmSTB PCIe controller files into a single file.
- All new files now have the SPDX identifier.
- Removed the list of PCIe controllers.
- Removed "link-up" race.
- Removed probe of msi psuedo-device.
- Multiple comment text changes, as requested.
- "SSC" => "Spread Spectrum Clocking".
- Set 'memc' variable.
- Unnecessary variable initializations removed (eg rc_bar2_size).
- Added comment on "L23" link state.
- Removed use of "__refdata".
- Formatting of structure elements.
V3 Changes:
- Fold pcie-brcmstb-msi.c into pcie-brcmstb.c
- Use PCI_XXX constants for PCIe capability registers
- Removal of any unused constants
- Change s/pci/pcie/ for filenames, comment text
- Config space access now uses 8/16/32 read/writes
- Use proper multi-line comment style
- Use function names, structure that are common in other host drivers
- DT binding 'brcm,ssc' is now 'brcm,enable-ssc'
- Dropped DT binding 'xyz-supply'
- Not setting CRS support as Linux does it if it is advertised.
- Removed code that was considered "debug code".
- Use of_get_pcie_domain_nr()
- Variable 'bridge_setup_done' removed.
V2 Changes:
* Patch brcmstb-add-memory-API:
- fix DT_PROP_DATA_TO_U32 macro.
- dropped one EXPORT_SYMBOL, changed the other to GPL.
* Patch DT-docs-for-Brcmstb-PCIe:
- change 'brcm,gen' prop to standard 'max-link-speed'.
- rewrite bindings commit to omit standard prop defs.
- change props "supplies", "supply-names" to "xyz-supply"
* Patch removed: export-symbol-arch_setup_dma_ops [4/9]
* Patch brcmstb-add-dma-ranges:
- use get_dma_ops(); also use a const dma_map_ops structure.
- rewrite map_sg(), unmap_sg(), other calls like syng_sg_*()
- omit brcm_mapping_error(), but added code in brcm_dma_supported()
- put all of the notifier code in one compilation unit.
Florian Fainelli (1):
soc: bcm: brcmstb: add memory API
Jim Quinlan (11):
dt-bindings: pci: add DT docs for Brcmstb PCIe device
PCI: brcmstb: add Broadcom STB PCIe host controller driver
PCI: brcmstb: add dma-range mapping for inbound traffic
PCI: brcmstb: add MSI capability
MIPS: BMIPS: add dma remap for BrcmSTB PCIe
PCI/MSI: enable PCI_MSI_IRQ_DOMAIN support for MIPS
MIPS: BMIPS: add PCI bindings for 7425, 7435
MIPS: BMIPS: enable PCI
ARM64: declare __phys_to_dma on ARCH_HAS_PHYS_TO_DMA
ARM64: add dma remap for BrcmSTB PCIe
ARM: add dma remap for BrcmSTB PCIe
.../devicetree/bindings/pci/brcmstb-pcie.txt | 59 +
arch/arm/Kconfig | 33 +
arch/arm/configs/brcmstb_defconfig | 204 +++
arch/arm/configs/multi_v7_defconfig | 3 -
arch/arm/mach-bcm/Kconfig | 21 +-
arch/arm/mach-bcm/Makefile.boot | 0
arch/arm/mach-bcm/include/mach/irqs.h | 3 +
arch/arm/mach-bcm/include/mach/memory.h | 47 +
arch/arm/mach-bcm/include/mach/uncompress.h | 8 +
arch/arm64/include/asm/dma-direct.h | 16 +
arch/mips/Kconfig | 3 +
arch/mips/bmips/dma.c | 9 +
arch/mips/boot/dts/brcm/bcm7425.dtsi | 28 +
arch/mips/boot/dts/brcm/bcm7435.dtsi | 28 +
arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 +
arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 +
drivers/pci/Kconfig | 2 +-
drivers/pci/controller/Kconfig | 13 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-brcmstb.c | 1554 ++++++++++++++++++++
drivers/soc/bcm/brcmstb/Makefile | 2 +-
drivers/soc/bcm/brcmstb/memory.c | 158 ++
include/soc/brcmstb/common.h | 16 +
include/soc/brcmstb/memory_api.h | 26 +
24 files changed, 2217 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
create mode 100644 arch/arm/configs/brcmstb_defconfig
create mode 100644 arch/arm/mach-bcm/Makefile.boot
create mode 100644 arch/arm/mach-bcm/include/mach/irqs.h
create mode 100644 arch/arm/mach-bcm/include/mach/memory.h
create mode 100644 arch/arm/mach-bcm/include/mach/uncompress.h
create mode 100644 arch/arm64/include/asm/dma-direct.h
create mode 100644 drivers/pci/controller/pcie-brcmstb.c
create mode 100644 drivers/soc/bcm/brcmstb/memory.c
create mode 100644 include/soc/brcmstb/memory_api.h
--
1.9.0.138.g2de3478
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 <[email protected]>
Acked-by: Rob Herring <[email protected]>
---
.../devicetree/bindings/pci/brcmstb-pcie.txt | 59 ++++++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt b/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
new file mode 100644
index 0000000..a1a9ad5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
@@ -0,0 +1,59 @@
+Brcmstb PCIe Host Controller Device Tree Bindings
+
+Required Properties:
+- compatible
+ "brcm,bcm7425-pcie" -- for 7425 family MIPS-based SOCs.
+ "brcm,bcm7435-pcie" -- for 7435 family MIPS-based SOCs.
+ "brcm,bcm7445-pcie" -- for 7445 and later ARM based SOCs (not including
+ the 7278).
+ "brcm,bcm7278-pcie" -- for 7278 family ARM-based SOCs.
+
+- reg -- the register start address and length for the PCIe reg block.
+- 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".
+- #address-cells -- set to <3>.
+- #size-cells -- set to <2>.
+- #interrupt-cells: set to <1>.
+- interrupt-map-mask and interrupt-map, standard PCI properties to define the
+ mapping of the PCIe interface to interrupt numbers.
+- ranges: ranges for the PCI memory and I/O regions.
+- linux,pci-domain -- should be unique per host controller.
+
+Optional Properties:
+- clocks -- phandle of pcie clock.
+- clock-names -- set to "sw_pcie" if clocks is used.
+- dma-ranges -- Specifies the inbound memory mapping regions when
+ an "identity map" is not possible.
+- msi-controller -- this property is typically specified to have the
+ PCIe controller use its internal MSI controller.
+- msi-parent -- set to use an external MSI interrupt controller.
+- brcm,enable-ssc -- (boolean) indicates usage of spread-spectrum clocking.
+- max-link-speed -- (integer) indicates desired generation of link:
+ 1 => 2.5 Gbps (gen1), 2 => 5.0 Gbps (gen2), 3 => 8.0 Gbps (gen3).
+
+Example Node:
+
+pcie0: pcie@f0460000 {
+ reg = <0x0 0xf0460000 0x0 0x9310>;
+ interrupts = <0x0 0x0 0x4>;
+ compatible = "brcm,bcm7445-pcie";
+ #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>;
+ 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;
+ max-link-speed = <1>;
+ linux,pci-domain = <0>;
+ };
--
1.9.0.138.g2de3478
From: Florian Fainelli <[email protected]>
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: Florian Fainelli <[email protected]>
---
drivers/soc/bcm/brcmstb/Makefile | 2 +-
drivers/soc/bcm/brcmstb/memory.c | 158 +++++++++++++++++++++++++++++++++++++++
include/soc/brcmstb/memory_api.h | 26 +++++++
3 files changed, 185 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 01687c2..e4ccd3a 100644
--- a/drivers/soc/bcm/brcmstb/Makefile
+++ b/drivers/soc/bcm/brcmstb/Makefile
@@ -1,2 +1,2 @@
-obj-y += common.o biuctrl.o
+obj-y += common.o biuctrl.o memory.o
obj-$(CONFIG_BRCMSTB_PM) += pm/
diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
new file mode 100644
index 0000000..254783d
--- /dev/null
+++ b/drivers/soc/bcm/brcmstb/memory.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright © 2015-2017 Broadcom */
+
+#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>
+
+/* Macro to help extract property data */
+#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(*(u32 *)(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,
+};
+
+/*
+ * 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
+
+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_GPL(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..6546845
--- /dev/null
+++ b/include/soc/brcmstb/memory_api.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#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
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 <[email protected]>
---
drivers/pci/controller/Kconfig | 12 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-brcmstb.c | 1099 +++++++++++++++++++++++++++++++++
3 files changed, 1112 insertions(+)
create mode 100644 drivers/pci/controller/pcie-brcmstb.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 028b287..c863c67 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -278,5 +278,17 @@ config VMD
To compile this driver as a module, choose M here: the
module will be called vmd.
+config PCIE_BRCMSTB
+ bool "Broadcom Brcmstb PCIe host controller"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ depends on OF
+ depends on SOC_BRCMSTB
+ default ARCH_BRCMSTB || BMIPS_GENERIC
+ help
+ Say Y here to enable PCIe host controller support for
+ Broadcom Settop Box SOCs. A Broadcom SOC will may have
+ multiple host controllers as opposed to a single host
+ controller with multiple ports.
+
source "drivers/pci/controller/dwc/Kconfig"
endmenu
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index d56a507..e76bfb2 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
+obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
new file mode 100644
index 0000000..9c87d10
--- /dev/null
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -0,0 +1,1099 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2009 - 2018 Broadcom */
+
+#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_platform.h>
+#include <linux/pci.h>
+#include <linux/printk.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.h"
+
+/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
+#define BRCM_PCIE_CAP_REGS 0x00ac
+
+/*
+ * Broadcom Settop Box PCIe Register Offsets. The names are from
+ * the chip's RDB and we use them here so that a script can correlate
+ * this code and the RDB to prevent discrepancies.
+ */
+#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_BAR2_CONFIG_LO 0x4034
+#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
+#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
+#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
+#define PCIE_INTR2_CPU_BASE 0x4300
+
+/*
+ * Broadcom Settop Box PCIe Register Field shift and mask info. The
+ * names are from the chip's RDB and we use them here so that a script
+ * can correlate this code and the RDB to prevent discrepancies.
+ */
+#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_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_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
+#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_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_PCIE_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 PCIE_BUSNUM_SHIFT 20
+#define PCIE_SLOT_SHIFT 15
+#define PCIE_FUNC_SHIFT 12
+
+#if defined(__BIG_ENDIAN)
+#define DATA_ENDIAN 2 /* PCIe->DDR inbound traffic */
+#define MMIO_ENDIAN 2 /* CPU->PCIe outbound traffic */
+#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,
+};
+
+struct brcm_window {
+ dma_addr_t pcie_addr;
+ phys_addr_t cpu_addr;
+ dma_addr_t size;
+};
+
+/* Internal PCIe Host Controller Information.*/
+struct brcm_pcie {
+ struct device *dev;
+ void __iomem *base;
+ struct list_head resources;
+ int irq;
+ struct clk *clk;
+ struct pci_bus *root_bus;
+ struct device_node *dn;
+ int id;
+ bool suspended;
+ int num_out_wins;
+ bool ssc;
+ int gen;
+ struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
+ unsigned int rev;
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
+};
+
+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_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
+ int where);
+
+static struct pci_ops brcm_pcie_ops = {
+ .map_bus = brcm_pcie_map_conf,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
+};
+
+#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)
+#define bcm_readw(a) __raw_readw(a)
+#define bcm_writew(d, a) __raw_writew(d, a)
+#else
+#define bcm_readl(a) readl(a)
+#define bcm_writel(d, a) writel(d, a)
+#define bcm_readw(a) readw(a)
+#define bcm_writew(d, a) writew(d, a)
+#endif
+
+/* These macros extract/insert fields to host controller's register set. */
+#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)))
+
+static phys_addr_t scb_size[BRCM_MAX_SCB];
+static int num_memc;
+static int num_pcie;
+static DEFINE_MUTEX(brcm_pcie_lock);
+
+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);
+}
+
+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 "???";
+}
+
+/*
+ * 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);
+}
+
+/*
+ * This is to convert the size of the inbound "BAR" region to the
+ * non-linear 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;
+}
+
+/*
+ * Configures device for Spread Spectrum Clocking (SSC) mode; a 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)
+{
+ u32 lnkcap = bcm_readl(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
+ u16 lnkctl2 = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
+
+ lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS) | gen;
+ bcm_writel(lnkcap, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
+
+ lnkctl2 = (lnkctl2 & ~0xf) | gen;
+ bcm_writew(lnkctl2, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
+}
+
+static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
+ unsigned int win, phys_addr_t cpu_addr,
+ dma_addr_t pcie_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 pcie_addr window */
+ bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
+ bcm_writel(upper_32_bits(pcie_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);
+ }
+}
+
+/* Configuration space read/write support */
+static int cfg_index(int busnr, int devfn, int reg)
+{
+ return ((PCI_SLOT(devfn) & 0x1f) << PCIE_SLOT_SHIFT)
+ | ((PCI_FUNC(devfn) & 0x07) << PCIE_FUNC_SHIFT)
+ | (busnr << PCIE_BUSNUM_SHIFT)
+ | (reg & ~3);
+}
+
+/* The controller is capable of serving in both RC and EP roles */
+static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
+
+ return !!EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
+}
+
+static bool brcm_pcie_link_up(struct brcm_pcie *pcie)
+{
+ 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);
+
+ return (dla && plu) ? true : false;
+}
+
+static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ struct brcm_pcie *pcie = bus->sysdata;
+ void __iomem *base = pcie->base;
+ int idx;
+
+ /* Accesses to the RC go right to the RC registers if slot==0 */
+ if (pci_is_root_bus(bus))
+ return PCI_SLOT(devfn) ? NULL : base + where;
+
+ /* For devices, write to the config space index register */
+ idx = cfg_index(bus->number, devfn, where);
+ bcm_writel(idx, pcie->base + IDX_ADDR(pcie));
+ return base + DATA_ADDR(pcie) + (where & 0x3);
+}
+
+static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ 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];
+
+ 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_pcie_add_controller(struct brcm_pcie *pcie)
+{
+ int i, ret = 0;
+ struct device *dev = pcie->dev;
+
+ mutex_lock(&brcm_pcie_lock);
+ if (num_pcie > 0) {
+ num_pcie++;
+ goto done;
+ }
+
+ /* Determine num_memc and their sizes */
+ for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
+ u64 size = brcmstb_memory_memc_size(i);
+
+ if (size == (u64)-1) {
+ dev_err(dev, "cannot get memc%d size\n", i);
+ ret = -EINVAL;
+ goto done;
+ } else if (size) {
+ scb_size[i] = roundup_pow_of_two_64(size);
+ num_memc++;
+ } else {
+ break;
+ }
+ }
+ if (!ret && num_memc == 0) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ num_pcie++;
+done:
+ mutex_unlock(&brcm_pcie_lock);
+ return ret;
+}
+
+static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
+{
+ mutex_lock(&brcm_pcie_lock);
+ if (--num_pcie == 0)
+ num_memc = 0;
+ mutex_unlock(&brcm_pcie_lock);
+}
+
+static int brcm_pcie_parse_request_of_pci_ranges(struct brcm_pcie *pcie)
+{
+ struct resource_entry *win;
+ int ret;
+
+ ret = devm_of_pci_get_host_bridge_resources(pcie->dev, 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 *res = win->res;
+ dma_addr_t offset = (dma_addr_t)win->offset;
+
+ if (resource_type(res) != IORESOURCE_MEM)
+ continue;
+
+ if (pcie->num_out_wins >= BRCM_NUM_PCIE_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].pcie_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++;
+ }
+
+ ret = devm_request_pci_bus_resources(pcie->dev, &pcie->resources);
+ if (ret)
+ dev_err(pcie->dev, "failed to request pci resources\n");
+ return ret;
+}
+
+static int brcm_pcie_setup(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ unsigned int scb_size_val;
+ u64 rc_bar2_offset, rc_bar2_size, total_mem_size = 0;
+ u32 tmp, burst;
+ int i, j, ret, limit;
+ u16 nlw, cls, lnksta;
+ bool ssc_good = false;
+ struct device *dev = pcie->dev;
+
+ /* Reset the bridge */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+
+ /*
+ * Ensure that the fundamental reset is asserted, except for 7278,
+ * which fails if we do this.
+ */
+ if (pcie->type != BCM7278)
+ brcm_pcie_perst_set(pcie, 1);
+
+ usleep_range(100, 200);
+
+ /* Take the bridge out of reset */
+ 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 PCIe 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 pcie-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);
+
+ scb_size_val = scb_size[0]
+ ? ilog2(scb_size[0]) - 15 : 0xf; /* 0xf is 1GB */
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
+
+ if (num_memc > 1) {
+ scb_size_val = scb_size[1]
+ ? ilog2(scb_size[1]) - 15 : 0xf; /* 0xf is 1GB */
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB1_SIZE, scb_size_val);
+ }
+
+ if (num_memc > 2) {
+ scb_size_val = scb_size[2]
+ ? ilog2(scb_size[2]) - 15 : 0xf; /* 0xf is 1GB */
+ 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);
+
+ /* Unassert the fundamental reset */
+ brcm_pcie_perst_set(pcie, 0);
+
+ /*
+ * 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.
+ */
+ limit = pcie->suspended ? 1000 : 100;
+ for (i = 1, j = 0; j < limit && !brcm_pcie_link_up(pcie);
+ j += i, i = i * 2)
+ msleep(i + j > limit ? limit - j : i);
+
+ if (!brcm_pcie_link_up(pcie)) {
+ dev_info(dev, "link down\n");
+ return -ENODEV;
+ }
+
+ if (!brcm_pcie_rc_mode(pcie)) {
+ dev_err(dev, "PCIe misconfigured; is in EP mode\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < pcie->num_out_wins; i++)
+ brcm_pcie_set_outbound_win(pcie, i, pcie->out_wins[i].cpu_addr,
+ pcie->out_wins[i].pcie_addr,
+ pcie->out_wins[i].size);
+
+ /*
+ * For config space accesses on the RC, show the right class for
+ * a PCIe-PCIe bridge (the default setting is to be EP mode).
+ */
+ 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(dev, "failed attempt to enter ssc mode\n");
+ }
+
+ lnksta = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKSTA);
+ cls = lnksta & PCI_EXP_LNKSTA_CLS;
+ nlw = (lnksta & PCI_EXP_LNKSTA_NLW) >> PCI_EXP_LNKSTA_NLW_SHIFT;
+ dev_info(dev, "link up, %s Gbps x%u %s\n", link_speed_to_str(cls),
+ nlw, ssc_good ? "(SSC)" : "(!SSC)");
+
+ /* 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);
+
+ return 0;
+}
+
+/* L23 is a low-power PCIe link state */
+static void enter_l23(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ int l23, i;
+
+ /* assert request for L23 */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
+
+ /* Wait up to 30 msec for L23 */
+ l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
+ for (i = 0; i < 15 && !l23; i++) {
+ usleep_range(2000, 2400);
+ 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 (brcm_pcie_link_up(pcie))
+ enter_l23(pcie);
+ /* Assert fundamental reset */
+ 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);
+ /* Turn off SerDes */
+ 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);
+
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ 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;
+
+ base = pcie->base;
+ 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);
+
+ /* Turn on SerDes */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* Wait for SerDes to be stable */
+ usleep_range(100, 200);
+
+ ret = brcm_pcie_setup(pcie);
+ if (ret)
+ return ret;
+
+ pcie->suspended = false;
+
+ return 0;
+}
+
+static void _brcm_pcie_remove(struct brcm_pcie *pcie)
+{
+ turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ clk_put(pcie->clk);
+ pci_free_resource_list(&pcie->resources);
+ brcm_pcie_remove_controller(pcie);
+}
+
+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 of_device_id brcm_pcie_match[] = {
+ { .compatible = "brcm,bcm7425-pcie", .data = &bcm7425_cfg },
+ { .compatible = "brcm,bcm7435-pcie", .data = &bcm7435_cfg },
+ { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, brcm_pcie_match);
+
+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 ret;
+ struct brcm_pcie *pcie;
+ struct resource *res;
+ void __iomem *base;
+ u32 tmp;
+ struct pci_host_bridge *bridge;
+ struct pci_bus *child;
+
+ 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_pcie_match, dn);
+ if (!of_id) {
+ dev_err(&pdev->dev, "failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
+ dev_err(&pdev->dev, "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;
+
+ /* We use the domain number as our controller number */
+ pcie->id = of_get_pci_domain_nr(dn);
+ if (pcie->id < 0)
+ return pcie->id;
+
+ 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;
+
+ ret = of_pci_get_max_link_speed(dn);
+ pcie->gen = (ret < 0) ? 0 : ret;
+
+ pcie->ssc = of_property_read_bool(dn, "brcm,enable-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_pcie_parse_request_of_pci_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;
+
+ ret = brcm_pcie_setup(pcie);
+ if (ret)
+ goto fail;
+
+ list_splice_init(&pcie->resources, &bridge->windows);
+ bridge->dev.parent = &pdev->dev;
+ bridge->busnr = 0;
+ bridge->ops = &brcm_pcie_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\n");
+ 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 const struct dev_pm_ops brcm_pcie_pm_ops = {
+ .suspend_noirq = brcm_pcie_suspend,
+ .resume_noirq = brcm_pcie_resume,
+};
+
+static struct platform_driver brcm_pcie_driver = {
+ .probe = brcm_pcie_probe,
+ .remove = brcm_pcie_remove,
+ .driver = {
+ .name = "brcm-pcie",
+ .owner = THIS_MODULE,
+ .of_match_table = brcm_pcie_match,
+ .pm = &brcm_pcie_pm_ops,
+ },
+};
+
+module_platform_driver(brcm_pcie_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Broadcom STB PCIe RC driver");
+MODULE_AUTHOR("Broadcom");
--
1.9.0.138.g2de3478
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. The method to do
this is to redefine the __dma_to_phys() and __phys_to_dma() functions
of the ARM, ARM64, and MIPS architectures. This commit sets up the
infrastructure in the Brcm PCIe controller to prepare for this, while
there is three other subsequent commits to implement/redefine these
two functions for the three target architectures.
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 130 ++++++++++++++++++++++++++++++----
include/soc/brcmstb/common.h | 16 +++++
2 files changed, 133 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 9c87d10..abfa429 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -21,6 +21,7 @@
#include <linux/printk.h>
#include <linux/sizes.h>
#include <linux/slab.h>
+#include <soc/brcmstb/common.h>
#include <soc/brcmstb/memory_api.h>
#include <linux/string.h>
#include <linux/types.h>
@@ -321,6 +322,7 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
(((val) & ~reg##_##field##_MASK) | \
(reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
+static struct of_pci_range *brcm_dma_ranges;
static phys_addr_t scb_size[BRCM_MAX_SCB];
static int num_memc;
static int num_pcie;
@@ -599,6 +601,79 @@ static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
}
+static int brcm_pcie_parse_map_dma_ranges(struct brcm_pcie *pcie)
+{
+ int i;
+ struct of_pci_range_parser parser;
+ struct device_node *dn = pcie->dn;
+
+ /*
+ * Parse dma-ranges property if present. If there are multiple
+ * PCIe controllers, we only have to parse from one of them since
+ * the others will have an identical mapping.
+ */
+ if (!of_pci_dma_range_parser_init(&parser, dn)) {
+ struct of_pci_range *p;
+ unsigned int max_ranges = (parser.end - parser.range)
+ / parser.np;
+
+ /* Add a null entry to indicate the end of the array */
+ brcm_dma_ranges = kcalloc(max_ranges + 1,
+ sizeof(struct of_pci_range),
+ GFP_KERNEL);
+ if (!brcm_dma_ranges)
+ return -ENOMEM;
+
+ p = brcm_dma_ranges;
+ while (of_pci_range_parser_one(&parser, p))
+ p++;
+ }
+
+ 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);
+ return -EINVAL;
+ } else if (size) {
+ scb_size[i] = roundup_pow_of_two_64(size);
+ num_memc++;
+ } else {
+ break;
+ }
+ }
+
+ return 0;
+}
+
+dma_addr_t brcm_phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+ struct of_pci_range *p;
+
+ if (!dev || !dev_is_pci(dev))
+ return (dma_addr_t)paddr;
+ for (p = brcm_dma_ranges; p && p->size; p++)
+ if (paddr >= p->cpu_addr && paddr < (p->cpu_addr + p->size))
+ return (dma_addr_t)(paddr - p->cpu_addr + p->pci_addr);
+
+ return (dma_addr_t)paddr;
+}
+
+phys_addr_t brcm_dma_to_phys(struct device *dev, dma_addr_t dev_addr)
+{
+ struct of_pci_range *p;
+
+ if (!dev || !dev_is_pci(dev))
+ return (phys_addr_t)dev_addr;
+ for (p = brcm_dma_ranges; p && p->size; p++)
+ if (dev_addr >= p->pci_addr
+ && dev_addr < (p->pci_addr + p->size))
+ return (phys_addr_t)
+ (dev_addr - p->pci_addr + p->cpu_addr);
+
+ return (phys_addr_t)dev_addr;
+}
+
static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
{
int i, ret = 0;
@@ -610,6 +685,10 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
goto done;
}
+ ret = brcm_pcie_parse_map_dma_ranges(pcie);
+ if (ret)
+ goto done;
+
/* Determine num_memc and their sizes */
for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
u64 size = brcmstb_memory_memc_size(i);
@@ -639,8 +718,13 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
{
mutex_lock(&brcm_pcie_lock);
- if (--num_pcie == 0)
- num_memc = 0;
+ if (--num_pcie > 0)
+ goto out;
+
+ kfree(brcm_dma_ranges);
+ brcm_dma_ranges = NULL;
+ num_memc = 0;
+out:
mutex_unlock(&brcm_pcie_lock);
}
@@ -747,11 +831,37 @@ static int brcm_pcie_setup(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 (brcm_dma_ranges) {
+ /*
+ * The best-case scenario is to place the inbound
+ * region in the first 4GB of pcie-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,
@@ -969,7 +1079,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
struct brcm_pcie *pcie;
struct resource *res;
void __iomem *base;
- u32 tmp;
struct pci_host_bridge *bridge;
struct pci_bus *child;
@@ -986,11 +1095,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
return -EINVAL;
}
- if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
- dev_err(&pdev->dev, "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;
diff --git a/include/soc/brcmstb/common.h b/include/soc/brcmstb/common.h
index cfb5335..a7f19e0 100644
--- a/include/soc/brcmstb/common.h
+++ b/include/soc/brcmstb/common.h
@@ -12,4 +12,20 @@
bool soc_is_brcmstb(void);
+#if defined(CONFIG_PCIE_BRCMSTB)
+dma_addr_t brcm_phys_to_dma(struct device *dev, phys_addr_t paddr);
+phys_addr_t brcm_dma_to_phys(struct device *dev, dma_addr_t dev_addr);
+#else
+static inline dma_addr_t brcm_phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+ return (dma_addr_t)paddr;
+}
+
+static inline phys_addr_t brcm_dma_to_phys(struct device *dev,
+ dma_addr_t dev_addr)
+{
+ return (phys_addr_t)dev_addr;
+}
+#endif
+
#endif /* __SOC_BRCMSTB_COMMON_H__ */
--
1.9.0.138.g2de3478
This change allows one to define custom routines for __phys_to_dma()
and __dma_to_phys() for the ARM64 architecture by selecting
ARCH_HAS_PHYS_TO_DMA. This is done for similar reasons that caused
arch/x86/include/asm/dma-direct.h to exist (see CONFIG_STA2X11).
Signed-off-by: Jim Quinlan <[email protected]>
---
arch/arm64/include/asm/dma-direct.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 arch/arm64/include/asm/dma-direct.h
diff --git a/arch/arm64/include/asm/dma-direct.h b/arch/arm64/include/asm/dma-direct.h
new file mode 100644
index 0000000..d87da92
--- /dev/null
+++ b/arch/arm64/include/asm/dma-direct.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ARM64_DMA_DIRECT_H
+#define _ARM64_DMA_DIRECT_H 1
+
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+ if (!dev->dma_mask)
+ return false;
+
+ return addr + size - 1 <= *dev->dma_mask;
+}
+
+dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr);
+phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr);
+
+#endif /* _ARM64_DMA_DIRECT_H */
--
1.9.0.138.g2de3478
The BrcmSTB PCIe controller needs to remap DMA accesses to it because
of the requirements of its interface with the SOC memory controllers.
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/Kconfig | 1 +
drivers/pci/controller/pcie-brcmstb.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 8daa621..4394430 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -284,6 +284,7 @@ config PCIE_BRCMSTB
depends on OF && PCI_MSI
depends on SOC_BRCMSTB
default ARCH_BRCMSTB || BMIPS_GENERIC
+ select ARCH_HAS_PHYS_TO_DMA if ARM64
help
Say Y here to enable PCIe host controller support for
Broadcom Settop Box SOCs. A Broadcom SOC will may have
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index a805d87..ae9df8e 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -974,6 +974,18 @@ phys_addr_t brcm_dma_to_phys(struct device *dev, dma_addr_t dev_addr)
return (phys_addr_t)dev_addr;
}
+#if defined(CONFIG_ARM64)
+dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+ return brcm_phys_to_dma(dev, paddr);
+}
+
+phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
+{
+ return brcm_dma_to_phys(dev, dev_addr);
+}
+#endif
+
static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
{
int i, ret = 0;
--
1.9.0.138.g2de3478
Adds the PCIe nodes for the Broadcom STB PCIe root complex.
Signed-off-by: Jim Quinlan <[email protected]>
---
arch/mips/boot/dts/brcm/bcm7425.dtsi | 28 ++++++++++++++++++++++++++++
arch/mips/boot/dts/brcm/bcm7435.dtsi | 28 ++++++++++++++++++++++++++++
arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 ++++
4 files changed, 64 insertions(+)
diff --git a/arch/mips/boot/dts/brcm/bcm7425.dtsi b/arch/mips/boot/dts/brcm/bcm7425.dtsi
index 410e61e..0edcbe4 100644
--- a/arch/mips/boot/dts/brcm/bcm7425.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7425.dtsi
@@ -584,4 +584,32 @@
};
};
};
+
+ pcie: pcie@10410000 {
+ reg = <0x10410000 0x830c>;
+ compatible = "brcm,bcm7425-pcie";
+ interrupts = <37>, <37>;
+ interrupt-names = "pcie", "msi";
+ interrupt-parent = <&periph_intc>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ linux,pci-domain = <0>;
+ brcm,enable-ssc;
+ bus-range = <0x00 0xff>;
+ msi-controller;
+ #interrupt-cells = <1>;
+ /* 4x128mb windows */
+ ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0x0 0x20000000>;
+ /* 768M or 1GB memc0, 0-1GB memc1 */
+ dma-ranges =
+ <0x02000000 0x0 0x00000000 0x00000000 0x0 0x10000000>,
+ <0x02000000 0x0 0x10000000 0x20000000 0x0 0x30000000>,
+ <0x02000000 0x0 0x40000000 0x90000000 0x0 0x40000000>;
+ 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 8398b7f..50bc7a0 100644
--- a/arch/mips/boot/dts/brcm/bcm7435.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7435.dtsi
@@ -599,4 +599,32 @@
};
};
};
+
+ pcie: pcie@10410000 {
+ reg = <0x10410000 0x930c>;
+ interrupts = <0x27>, <0x27>;
+ interrupt-names = "pcie", "msi";
+ interrupt-parent = <&periph_intc>;
+ compatible = "brcm,bcm7435-pcie";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ linux,pci-domain = <0>;
+ brcm,enable-ssc;
+ bus-range = <0x00 0xff>;
+ msi-controller;
+ #interrupt-cells = <1>;
+ ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0x0 0x20000000>;
+ /* 768M or 1GB memc0, 0-1GB memc1 */
+ dma-ranges =
+ <0x02000000 0x0 0x00000000 0x00000000 0x0 0x10000000>,
+ <0x02000000 0x0 0x10000000 0x20000000 0x0 0x30000000>,
+ <0x02000000 0x0 0x40000000 0x90000000 0x0 0x40000000>;
+ 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 0ed2221..22270a9 100644
--- a/arch/mips/boot/dts/brcm/bcm97425svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97425svmb.dts
@@ -152,3 +152,7 @@
&waketimer {
status = "okay";
};
+
+&pcie {
+ status = "okay";
+};
diff --git a/arch/mips/boot/dts/brcm/bcm97435svmb.dts b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
index 2c145a8..91bc1ec 100644
--- a/arch/mips/boot/dts/brcm/bcm97435svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
@@ -128,3 +128,7 @@
&waketimer {
status = "okay";
};
+
+&pcie {
+ status = "okay";
+};
--
1.9.0.138.g2de3478
The BrcmSTB PCIe controller needs to remap DMA accesses to it because
of the requirements of its interface with the SOC memory controllers.
In the ARM64 and MIPs architectures, this is accomplished by
CONFIG_ARCH_HAS_PHYS_TO_DMA=y and then defining the functions
__dma_to_phys() and __phys_to_dma() accordingly.
Doing so for the ARM architecture is not as easy as ARM64 and MIPS;
the two functions are already defined as static inline functions.
Howevery, the behavior of these functions may be changed by redefining
the sub-functions that these two functions invoke.
Specifically, this commit defines
__arch_pfn_to_dma()
__arch_dma_to_pfn()
__arch_dma_to_virt()
__arch_virt_to_dma()
as these are the functions invoked by __dma_to_phys() and
__phys_to_dma(). Unfortunately, the only apparent approach to do this
is to declare and define the four sub-functions in
arch/arm/mach-bcm/include/mach/memory.h, and in doing so we must move
out of ARCH_MULTIPLATFORM and create brcmstb_defconfig, as we were
previously using multi_v7_defconfig.
Signed-off-by: Jim Quinlan <[email protected]>
---
arch/arm/Kconfig | 33 +++++
arch/arm/configs/brcmstb_defconfig | 204 ++++++++++++++++++++++++++++
arch/arm/configs/multi_v7_defconfig | 3 -
arch/arm/mach-bcm/Kconfig | 21 +--
arch/arm/mach-bcm/Makefile.boot | 0
arch/arm/mach-bcm/include/mach/irqs.h | 3 +
arch/arm/mach-bcm/include/mach/memory.h | 47 +++++++
arch/arm/mach-bcm/include/mach/uncompress.h | 8 ++
8 files changed, 296 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/configs/brcmstb_defconfig
create mode 100644 arch/arm/mach-bcm/Makefile.boot
create mode 100644 arch/arm/mach-bcm/include/mach/irqs.h
create mode 100644 arch/arm/mach-bcm/include/mach/memory.h
create mode 100644 arch/arm/mach-bcm/include/mach/uncompress.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e8cd55a..913765b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -637,6 +637,39 @@ config ARCH_OMAP1
help
Support for older TI OMAP1 (omap7xx, omap15xx or omap16xx)
+config ARCH_BRCMSTB
+ bool "Broadcom BCM7XXX based boards"
+ select ARM_HAS_SG_CHAIN
+ select ARM_PATCH_PHYS_VIRT
+ select TIMER_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select MULTI_IRQ_HANDLER
+ select MIGHT_HAVE_PCI
+ select PCI_DOMAINS if PCI
+ select USE_OF
+
+ select CPU_V7
+ select ARCH_BCM
+ select HAVE_SMP
+ select AUTO_ZRELADDR
+ select ARM_GIC
+ select ARM_GIC_V3
+ select HAVE_ARM_ARCH_TIMER
+ select SPARSE_IRQ
+ select BRCMSTB_L2_IRQ
+ select BCM7120_L2_IRQ
+ select ARCH_HAS_HOLES_MEMORYMODEL
+ select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+ select ZONE_DMA if ARM_LPAE
+ select NEED_MACH_MEMORY_H
+ help
+ Say Y if you intend to run the kernel on a Broadcom ARM-based STB
+ chipset.
+
+ This enables support for Broadcom ARM-based set-top box chipsets,
+ including the 7445 family of chips.
+
endchoice
menu "Multiple platform selection"
diff --git a/arch/arm/configs/brcmstb_defconfig b/arch/arm/configs/brcmstb_defconfig
new file mode 100644
index 0000000..572fcf32
--- /dev/null
+++ b/arch/arm/configs/brcmstb_defconfig
@@ -0,0 +1,204 @@
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IRQ_TIME_ACCOUNTING=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CGROUPS=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="romfs"
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_ARCH_BRCMSTB=y
+CONFIG_ARM_LPAE=y
+CONFIG_ARM_THUMBEE=y
+CONFIG_ARM_ERRATA_430973=y
+CONFIG_ARM_ERRATA_720789=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_ARM_ERRATA_754327=y
+CONFIG_ARM_ERRATA_764369=y
+CONFIG_ARM_ERRATA_775420=y
+CONFIG_ARM_ERRATA_798181=y
+CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_MSI=y
+CONFIG_SMP=y
+CONFIG_MCPM=y
+CONFIG_NR_CPUS=16
+CONFIG_ARM_PSCI=y
+CONFIG_HZ_1000=y
+CONFIG_HIGHMEM=y
+CONFIG_CMA=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_EFI=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
+CONFIG_CPU_IDLE=y
+CONFIG_VFP=y
+CONFIG_PM_DEBUG=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_UDP_DIAG=y
+CONFIG_TCP_CONG_ADVANCED=y
+CONFIG_TCP_CONG_BIC=y
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+# CONFIG_IPV6 is not set
+CONFIG_BRIDGE=y
+CONFIG_NET_DSA=y
+CONFIG_CFG80211=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_DMA_CMA=y
+CONFIG_CMA_ALIGNMENT=9
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_ROM=y
+CONFIG_MTD_ABSENT=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_BRCMNAND=y
+CONFIG_MTD_SPI_NOR=y
+# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_EEPROM_93CX6=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_ATA=y
+CONFIG_SATA_AHCI_PLATFORM=y
+CONFIG_AHCI_BRCM=y
+CONFIG_NETDEVICES=y
+CONFIG_NET_DSA_BCM_SF2=y
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_CADENCE is not set
+CONFIG_BCMGENET=y
+CONFIG_SYSTEMPORT=y
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MELLANOX is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_USB_PEGASUS=y
+CONFIG_USB_USBNET=y
+# CONFIG_USB_NET_NET1080 is not set
+# CONFIG_USB_NET_CDC_SUBSET is not set
+# CONFIG_USB_NET_ZAURUS is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_MOUSE_PS2_ELANTECH=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_UINPUT=y
+# CONFIG_SERIO_SERPORT is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_SPI=y
+CONFIG_SPI_BITBANG=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_RESET=y
+# CONFIG_HWMON is not set
+CONFIG_MFD_SYSCON=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_USB_SUPPORT=y
+CONFIG_USB_GSPCA=y
+CONFIG_DRM=y
+CONFIG_SOUND=m
+CONFIG_SND=m
+CONFIG_SND_SOC=m
+CONFIG_USB=y
+CONFIG_USB_MON=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_MASS_STORAGE=y
+CONFIG_MMC=y
+CONFIG_MMC_BLOCK_MINORS=16
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_RTC_CLASS=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_INA2XX_ADC=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_PHY_BRCM_SATA=y
+CONFIG_EXT4_FS=y
+CONFIG_JBD2_DEBUG=y
+CONFIG_FUSE_FS=y
+CONFIG_CUSE=y
+CONFIG_ISO9660_FS=y
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_UBIFS_FS=y
+CONFIG_CRAMFS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_LZO=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_NFS_V4_2=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_INFO_REDUCED=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC_CCITT=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fc33444..33c91f8 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -17,7 +17,6 @@ CONFIG_ARCH_AT91=y
CONFIG_SOC_SAMA5D2=y
CONFIG_SOC_SAMA5D3=y
CONFIG_SOC_SAMA5D4=y
-CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_CYGNUS=y
CONFIG_ARCH_BCM_HR2=y
CONFIG_ARCH_BCM_NSP=y
@@ -26,7 +25,6 @@ CONFIG_ARCH_BCM_281XX=y
CONFIG_ARCH_BCM_21664=y
CONFIG_ARCH_BCM2835=y
CONFIG_ARCH_BCM_63XX=y
-CONFIG_ARCH_BRCMSTB=y
CONFIG_ARCH_BERLIN=y
CONFIG_MACH_BERLIN_BG2=y
CONFIG_MACH_BERLIN_BG2CD=y
@@ -229,7 +227,6 @@ CONFIG_B53_MMAP_DRIVER=m
CONFIG_B53_SRAB_DRIVER=m
CONFIG_NET_DSA_BCM_SF2=m
CONFIG_SUN4I_EMAC=y
-CONFIG_BCMGENET=m
CONFIG_BGMAC_BCMA=y
CONFIG_SYSTEMPORT=m
CONFIG_MACB=y
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 25aac6e..2c3ad42 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
menuconfig ARCH_BCM
bool "Broadcom SoC Support"
- depends on ARCH_MULTI_V6_V7
+ depends on ARCH_BRCMSTB
help
This enables support for Broadcom ARM based SoC chips
@@ -203,23 +203,4 @@ config ARCH_BCM_63XX
It currently supports the 'BCM63XX' ARM-based family, which includes
the BCM63138 variant.
-config ARCH_BRCMSTB
- bool "Broadcom BCM7XXX based boards"
- depends on ARCH_MULTI_V7
- select ARM_GIC
- select ARM_ERRATA_798181 if SMP
- select HAVE_ARM_ARCH_TIMER
- select BRCMSTB_L2_IRQ
- select BCM7120_L2_IRQ
- select ARCH_HAS_HOLES_MEMORYMODEL
- select ZONE_DMA if ARM_LPAE
- select SOC_BRCMSTB
- select SOC_BUS
- help
- Say Y if you intend to run the kernel on a Broadcom ARM-based STB
- chipset.
-
- This enables support for Broadcom ARM-based set-top box chipsets,
- including the 7445 family of chips.
-
endif
diff --git a/arch/arm/mach-bcm/Makefile.boot b/arch/arm/mach-bcm/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-bcm/include/mach/irqs.h b/arch/arm/mach-bcm/include/mach/irqs.h
new file mode 100644
index 0000000..f1f3f22
--- /dev/null
+++ b/arch/arm/mach-bcm/include/mach/irqs.h
@@ -0,0 +1,3 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#define NR_IRQS NR_IRQS_LEGACY
diff --git a/arch/arm/mach-bcm/include/mach/memory.h b/arch/arm/mach-bcm/include/mach/memory.h
new file mode 100644
index 0000000..a90a216
--- /dev/null
+++ b/arch/arm/mach-bcm/include/mach/memory.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_ARCH_MEMORY_H__
+#define __ASM_ARCH_MEMORY_H__
+#ifndef __ASSEMBLY__
+
+struct device;
+
+#include <soc/brcmstb/common.h>
+
+#ifdef CONFIG_PCIE_BRCMSTB
+#define __arch_pfn_to_dma(dev, pfn) \
+ ({ \
+ if (dev) \
+ pfn -= dev->dma_pfn_offset; \
+ (dma_addr_t)brcm_phys_to_dma(dev, __pfn_to_phys(pfn)); \
+ })
+
+#define __arch_dma_to_pfn(dev, addr) \
+ ({ \
+ unsigned long pfn = __phys_to_pfn(brcm_dma_to_phys(dev, addr));\
+ if (dev) \
+ pfn += dev->dma_pfn_offset; \
+ pfn; \
+ })
+
+#define __arch_dma_to_virt(dev, addr) \
+ ({ \
+ void *v; \
+ if (dev) { \
+ unsigned long pfn = dma_to_pfn(dev, addr); \
+ v = phys_to_virt(__pfn_to_phys(pfn)); \
+ } else { \
+ v = (void *)__bus_to_virt((unsigned long)addr); \
+ } \
+ v; \
+ })
+
+#define __arch_virt_to_dma(dev, addr) \
+ ({ \
+ (dev) ? pfn_to_dma(dev, virt_to_pfn(addr)) \
+ : (dma_addr_t)__virt_to_bus((unsigned long)(addr));\
+ })
+
+#endif /* CONFIG_PCIE_BRCMSTB */
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_ARCH_MEMORY_H__ */
diff --git a/arch/arm/mach-bcm/include/mach/uncompress.h b/arch/arm/mach-bcm/include/mach/uncompress.h
new file mode 100644
index 0000000..b297333
--- /dev/null
+++ b/arch/arm/mach-bcm/include/mach/uncompress.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifdef CONFIG_DEBUG_UNCOMPRESS
+void putc(int c);
+#else
+static inline void putc(int c) {}
+#endif
+static inline void flush(void) {}
+static inline void arch_decomp_setup(void) {}
--
1.9.0.138.g2de3478
The design of the Broadcom PCIe RC controller requires us to remap its
DMA addresses for inbound traffic. We do this by modifying the
definitions of __phys_to_dma() and __dma_to_phys().
In arch/mips/bmips/dma.c, these functions are already in use to remap
DMA addresses for the 338x SOC chips. We leave this code alone -- and
give its mapping priority -- but if it is not in use, the PCIe DMA
mapping is in effect.
One might think that the two DMA remapping systems of dma.c could be
combined, but they cannot: one governs only DMA addresses for the PCIe
controller of BrcmSTB ARM/ARM64/MIPs chips, while the other governs
the PCIe controller *and* other peripherals for only MIPs 338x
chips.
Signed-off-by: Jim Quinlan <[email protected]>
---
arch/mips/bmips/dma.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
index 3d13c77..292994f 100644
--- a/arch/mips/bmips/dma.c
+++ b/arch/mips/bmips/dma.c
@@ -18,6 +18,7 @@
#include <linux/slab.h>
#include <linux/types.h>
#include <asm/bmips.h>
+#include <soc/brcmstb/common.h>
/*
* BCM338x has configurable address translation windows which allow the
@@ -44,6 +45,10 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
{
struct bmips_dma_range *r;
+#ifdef CONFIG_PCIE_BRCMSTB
+ if (!bmips_dma_ranges)
+ return brcm_phys_to_dma(dev, pa);
+#endif
for (r = bmips_dma_ranges; r && r->size; r++) {
if (pa >= r->child_addr &&
pa < (r->child_addr + r->size))
@@ -56,6 +61,10 @@ phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
{
struct bmips_dma_range *r;
+#ifdef CONFIG_PCIE_BRCMSTB
+ if (!bmips_dma_ranges)
+ return (unsigned long)brcm_dma_to_phys(dev, dma_addr);
+#endif
for (r = bmips_dma_ranges; r && r->size; r++) {
if (dma_addr >= r->parent_addr &&
dma_addr < (r->parent_addr + r->size))
--
1.9.0.138.g2de3478
Adds the Kconfig hooks to enable the Broadcom STB PCIe root complex
driver for Broadcom MIPS systems.
Signed-off-by: Jim Quinlan <[email protected]>
---
arch/mips/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 3551199..a15c0da 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -220,6 +220,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
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 <[email protected]>
---
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pcie-brcmstb.c | 361 ++++++++++++++++++++++++++++++++--
2 files changed, 351 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index c863c67..8daa621 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -281,7 +281,7 @@ config VMD
config PCIE_BRCMSTB
bool "Broadcom Brcmstb PCIe host controller"
depends on ARCH_BRCMSTB || BMIPS_GENERIC
- depends on OF
+ depends on OF && PCI_MSI
depends on SOC_BRCMSTB
default ARCH_BRCMSTB || BMIPS_GENERIC
help
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index abfa429..a805d87 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (C) 2009 - 2018 Broadcom */
+#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/compiler.h>
#include <linux/delay.h>
@@ -8,11 +9,13 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/ioport.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
#include <linux/kernel.h>
#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>
@@ -48,6 +51,9 @@
#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_MSI_BAR_CONFIG_LO 0x4044
+#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
+#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
#define PCIE_MISC_PCIE_CTRL 0x4064
#define PCIE_MISC_PCIE_STATUS 0x4068
#define PCIE_MISC_REVISION 0x406c
@@ -56,6 +62,7 @@
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
#define PCIE_INTR2_CPU_BASE 0x4300
+#define PCIE_MSI_INTR2_BASE 0x4500
/*
* Broadcom Settop Box PCIe Register Field shift and mask info. The
@@ -116,6 +123,8 @@
#define BRCM_NUM_PCIE_OUT_WINS 0x4
#define BRCM_MAX_SCB 0x4
+#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_PCIE_HW_REV_33 0x0303
#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
@@ -204,6 +213,33 @@ struct brcm_window {
dma_addr_t size;
};
+struct brcm_msi {
+ struct device *dev;
+ void __iomem *base;
+ struct device_node *dn;
+ 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;
+ unsigned int rev;
+};
+
/* Internal PCIe Host Controller Information.*/
struct brcm_pcie {
struct device *dev;
@@ -218,7 +254,10 @@ struct brcm_pcie {
int num_out_wins;
bool ssc;
int gen;
+ u64 msi_target_addr;
struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
+ struct brcm_msi *msi;
+ bool msi_internal;
unsigned int rev;
const int *reg_offsets;
const int *reg_field_info;
@@ -535,6 +574,267 @@ static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
}
}
+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;
+ struct device *dev;
+
+ chained_irq_enter(chip, desc);
+ msi = irq_desc_get_handler_data(desc);
+ mask = msi->intr_legacy_mask;
+ dev = msi->dev;
+
+ 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(dev, "unhandled MSI %d\n",
+ hwirq);
+ } else {
+ /* Unknown MSI, just clear it */
+ dev_dbg(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);
+}
+
+static 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);
+}
+
+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);
+ struct device *dev = msi->dev;
+
+ msi->inner_domain = irq_domain_add_linear(NULL, BRCM_INT_PCI_MSI_NR,
+ &msi_domain_ops, msi);
+ if (!msi->inner_domain) {
+ dev_err(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(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);
+}
+
+static void brcm_msi_remove(struct brcm_pcie *pcie)
+{
+ struct brcm_msi *msi = pcie->msi;
+
+ if (!msi)
+ return;
+ irq_set_chained_handler(msi->irq, NULL);
+ irq_set_handler_data(msi->irq, NULL);
+ brcm_free_domains(msi);
+}
+
+static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
+{
+ struct brcm_msi *msi;
+ int irq, ret;
+ struct device *dev = pcie->dev;
+
+ irq = irq_of_parse_and_map(dev->of_node, 1);
+ if (irq <= 0) {
+ dev_err(dev, "cannot map msi intr\n");
+ return -ENODEV;
+ }
+
+ msi = devm_kzalloc(dev, sizeof(struct brcm_msi), GFP_KERNEL);
+ if (!msi)
+ return -ENOMEM;
+
+ msi->dev = dev;
+ msi->base = pcie->base;
+ msi->rev = pcie->rev;
+ msi->dn = pcie->dn;
+ msi->target_addr = pcie->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);
+ pcie->msi = msi;
+
+ return 0;
+}
+
/* Configuration space read/write support */
static int cfg_index(int busnr, int devfn, int reg)
{
@@ -776,6 +1076,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
u16 nlw, cls, lnksta;
bool ssc_good = false;
struct device *dev = pcie->dev;
+ u64 msi_target_addr;
/* Reset the bridge */
brcm_pcie_bridge_sw_init_set(pcie, 1);
@@ -820,14 +1121,17 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
* The PCIe 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 pcie-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
+ * pcie-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);
@@ -843,6 +1147,15 @@ static int brcm_pcie_setup(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
@@ -852,8 +1165,12 @@ static int brcm_pcie_setup(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
@@ -861,7 +1178,12 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
* 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,
@@ -1036,6 +1358,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;
@@ -1043,6 +1368,7 @@ static int brcm_pcie_resume(struct device *dev)
static void _brcm_pcie_remove(struct brcm_pcie *pcie)
{
+ brcm_msi_remove(pcie);
turn_off(pcie);
clk_disable_unprepare(pcie->clk);
clk_put(pcie->clk);
@@ -1072,7 +1398,7 @@ static int brcm_pcie_remove(struct platform_device *pdev)
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 ret;
@@ -1152,6 +1478,20 @@ 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 (pci_msi_enabled() && msi_dn == pcie->dn) {
+ ret = brcm_pcie_enable_msi(pcie);
+ if (ret)
+ dev_err(pcie->dev,
+ "probe of internal MSI failed: %d)", ret);
+ else
+ pcie->msi_internal = true;
+ }
+
list_splice_init(&pcie->resources, &bridge->windows);
bridge->dev.parent = &pdev->dev;
bridge->busnr = 0;
@@ -1174,7 +1514,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
pcie->root_bus = bridge->bus;
return 0;
-
fail:
_brcm_pcie_remove(pcie);
return ret;
--
1.9.0.138.g2de3478
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 <[email protected]>
---
drivers/pci/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 56ff8f6..61a9539 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -22,7 +22,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
This is useless on its own. Please merge it into whatever patch
selects ARCH_HAS_PHYS_TO_DMA and actually implements the functions.
On Wed, Sep 19, 2018 at 10:32:06AM -0400, Jim Quinlan wrote:
> +#if defined(CONFIG_ARM64)
Please use plain #ifdef where possible.
> +dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
> +{
> + return brcm_phys_to_dma(dev, paddr);
> +}
> +
> +phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> +{
> + return brcm_dma_to_phys(dev, dev_addr);
> +}
> +#endif
How is this going to work for a kernel with BrcmSTB built in, but running
on a more standard arm64 SOC?
I suspect we really just want a set of ranges hanging off struct device
(conditional on a config option). Each SoC can then fill it at boot
time, and if it is non-NULL the DMA code will use it instead of
calling __phys_to_dma and __dma_to_phys. In fact the single range
version could probably just replace the existing dma_pfn_offset
field.
On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
>
So is describing this as
dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
<0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
<0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
<0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
<0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
<0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
not working for you? I haven't tried this myself, but since DT permits
describing the inbound mappings this way, we should fix the code if it
doesn't work at the moment.
> 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. The method to do
> this is to redefine the __dma_to_phys() and __phys_to_dma() functions
> of the ARM, ARM64, and MIPS architectures. This commit sets up the
> infrastructure in the Brcm PCIe controller to prepare for this, while
> there is three other subsequent commits to implement/redefine these
> two functions for the three target architectures.
>
> Signed-off-by: Jim Quinlan <[email protected]>
> ---
> drivers/pci/controller/pcie-brcmstb.c | 130 ++++++++++++++++++++++++++++++----
> include/soc/brcmstb/common.h | 16 +++++
> 2 files changed, 133 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index 9c87d10..abfa429 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -21,6 +21,7 @@
> #include <linux/printk.h>
> #include <linux/sizes.h>
> #include <linux/slab.h>
> +#include <soc/brcmstb/common.h>
> #include <soc/brcmstb/memory_api.h>
> #include <linux/string.h>
> #include <linux/types.h>
> @@ -321,6 +322,7 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
> (((val) & ~reg##_##field##_MASK) | \
> (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
>
> +static struct of_pci_range *brcm_dma_ranges;
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> static int num_memc;
> static int num_pcie;
> @@ -599,6 +601,79 @@ static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
> WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
> }
>
> +static int brcm_pcie_parse_map_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + /*
> + * Parse dma-ranges property if present. If there are multiple
> + * PCIe controllers, we only have to parse from one of them since
> + * the others will have an identical mapping.
> + */
> + if (!of_pci_dma_range_parser_init(&parser, dn)) {
> + struct of_pci_range *p;
> + unsigned int max_ranges = (parser.end - parser.range)
> + / parser.np;
> +
> + /* Add a null entry to indicate the end of the array */
> + brcm_dma_ranges = kcalloc(max_ranges + 1,
> + sizeof(struct of_pci_range),
> + GFP_KERNEL);
> + if (!brcm_dma_ranges)
> + return -ENOMEM;
> +
> + p = brcm_dma_ranges;
> + while (of_pci_range_parser_one(&parser, p))
> + p++;
> + }
> +
> + 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);
> + return -EINVAL;
> + } else if (size) {
> + scb_size[i] = roundup_pow_of_two_64(size);
> + num_memc++;
> + } else {
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +dma_addr_t brcm_phys_to_dma(struct device *dev, phys_addr_t paddr)
> +{
> + struct of_pci_range *p;
> +
> + if (!dev || !dev_is_pci(dev))
> + return (dma_addr_t)paddr;
> + for (p = brcm_dma_ranges; p && p->size; p++)
> + if (paddr >= p->cpu_addr && paddr < (p->cpu_addr + p->size))
> + return (dma_addr_t)(paddr - p->cpu_addr + p->pci_addr);
> +
> + return (dma_addr_t)paddr;
> +}
> +
> +phys_addr_t brcm_dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!dev || !dev_is_pci(dev))
> + return (phys_addr_t)dev_addr;
> + for (p = brcm_dma_ranges; p && p->size; p++)
> + if (dev_addr >= p->pci_addr
> + && dev_addr < (p->pci_addr + p->size))
> + return (phys_addr_t)
> + (dev_addr - p->pci_addr + p->cpu_addr);
> +
> + return (phys_addr_t)dev_addr;
> +}
> +
> static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> {
> int i, ret = 0;
> @@ -610,6 +685,10 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> goto done;
> }
>
> + ret = brcm_pcie_parse_map_dma_ranges(pcie);
> + if (ret)
> + goto done;
> +
> /* Determine num_memc and their sizes */
> for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
> u64 size = brcmstb_memory_memc_size(i);
> @@ -639,8 +718,13 @@ static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> {
> mutex_lock(&brcm_pcie_lock);
> - if (--num_pcie == 0)
> - num_memc = 0;
> + if (--num_pcie > 0)
> + goto out;
> +
> + kfree(brcm_dma_ranges);
> + brcm_dma_ranges = NULL;
> + num_memc = 0;
> +out:
> mutex_unlock(&brcm_pcie_lock);
> }
>
> @@ -747,11 +831,37 @@ static int brcm_pcie_setup(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 (brcm_dma_ranges) {
> + /*
> + * The best-case scenario is to place the inbound
> + * region in the first 4GB of pcie-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,
> @@ -969,7 +1079,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> struct brcm_pcie *pcie;
> struct resource *res;
> void __iomem *base;
> - u32 tmp;
> struct pci_host_bridge *bridge;
> struct pci_bus *child;
>
> @@ -986,11 +1095,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
> - dev_err(&pdev->dev, "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;
> diff --git a/include/soc/brcmstb/common.h b/include/soc/brcmstb/common.h
> index cfb5335..a7f19e0 100644
> --- a/include/soc/brcmstb/common.h
> +++ b/include/soc/brcmstb/common.h
> @@ -12,4 +12,20 @@
>
> bool soc_is_brcmstb(void);
>
> +#if defined(CONFIG_PCIE_BRCMSTB)
> +dma_addr_t brcm_phys_to_dma(struct device *dev, phys_addr_t paddr);
> +phys_addr_t brcm_dma_to_phys(struct device *dev, dma_addr_t dev_addr);
> +#else
> +static inline dma_addr_t brcm_phys_to_dma(struct device *dev, phys_addr_t paddr)
> +{
> + return (dma_addr_t)paddr;
> +}
> +
> +static inline phys_addr_t brcm_dma_to_phys(struct device *dev,
> + dma_addr_t dev_addr)
> +{
> + return (phys_addr_t)dev_addr;
> +}
> +#endif
> +
> #endif /* __SOC_BRCMSTB_COMMON_H__ */
> --
> 1.9.0.138.g2de3478
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 19 September 2018 at 16:31, Jim Quinlan <[email protected]> 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.
Oh, hey, *one* email made it finally through :P
>
> Signed-off-by: Jim Quinlan <[email protected]>
> Acked-by: Rob Herring <[email protected]>
> ---
> .../devicetree/bindings/pci/brcmstb-pcie.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt b/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
> new file mode 100644
> index 0000000..a1a9ad5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
> @@ -0,0 +1,59 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Required Properties:
> +- compatible
> + "brcm,bcm7425-pcie" -- for 7425 family MIPS-based SOCs.
> + "brcm,bcm7435-pcie" -- for 7435 family MIPS-based SOCs.
> + "brcm,bcm7445-pcie" -- for 7445 and later ARM based SOCs (not including
> + the 7278).
> + "brcm,bcm7278-pcie" -- for 7278 family ARM-based SOCs.
> +
> +- reg -- the register start address and length for the PCIe reg block.
> +- 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".
> +- #address-cells -- set to <3>.
> +- #size-cells -- set to <2>.
> +- #interrupt-cells: set to <1>.
> +- interrupt-map-mask and interrupt-map, standard PCI properties to define the
> + mapping of the PCIe interface to interrupt numbers.
> +- ranges: ranges for the PCI memory and I/O regions.
> +- linux,pci-domain -- should be unique per host controller.
> +
> +Optional Properties:
> +- clocks -- phandle of pcie clock.
> +- clock-names -- set to "sw_pcie" if clocks is used.
> +- dma-ranges -- Specifies the inbound memory mapping regions when
> + an "identity map" is not possible.
> +- msi-controller -- this property is typically specified to have the
> + PCIe controller use its internal MSI controller.
> +- msi-parent -- set to use an external MSI interrupt controller.
> +- brcm,enable-ssc -- (boolean) indicates usage of spread-spectrum clocking.
> +- max-link-speed -- (integer) indicates desired generation of link:
> + 1 => 2.5 Gbps (gen1), 2 => 5.0 Gbps (gen2), 3 => 8.0 Gbps (gen3).
> +
> +Example Node:
> +
> +pcie0: pcie@f0460000 {
> + reg = <0x0 0xf0460000 0x0 0x9310>;
> + interrupts = <0x0 0x0 0x4>;
Your binding says two interrupts, your example has three - what's the
third interrupt for? Also you define the same for MSI and PCIe (I
assume) - is that expected? Are there systems where they are
different? I would expect the msi interrupt to be optional for the
case where its the same as the pcie one, and only required if it is
different.
Also your binding requires an interrupt-names propery, but it's
missing from the example.
> + compatible = "brcm,bcm7445-pcie";
> + #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>;
> + 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;
> + max-link-speed = <1>;
> + linux,pci-domain = <0>;
> + };
> --
> 1.9.0.138.g2de3478
>
Regards
Jonas
On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
>>
>
> So is describing this as
>
> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>
> not working for you? I haven't tried this myself, but since DT permits
> describing the inbound mappings this way, we should fix the code if it
> doesn't work at the moment.
You mean encoding the memory controller index in the first cell? If that
works, that's indeed a much cleaner solution, though is it standard
compliant in any form?
--
Florian
On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
>>>
>>
>> So is describing this as
>>
>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>
>> not working for you? I haven't tried this myself, but since DT permits
>> describing the inbound mappings this way, we should fix the code if it
>> doesn't work at the moment.
>
> You mean encoding the memory controller index in the first cell? If that
> works, that's indeed a much cleaner solution, though is it standard
> compliant in any form?
No those are just memory addresses (although I may have screwed up the
order). From Documentation/devicetree/booting-without-of.txt:
"""
Optional property:
- dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
(child-bus-address, parent-bus-address, length). Each triplet specified
describes a contiguous DMA address range.
"""
On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
>>>>
>>>
>>> So is describing this as
>>>
>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>>
>>> not working for you? I haven't tried this myself, but since DT permits
>>> describing the inbound mappings this way, we should fix the code if it
>>> doesn't work at the moment.
>>
>> You mean encoding the memory controller index in the first cell? If that
>> works, that's indeed a much cleaner solution, though is it standard
>> compliant in any form?
>
> No those are just memory addresses (although I may have screwed up the
> order). From Documentation/devicetree/booting-without-of.txt:
>
> """
> Optional property:
> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
> (child-bus-address, parent-bus-address, length). Each triplet specified
> describes a contiguous DMA address range.
> """
>
Then I am confused by your comment, that's what this patch does, it adds
support for reading "dma-ranges" from Device Tree and setting up inbound
windows using that. The only caveat is that because the PCIe root
complex has some ties with the memory bus architecture it is connected
to (SCB in our case) there is still a requirement to know the
translation between a given physical address and its backing memory
controller/aperture.
--
Florian
On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
>>>>>
>>>>
>>>> So is describing this as
>>>>
>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>>>
>>>> not working for you? I haven't tried this myself, but since DT permits
>>>> describing the inbound mappings this way, we should fix the code if it
>>>> doesn't work at the moment.
>>>
>>> You mean encoding the memory controller index in the first cell? If that
>>> works, that's indeed a much cleaner solution, though is it standard
>>> compliant in any form?
>>
>> No those are just memory addresses (although I may have screwed up the
>> order). From Documentation/devicetree/booting-without-of.txt:
>>
>> """
>> Optional property:
>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
>> (child-bus-address, parent-bus-address, length). Each triplet specified
>> describes a contiguous DMA address range.
>> """
>>
>
> Then I am confused by your comment, that's what this patch does, it adds
> support for reading "dma-ranges" from Device Tree and setting up inbound
> windows using that. The only caveat is that because the PCIe root
> complex has some ties with the memory bus architecture it is connected
> to (SCB in our case) there is still a requirement to know the
> translation between a given physical address and its backing memory
> controller/aperture.
>
Ah ok, apologies for the noise then.
I was hoping that having working support for dma-ranges would remove
the need for the special phys<->dma conversion routines.
On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
> On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
>>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
>>>>>>
>>>>>
>>>>> So is describing this as
>>>>>
>>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>>>>
>>>>> not working for you? I haven't tried this myself, but since DT permits
>>>>> describing the inbound mappings this way, we should fix the code if it
>>>>> doesn't work at the moment.
>>>>
>>>> You mean encoding the memory controller index in the first cell? If that
>>>> works, that's indeed a much cleaner solution, though is it standard
>>>> compliant in any form?
>>>
>>> No those are just memory addresses (although I may have screwed up the
>>> order). From Documentation/devicetree/booting-without-of.txt:
>>>
>>> """
>>> Optional property:
>>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
>>> (child-bus-address, parent-bus-address, length). Each triplet specified
>>> describes a contiguous DMA address range.
>>> """
>>>
>>
>> Then I am confused by your comment, that's what this patch does, it adds
>> support for reading "dma-ranges" from Device Tree and setting up inbound
>> windows using that. The only caveat is that because the PCIe root
>> complex has some ties with the memory bus architecture it is connected
>> to (SCB in our case) there is still a requirement to know the
>> translation between a given physical address and its backing memory
>> controller/aperture.
>>
>
> Ah ok, apologies for the noise then.
>
> I was hoping that having working support for dma-ranges would remove
> the need for the special phys<->dma conversion routines.
What you describe definitively works with platform devices, but I am not
sure this is working for PCIe devices, although, conceptually it should,
yes.
--
Florian
On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli <[email protected]> wrote:
>
> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
> > On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
> >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> >>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
> >>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> >>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
> >>>>>>
> >>>>>
> >>>>> So is describing this as
> >>>>>
> >>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
> >>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
> >>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
> >>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
> >>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
> >>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
> >>>>>
> >>>>> not working for you? I haven't tried this myself, but since DT permits
> >>>>> describing the inbound mappings this way, we should fix the code if it
> >>>>> doesn't work at the moment.
> >>>>
> >>>> You mean encoding the memory controller index in the first cell? If that
> >>>> works, that's indeed a much cleaner solution, though is it standard
> >>>> compliant in any form?
> >>>
> >>> No those are just memory addresses (although I may have screwed up the
> >>> order). From Documentation/devicetree/booting-without-of.txt:
> >>>
> >>> """
> >>> Optional property:
> >>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
> >>> (child-bus-address, parent-bus-address, length). Each triplet specified
> >>> describes a contiguous DMA address range.
> >>> """
> >>>
> >>
> >> Then I am confused by your comment, that's what this patch does, it adds
> >> support for reading "dma-ranges" from Device Tree and setting up inbound
> >> windows using that. The only caveat is that because the PCIe root
> >> complex has some ties with the memory bus architecture it is connected
> >> to (SCB in our case) there is still a requirement to know the
> >> translation between a given physical address and its backing memory
> >> controller/aperture.
> >>
> >
> > Ah ok, apologies for the noise then.
> >
> > I was hoping that having working support for dma-ranges would remove
> > the need for the special phys<->dma conversion routines.
>
> What you describe definitively works with platform devices, but I am not
> sure this is working for PCIe devices, although, conceptually it should,
> yes.
Sorry for my delay in responding. One problem is that
of_dma_configure() only looks at the first dma-range given and then
converts it to dev->dma_pfn_offset which is respected by the DMA API.
However, we often have multiple dma-ranges, not just one. This is the
big issue.
There is another issue with of_dma_configure() being invoked by the EP
driver on "bridge->parent->of_node", which is our RC device,
Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of
our RC's device node and this misses the dma-ranges property which is
contained within the RC. I think I could workaround this but there is
no getting around the first problem.
Thanks,
Jim
> --
> Florian
On Thu, Sep 20, 2018 at 5:06 AM Jonas Gorski <[email protected]> wrote:
>
> On 19 September 2018 at 16:31, Jim Quinlan <[email protected]> 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.
>
> Oh, hey, *one* email made it finally through :P
Sigh, I'm still having email issues, my apologies.
>
> >
> > Signed-off-by: Jim Quinlan <[email protected]>
> > Acked-by: Rob Herring <[email protected]>
> > ---
> > .../devicetree/bindings/pci/brcmstb-pcie.txt | 59 ++++++++++++++++++++++
> > 1 file changed, 59 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt b/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
> > new file mode 100644
> > index 0000000..a1a9ad5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
> > @@ -0,0 +1,59 @@
> > +Brcmstb PCIe Host Controller Device Tree Bindings
> > +
> > +Required Properties:
> > +- compatible
> > + "brcm,bcm7425-pcie" -- for 7425 family MIPS-based SOCs.
> > + "brcm,bcm7435-pcie" -- for 7435 family MIPS-based SOCs.
> > + "brcm,bcm7445-pcie" -- for 7445 and later ARM based SOCs (not including
> > + the 7278).
> > + "brcm,bcm7278-pcie" -- for 7278 family ARM-based SOCs.
> > +
> > +- reg -- the register start address and length for the PCIe reg block.
> > +- 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".
> > +- #address-cells -- set to <3>.
> > +- #size-cells -- set to <2>.
> > +- #interrupt-cells: set to <1>.
> > +- interrupt-map-mask and interrupt-map, standard PCI properties to define the
> > + mapping of the PCIe interface to interrupt numbers.
> > +- ranges: ranges for the PCI memory and I/O regions.
> > +- linux,pci-domain -- should be unique per host controller.
> > +
> > +Optional Properties:
> > +- clocks -- phandle of pcie clock.
> > +- clock-names -- set to "sw_pcie" if clocks is used.
> > +- dma-ranges -- Specifies the inbound memory mapping regions when
> > + an "identity map" is not possible.
> > +- msi-controller -- this property is typically specified to have the
> > + PCIe controller use its internal MSI controller.
> > +- msi-parent -- set to use an external MSI interrupt controller.
> > +- brcm,enable-ssc -- (boolean) indicates usage of spread-spectrum clocking.
> > +- max-link-speed -- (integer) indicates desired generation of link:
> > + 1 => 2.5 Gbps (gen1), 2 => 5.0 Gbps (gen2), 3 => 8.0 Gbps (gen3).
> > +
> > +Example Node:
> > +
> > +pcie0: pcie@f0460000 {
> > + reg = <0x0 0xf0460000 0x0 0x9310>;
> > + interrupts = <0x0 0x0 0x4>;
>
> Your binding says two interrupts, your example has three - what's the
> third interrupt for?
Actually that's a single interrupt with three cells. I need to add
another interrupt. Note that we have #interrupt-cells set to 1
because that is for the legacy interrupts given in the interrupt-map.
> Also you define the same for MSI and PCIe (I assume) - is that expected?
No, these will be updated to two different interrupts.
Are there systems where they are
> different? I would expect the msi interrupt to be optional for the
> case where its the same as the pcie one, and only required if it is
> different.
>
> Also your binding requires an interrupt-names propery, but it's
> missing from the example.
Will fix.
Thanks,
Jim
>
> > + compatible = "brcm,bcm7445-pcie";
> > + #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>;
> > + 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;
> > + max-link-speed = <1>;
> > + linux,pci-domain = <0>;
> > + };
> > --
> > 1.9.0.138.g2de3478
> >
>
> Regards
> Jonas
On Wed, Sep 19, 2018 at 10:41 AM Christoph Hellwig <[email protected]> wrote:
>
> On Wed, Sep 19, 2018 at 10:32:06AM -0400, Jim Quinlan wrote:
> > +#if defined(CONFIG_ARM64)
>
> Please use plain #ifdef where possible.
>
> > +dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
> > +{
> > + return brcm_phys_to_dma(dev, paddr);
> > +}
> > +
> > +phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> > +{
> > + return brcm_dma_to_phys(dev, dev_addr);
> > +}
> > +#endif
>
> How is this going to work for a kernel with BrcmSTB built in, but running
> on a more standard arm64 SOC?
Sorry for the delay in my response. It would work because the
dma_ranges would be empty/null and identity mapping would happen, but
yes, all __dma_to_phys and __phys_to_dma calls would be wasting time
going through the brcm functions. We would have to take BRCMSTB=y out
of the defconfig. Florian would probably NAK that idea.
Please remember that the reason for this approach is because in your
response to V4 you suggested that "Override phys_to_dma and
dma_to_phys as mips and x86 [sta2x11] do for similar situations" and
"Overriding phys_to_dma and dma_to_phys is required if you need to
support swiotlb, and chances are with a broken PCIe controller on
arm64 or mips64 you eventuall will".
>
> I suspect we really just want a set of ranges hanging off struct device
> (conditional on a config option). Each SoC can then fill it at boot
> time, and if it is non-NULL the DMA code will use it instead of
> calling __phys_to_dma and __dma_to_phys. In fact the single range
> version could probably just replace the existing dma_pfn_offset
> field.
If this was a config option then BRCMSTB=y in defconfig would set this
for all ARM64, just like the above case, correct? And would this work
with SWIOTLB? Also, do you think others would use it, or would I be
adding code in the DMA API only because of one unusual PCIe host
controller design? Keep in mind that although you didn't like the
approach of V4 -- which intercepted DMA ops to make the appropriate
mapping and was not compatible with SWIOTLB -- at least it kept the
code restricted to oru driver.
Thanks,
Jim
On Fri, 21 Sep 2018 at 19:41, Jim Quinlan <[email protected]> wrote:
>
> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli <[email protected]> wrote:
> >
> > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
> > > On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
> > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> > >>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
> > >>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> > >>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
> > >>>>>>
> > >>>>>
> > >>>>> So is describing this as
> > >>>>>
> > >>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
> > >>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
> > >>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
> > >>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
> > >>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
> > >>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
> > >>>>>
> > >>>>> not working for you? I haven't tried this myself, but since DT permits
> > >>>>> describing the inbound mappings this way, we should fix the code if it
> > >>>>> doesn't work at the moment.
> > >>>>
> > >>>> You mean encoding the memory controller index in the first cell? If that
> > >>>> works, that's indeed a much cleaner solution, though is it standard
> > >>>> compliant in any form?
> > >>>
> > >>> No those are just memory addresses (although I may have screwed up the
> > >>> order). From Documentation/devicetree/booting-without-of.txt:
> > >>>
> > >>> """
> > >>> Optional property:
> > >>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
> > >>> (child-bus-address, parent-bus-address, length). Each triplet specified
> > >>> describes a contiguous DMA address range.
> > >>> """
> > >>>
> > >>
> > >> Then I am confused by your comment, that's what this patch does, it adds
> > >> support for reading "dma-ranges" from Device Tree and setting up inbound
> > >> windows using that. The only caveat is that because the PCIe root
> > >> complex has some ties with the memory bus architecture it is connected
> > >> to (SCB in our case) there is still a requirement to know the
> > >> translation between a given physical address and its backing memory
> > >> controller/aperture.
> > >>
> > >
> > > Ah ok, apologies for the noise then.
> > >
> > > I was hoping that having working support for dma-ranges would remove
> > > the need for the special phys<->dma conversion routines.
> >
> > What you describe definitively works with platform devices, but I am not
> > sure this is working for PCIe devices, although, conceptually it should,
> > yes.
> Sorry for my delay in responding. One problem is that
> of_dma_configure() only looks at the first dma-range given and then
> converts it to dev->dma_pfn_offset which is respected by the DMA API.
> However, we often have multiple dma-ranges, not just one. This is the
> big issue.
>
Given the recent attention to getting these APIs in shape, this may be
something Robin or Christoph may care to look into?
In any case, the description of dma-ranges should be in sync with the
way Linux interprets it, so this is either a documentation bug or a
DMA layer bug.
> There is another issue with of_dma_configure() being invoked by the EP
> driver on "bridge->parent->of_node", which is our RC device,
> Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of
> our RC's device node and this misses the dma-ranges property which is
> contained within the RC. I think I could workaround this but there is
> no getting around the first problem.
>
IIUC dma-ranges should be added to the parent bus of a device, which I
guess is slightly ambiguous for a root complex that incorporates a
host bridge.
On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel
<[email protected]> wrote:
>
> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan <[email protected]> wrote:
> >
> > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli <[email protected]> wrote:
> > >
> > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
> > > > On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
> > > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> > > >>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
> > > >>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> > > >>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
> > > >>>>>>
> > > >>>>>
> > > >>>>> So is describing this as
> > > >>>>>
> > > >>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
> > > >>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
> > > >>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
> > > >>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
> > > >>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
> > > >>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
> > > >>>>>
> > > >>>>> not working for you? I haven't tried this myself, but since DT permits
> > > >>>>> describing the inbound mappings this way, we should fix the code if it
> > > >>>>> doesn't work at the moment.
> > > >>>>
> > > >>>> You mean encoding the memory controller index in the first cell? If that
> > > >>>> works, that's indeed a much cleaner solution, though is it standard
> > > >>>> compliant in any form?
> > > >>>
> > > >>> No those are just memory addresses (although I may have screwed up the
> > > >>> order). From Documentation/devicetree/booting-without-of.txt:
> > > >>>
> > > >>> """
> > > >>> Optional property:
> > > >>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
> > > >>> (child-bus-address, parent-bus-address, length). Each triplet specified
> > > >>> describes a contiguous DMA address range.
> > > >>> """
> > > >>>
> > > >>
> > > >> Then I am confused by your comment, that's what this patch does, it adds
> > > >> support for reading "dma-ranges" from Device Tree and setting up inbound
> > > >> windows using that. The only caveat is that because the PCIe root
> > > >> complex has some ties with the memory bus architecture it is connected
> > > >> to (SCB in our case) there is still a requirement to know the
> > > >> translation between a given physical address and its backing memory
> > > >> controller/aperture.
> > > >>
> > > >
> > > > Ah ok, apologies for the noise then.
> > > >
> > > > I was hoping that having working support for dma-ranges would remove
> > > > the need for the special phys<->dma conversion routines.
> > >
> > > What you describe definitively works with platform devices, but I am not
> > > sure this is working for PCIe devices, although, conceptually it should,
> > > yes.
> > Sorry for my delay in responding. One problem is that
> > of_dma_configure() only looks at the first dma-range given and then
> > converts it to dev->dma_pfn_offset which is respected by the DMA API.
> > However, we often have multiple dma-ranges, not just one. This is the
> > big issue.
> >
>
> Given the recent attention to getting these APIs in shape, this may be
> something Robin or Christoph may care to look into?
It looks like this has been brought up before in the "[RFC PATCH] of:
Fix DMA configuration for non-DT masters" thread aka
https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html
In the thread "Oza Oza", a Broadcom coworker probably dealing with the
same exact problem as I, enumerates three problems. #1 and #2 are
the exact same ones I've just given: the "dma-ranges" prop of the RC
DT node is "skipped", and of_dma_get_range() only considers the first
entry in any "dma-ranges".
Thanks, Jim
>
> In any case, the description of dma-ranges should be in sync with the
> way Linux interprets it, so this is either a documentation bug or a
> DMA layer bug.
>
> > There is another issue with of_dma_configure() being invoked by the EP
> > driver on "bridge->parent->of_node", which is our RC device,
> > Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of
> > our RC's device node and this misses the dma-ranges property which is
> > contained within the RC. I think I could workaround this but there is
> > no getting around the first problem.
> >
>
> IIUC dma-ranges should be added to the parent bus of a device, which I
> guess is slightly ambiguous for a root complex that incorporates a
> host bridge.
On 9/24/2018 8:01 AM, Jim Quinlan wrote:
> On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel
> <[email protected]> wrote:
>>
>> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan <[email protected]> wrote:
>>>
>>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli <[email protected]> wrote:
>>>>
>>>> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
>>>>> On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
>>>>>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>>>>>>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
>>>>>>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>>>>>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So is describing this as
>>>>>>>>>
>>>>>>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>>>>>>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>>>>>>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>>>>>>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>>>>>>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>>>>>>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>>>>>>>>
>>>>>>>>> not working for you? I haven't tried this myself, but since DT permits
>>>>>>>>> describing the inbound mappings this way, we should fix the code if it
>>>>>>>>> doesn't work at the moment.
>>>>>>>>
>>>>>>>> You mean encoding the memory controller index in the first cell? If that
>>>>>>>> works, that's indeed a much cleaner solution, though is it standard
>>>>>>>> compliant in any form?
>>>>>>>
>>>>>>> No those are just memory addresses (although I may have screwed up the
>>>>>>> order). From Documentation/devicetree/booting-without-of.txt:
>>>>>>>
>>>>>>> """
>>>>>>> Optional property:
>>>>>>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
>>>>>>> (child-bus-address, parent-bus-address, length). Each triplet specified
>>>>>>> describes a contiguous DMA address range.
>>>>>>> """
>>>>>>>
>>>>>>
>>>>>> Then I am confused by your comment, that's what this patch does, it adds
>>>>>> support for reading "dma-ranges" from Device Tree and setting up inbound
>>>>>> windows using that. The only caveat is that because the PCIe root
>>>>>> complex has some ties with the memory bus architecture it is connected
>>>>>> to (SCB in our case) there is still a requirement to know the
>>>>>> translation between a given physical address and its backing memory
>>>>>> controller/aperture.
>>>>>>
>>>>>
>>>>> Ah ok, apologies for the noise then.
>>>>>
>>>>> I was hoping that having working support for dma-ranges would remove
>>>>> the need for the special phys<->dma conversion routines.
>>>>
>>>> What you describe definitively works with platform devices, but I am not
>>>> sure this is working for PCIe devices, although, conceptually it should,
>>>> yes.
>>> Sorry for my delay in responding. One problem is that
>>> of_dma_configure() only looks at the first dma-range given and then
>>> converts it to dev->dma_pfn_offset which is respected by the DMA API.
>>> However, we often have multiple dma-ranges, not just one. This is the
>>> big issue.
>>>
>>
>> Given the recent attention to getting these APIs in shape, this may be
>> something Robin or Christoph may care to look into?
>
> It looks like this has been brought up before in the "[RFC PATCH] of:
> Fix DMA configuration for non-DT masters" thread aka
>
> https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html
>
> In the thread "Oza Oza", a Broadcom coworker probably dealing with the
> same exact problem as I, enumerates three problems. #1 and #2 are
> the exact same ones I've just given: the "dma-ranges" prop of the RC
> DT node is "skipped", and of_dma_get_range() only considers the first
> entry in any "dma-ranges".
Robin, is that something that is expected or should the "dma-ranges"
somehow propagate from host bridge down the PCIe end-point drivers?
>
> Thanks, Jim
>
>>
>> In any case, the description of dma-ranges should be in sync with the
>> way Linux interprets it, so this is either a documentation bug or a
>> DMA layer bug.
>>
>>> There is another issue with of_dma_configure() being invoked by the EP
>>> driver on "bridge->parent->of_node", which is our RC device,
>>> Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of
>>> our RC's device node and this misses the dma-ranges property which is
>>> contained within the RC. I think I could workaround this but there is
>>> no getting around the first problem.
>>>
>>
>> IIUC dma-ranges should be added to the parent bus of a device, which I
>> guess is slightly ambiguous for a root complex that incorporates a
>> host bridge.
Humm, why is that ambiguous for a host bridge/root complex?
--
Florian
On Wed, 26 Sep 2018 at 04:59, Florian Fainelli <[email protected]> wrote:
>
>
>
> On 9/24/2018 8:01 AM, Jim Quinlan wrote:
> > On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel
> > <[email protected]> wrote:
> >>
> >> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan <[email protected]> wrote:
> >>>
> >>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli <[email protected]> wrote:
> >>>>
> >>>> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
> >>>>> On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
> >>>>>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> >>>>>>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
> >>>>>>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
> >>>>>>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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]
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So is describing this as
> >>>>>>>>>
> >>>>>>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
> >>>>>>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
> >>>>>>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
> >>>>>>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
> >>>>>>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
> >>>>>>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
> >>>>>>>>>
> >>>>>>>>> not working for you? I haven't tried this myself, but since DT permits
> >>>>>>>>> describing the inbound mappings this way, we should fix the code if it
> >>>>>>>>> doesn't work at the moment.
> >>>>>>>>
> >>>>>>>> You mean encoding the memory controller index in the first cell? If that
> >>>>>>>> works, that's indeed a much cleaner solution, though is it standard
> >>>>>>>> compliant in any form?
> >>>>>>>
> >>>>>>> No those are just memory addresses (although I may have screwed up the
> >>>>>>> order). From Documentation/devicetree/booting-without-of.txt:
> >>>>>>>
> >>>>>>> """
> >>>>>>> Optional property:
> >>>>>>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
> >>>>>>> (child-bus-address, parent-bus-address, length). Each triplet specified
> >>>>>>> describes a contiguous DMA address range.
> >>>>>>> """
> >>>>>>>
> >>>>>>
> >>>>>> Then I am confused by your comment, that's what this patch does, it adds
> >>>>>> support for reading "dma-ranges" from Device Tree and setting up inbound
> >>>>>> windows using that. The only caveat is that because the PCIe root
> >>>>>> complex has some ties with the memory bus architecture it is connected
> >>>>>> to (SCB in our case) there is still a requirement to know the
> >>>>>> translation between a given physical address and its backing memory
> >>>>>> controller/aperture.
> >>>>>>
> >>>>>
> >>>>> Ah ok, apologies for the noise then.
> >>>>>
> >>>>> I was hoping that having working support for dma-ranges would remove
> >>>>> the need for the special phys<->dma conversion routines.
> >>>>
> >>>> What you describe definitively works with platform devices, but I am not
> >>>> sure this is working for PCIe devices, although, conceptually it should,
> >>>> yes.
> >>> Sorry for my delay in responding. One problem is that
> >>> of_dma_configure() only looks at the first dma-range given and then
> >>> converts it to dev->dma_pfn_offset which is respected by the DMA API.
> >>> However, we often have multiple dma-ranges, not just one. This is the
> >>> big issue.
> >>>
> >>
> >> Given the recent attention to getting these APIs in shape, this may be
> >> something Robin or Christoph may care to look into?
> >
> > It looks like this has been brought up before in the "[RFC PATCH] of:
> > Fix DMA configuration for non-DT masters" thread aka
> >
> > https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html
> >
> > In the thread "Oza Oza", a Broadcom coworker probably dealing with the
> > same exact problem as I, enumerates three problems. #1 and #2 are
> > the exact same ones I've just given: the "dma-ranges" prop of the RC
> > DT node is "skipped", and of_dma_get_range() only considers the first
> > entry in any "dma-ranges".
>
> Robin, is that something that is expected or should the "dma-ranges"
> somehow propagate from host bridge down the PCIe end-point drivers?
>
> >
> > Thanks, Jim
> >
> >>
> >> In any case, the description of dma-ranges should be in sync with the
> >> way Linux interprets it, so this is either a documentation bug or a
> >> DMA layer bug.
> >>
> >>> There is another issue with of_dma_configure() being invoked by the EP
> >>> driver on "bridge->parent->of_node", which is our RC device,
> >>> Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of
> >>> our RC's device node and this misses the dma-ranges property which is
> >>> contained within the RC. I think I could workaround this but there is
> >>> no getting around the first problem.
> >>>
> >>
> >> IIUC dma-ranges should be added to the parent bus of a device, which I
> >> guess is slightly ambiguous for a root complex that incorporates a
> >> host bridge.
>
> Humm, why is that ambiguous for a host bridge/root complex?
Well, perhaps I am the only one who is slightly confused by this, but
the fact that the device node describes both the host bridge and the
root port/bridge (which is arguably a device behind the bus) makes it
somewhat non-intuitive to me.
On 26/09/18 03:59, Florian Fainelli wrote:
>
>
> On 9/24/2018 8:01 AM, Jim Quinlan wrote:
>> On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel
>> <[email protected]> wrote:
>>>
>>> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan <[email protected]> wrote:
>>>>
>>>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli
>>>> <[email protected]> wrote:
>>>>>
>>>>> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
>>>>>> On 20 September 2018 at 14:31, Florian Fainelli
>>>>>> <[email protected]> wrote:
>>>>>>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>>>>>>>> On 20 September 2018 at 13:55, Florian Fainelli
>>>>>>>> <[email protected]> wrote:
>>>>>>>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>>>>>>>>> On 19 September 2018 at 07:31, Jim Quinlan
>>>>>>>>>> <[email protected]> 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]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So is describing this as
>>>>>>>>>>
>>>>>>>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>>>>>>>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>>>>>>>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>>>>>>>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>>>>>>>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>>>>>>>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>>>>>>>>>
>>>>>>>>>> not working for you? I haven't tried this myself, but since DT
>>>>>>>>>> permits
>>>>>>>>>> describing the inbound mappings this way, we should fix the
>>>>>>>>>> code if it
>>>>>>>>>> doesn't work at the moment.
>>>>>>>>>
>>>>>>>>> You mean encoding the memory controller index in the first
>>>>>>>>> cell? If that
>>>>>>>>> works, that's indeed a much cleaner solution, though is it
>>>>>>>>> standard
>>>>>>>>> compliant in any form?
>>>>>>>>
>>>>>>>> No those are just memory addresses (although I may have screwed
>>>>>>>> up the
>>>>>>>> order). From Documentation/devicetree/booting-without-of.txt:
>>>>>>>>
>>>>>>>> """
>>>>>>>> Optional property:
>>>>>>>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number
>>>>>>>> of triplets of
>>>>>>>> (child-bus-address, parent-bus-address, length). Each
>>>>>>>> triplet specified
>>>>>>>> describes a contiguous DMA address range.
>>>>>>>> """
>>>>>>>>
>>>>>>>
>>>>>>> Then I am confused by your comment, that's what this patch does,
>>>>>>> it adds
>>>>>>> support for reading "dma-ranges" from Device Tree and setting up
>>>>>>> inbound
>>>>>>> windows using that. The only caveat is that because the PCIe root
>>>>>>> complex has some ties with the memory bus architecture it is
>>>>>>> connected
>>>>>>> to (SCB in our case) there is still a requirement to know the
>>>>>>> translation between a given physical address and its backing memory
>>>>>>> controller/aperture.
>>>>>>>
>>>>>>
>>>>>> Ah ok, apologies for the noise then.
>>>>>>
>>>>>> I was hoping that having working support for dma-ranges would remove
>>>>>> the need for the special phys<->dma conversion routines.
>>>>>
>>>>> What you describe definitively works with platform devices, but I
>>>>> am not
>>>>> sure this is working for PCIe devices, although, conceptually it
>>>>> should,
>>>>> yes.
>>>> Sorry for my delay in responding. One problem is that
>>>> of_dma_configure() only looks at the first dma-range given and then
>>>> converts it to dev->dma_pfn_offset which is respected by the DMA API.
>>>> However, we often have multiple dma-ranges, not just one. This is the
>>>> big issue.
>>>>
>>>
>>> Given the recent attention to getting these APIs in shape, this may be
>>> something Robin or Christoph may care to look into?
>>
>> It looks like this has been brought up before in the "[RFC PATCH] of:
>> Fix DMA configuration for non-DT masters" thread aka
>>
>> https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html
>>
>> In the thread "Oza Oza", a Broadcom coworker probably dealing with the
>> same exact problem as I, enumerates three problems. #1 and #2 are
>> the exact same ones I've just given: the "dma-ranges" prop of the RC
>> DT node is "skipped", and of_dma_get_range() only considers the first
>> entry in any "dma-ranges".
>
> Robin, is that something that is expected or should the "dma-ranges"
> somehow propagate from host bridge down the PCIe end-point drivers?
Nope, the code is most definitely incomplete - it's sufficient to
support the system it was originally needed for (i.e. platform devices
with a single range), but can by no means even pretend to support the
binding fully. Furthermore, the way that PCI support was later grafted
into of_dma_configure() was *only* in support of dma-coherent without
consideration for dma-ranges. Hence the current mess.
>>
>> Thanks, Jim
>>
>>>
>>> In any case, the description of dma-ranges should be in sync with the
>>> way Linux interprets it, so this is either a documentation bug or a
>>> DMA layer bug.
>>>
>>>> There is another issue with of_dma_configure() being invoked by the EP
>>>> driver on "bridge->parent->of_node", which is our RC device,
>>>> Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of
>>>> our RC's device node and this misses the dma-ranges property which is
>>>> contained within the RC. I think I could workaround this but there is
>>>> no getting around the first problem.
>>>>
>>>
>>> IIUC dma-ranges should be added to the parent bus of a device, which I
>>> guess is slightly ambiguous for a root complex that incorporates a
>>> host bridge.
>
> Humm, why is that ambiguous for a host bridge/root complex?
The real problem is that FDT machines don't describe the PCI hierarchy
in DT as proper OF does, so we have this awkward crossing between the DT
model and the Linux device model where the devices have no DT
representation and the "parent bus" is a DT leaf node, which cocks up
the way the current code is expecting to work.
Robin.
Hi Jim,
On Wed, Sep 19, 2018 at 10:32:01AM -0400, Jim Quinlan wrote:
> The design of the Broadcom PCIe RC controller requires us to remap its
> DMA addresses for inbound traffic. We do this by modifying the
> definitions of __phys_to_dma() and __dma_to_phys().
>
> In arch/mips/bmips/dma.c, these functions are already in use to remap
> DMA addresses for the 338x SOC chips. We leave this code alone -- and
> give its mapping priority -- but if it is not in use, the PCIe DMA
> mapping is in effect.
>
> One might think that the two DMA remapping systems of dma.c could be
> combined, but they cannot: one governs only DMA addresses for the PCIe
> controller of BrcmSTB ARM/ARM64/MIPs chips, while the other governs
> the PCIe controller *and* other peripherals for only MIPs 338x
> chips.
>
> Signed-off-by: Jim Quinlan <[email protected]>
> ---
> arch/mips/bmips/dma.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Please copy me/linux-mips on the whole series next time - I seem to have
only received patches 6, 8 & 9 which means I have no idea whether they
have dependencies & if so whether those dependencies have been accepted
or rejected. I also have no clue whether these patches make sense to
take through the MIPS tree or if it would make more sense for someone
else to take them with acks.
> diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
> index 3d13c77..292994f 100644
> --- a/arch/mips/bmips/dma.c
> +++ b/arch/mips/bmips/dma.c
> @@ -18,6 +18,7 @@
> #include <linux/slab.h>
> #include <linux/types.h>
> #include <asm/bmips.h>
> +#include <soc/brcmstb/common.h>
>
> /*
> * BCM338x has configurable address translation windows which allow the
> @@ -44,6 +45,10 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
> {
> struct bmips_dma_range *r;
>
> +#ifdef CONFIG_PCIE_BRCMSTB
> + if (!bmips_dma_ranges)
> + return brcm_phys_to_dma(dev, pa);
> +#endif
> for (r = bmips_dma_ranges; r && r->size; r++) {
> if (pa >= r->child_addr &&
> pa < (r->child_addr + r->size))
I can't tell because I presume brcm_phys_to_dma() is added in one of
those patches I wasn't copied on, but perhaps you could avoid the #ifdef
by just returning brcm_phys_to_dma(dev, pa) after the loop?
> @@ -56,6 +61,10 @@ phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
> {
> struct bmips_dma_range *r;
>
> +#ifdef CONFIG_PCIE_BRCMSTB
> + if (!bmips_dma_ranges)
> + return (unsigned long)brcm_dma_to_phys(dev, dma_addr);
> +#endif
> for (r = bmips_dma_ranges; r && r->size; r++) {
> if (dma_addr >= r->parent_addr &&
> dma_addr < (r->parent_addr + r->size))
And similar here.
Thanks,
Paul
On Wed, Sep 26, 2018 at 6:07 PM Paul Burton <[email protected]> wrote:
>
> Hi Jim,
>
> On Wed, Sep 19, 2018 at 10:32:01AM -0400, Jim Quinlan wrote:
> > The design of the Broadcom PCIe RC controller requires us to remap its
> > DMA addresses for inbound traffic. We do this by modifying the
> > definitions of __phys_to_dma() and __dma_to_phys().
> >
> > In arch/mips/bmips/dma.c, these functions are already in use to remap
> > DMA addresses for the 338x SOC chips. We leave this code alone -- and
> > give its mapping priority -- but if it is not in use, the PCIe DMA
> > mapping is in effect.
> >
> > One might think that the two DMA remapping systems of dma.c could be
> > combined, but they cannot: one governs only DMA addresses for the PCIe
> > controller of BrcmSTB ARM/ARM64/MIPs chips, while the other governs
> > the PCIe controller *and* other peripherals for only MIPs 338x
> > chips.
> >
> > Signed-off-by: Jim Quinlan <[email protected]>
> > ---
> > arch/mips/bmips/dma.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
>
> Please copy me/linux-mips on the whole series next time - I seem to have
> only received patches 6, 8 & 9 which means I have no idea whether they
> have dependencies & if so whether those dependencies have been accepted
> or rejected. I also have no clue whether these patches make sense to
> take through the MIPS tree or if it would make more sense for someone
> else to take them with acks.
Hi Paul,
I had problem with the first time I sent this out and someone said I
should reduce me email list so I used the "git email --cc_cmd
get_mainters.pl". I'll switch back to an aggregate email list.
>
> > diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
> > index 3d13c77..292994f 100644
> > --- a/arch/mips/bmips/dma.c
> > +++ b/arch/mips/bmips/dma.c
> > @@ -18,6 +18,7 @@
> > #include <linux/slab.h>
> > #include <linux/types.h>
> > #include <asm/bmips.h>
> > +#include <soc/brcmstb/common.h>
> >
> > /*
> > * BCM338x has configurable address translation windows which allow the
> > @@ -44,6 +45,10 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
> > {
> > struct bmips_dma_range *r;
> >
> > +#ifdef CONFIG_PCIE_BRCMSTB
> > + if (!bmips_dma_ranges)
> > + return brcm_phys_to_dma(dev, pa);
> > +#endif
> > for (r = bmips_dma_ranges; r && r->size; r++) {
> > if (pa >= r->child_addr &&
> > pa < (r->child_addr + r->size))
>
> I can't tell because I presume brcm_phys_to_dma() is added in one of
> those patches I wasn't copied on, but perhaps you could avoid the #ifdef
> by just returning brcm_phys_to_dma(dev, pa) after the loop?
Yes, will rectify in next version.
>
> > @@ -56,6 +61,10 @@ phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
> > {
> > struct bmips_dma_range *r;
> >
> > +#ifdef CONFIG_PCIE_BRCMSTB
> > + if (!bmips_dma_ranges)
> > + return (unsigned long)brcm_dma_to_phys(dev, dma_addr);
> > +#endif
> > for (r = bmips_dma_ranges; r && r->size; r++) {
> > if (dma_addr >= r->parent_addr &&
> > dma_addr < (r->parent_addr + r->size))
>
> And similar here.
>
Okay, thanks,
Jim
> Thanks,
> Paul
On 09/26/2018 03:56 AM, Robin Murphy wrote:
> On 26/09/18 03:59, Florian Fainelli wrote:
>>
>>
>> On 9/24/2018 8:01 AM, Jim Quinlan wrote:
>>> On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel
>>> <[email protected]> wrote:
>>>>
>>>> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan <[email protected]> wrote:
>>>>>
>>>>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
>>>>>>> On 20 September 2018 at 14:31, Florian Fainelli
>>>>>>> <[email protected]> wrote:
>>>>>>>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>>>>>>>>> On 20 September 2018 at 13:55, Florian Fainelli
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>>>>>>>>>> On 19 September 2018 at 07:31, Jim Quinlan
>>>>>>>>>>> <[email protected]> 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]
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So is describing this as
>>>>>>>>>>>
>>>>>>>>>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>>>>>>>>>>> <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>>>>>>>>>>> <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>>>>>>>>>>> <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>>>>>>>>>>> <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>>>>>>>>>>> <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>>>>>>>>>>
>>>>>>>>>>> not working for you? I haven't tried this myself, but since
>>>>>>>>>>> DT permits
>>>>>>>>>>> describing the inbound mappings this way, we should fix the
>>>>>>>>>>> code if it
>>>>>>>>>>> doesn't work at the moment.
>>>>>>>>>>
>>>>>>>>>> You mean encoding the memory controller index in the first
>>>>>>>>>> cell? If that
>>>>>>>>>> works, that's indeed a much cleaner solution, though is it
>>>>>>>>>> standard
>>>>>>>>>> compliant in any form?
>>>>>>>>>
>>>>>>>>> No those are just memory addresses (although I may have screwed
>>>>>>>>> up the
>>>>>>>>> order). From Documentation/devicetree/booting-without-of.txt:
>>>>>>>>>
>>>>>>>>> """
>>>>>>>>> Optional property:
>>>>>>>>> - dma-ranges: <prop-encoded-array> encoded as arbitrary number
>>>>>>>>> of triplets of
>>>>>>>>> (child-bus-address, parent-bus-address, length). Each
>>>>>>>>> triplet specified
>>>>>>>>> describes a contiguous DMA address range.
>>>>>>>>> """
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then I am confused by your comment, that's what this patch does,
>>>>>>>> it adds
>>>>>>>> support for reading "dma-ranges" from Device Tree and setting up
>>>>>>>> inbound
>>>>>>>> windows using that. The only caveat is that because the PCIe root
>>>>>>>> complex has some ties with the memory bus architecture it is
>>>>>>>> connected
>>>>>>>> to (SCB in our case) there is still a requirement to know the
>>>>>>>> translation between a given physical address and its backing memory
>>>>>>>> controller/aperture.
>>>>>>>>
>>>>>>>
>>>>>>> Ah ok, apologies for the noise then.
>>>>>>>
>>>>>>> I was hoping that having working support for dma-ranges would remove
>>>>>>> the need for the special phys<->dma conversion routines.
>>>>>>
>>>>>> What you describe definitively works with platform devices, but I
>>>>>> am not
>>>>>> sure this is working for PCIe devices, although, conceptually it
>>>>>> should,
>>>>>> yes.
>>>>> Sorry for my delay in responding. One problem is that
>>>>> of_dma_configure() only looks at the first dma-range given and then
>>>>> converts it to dev->dma_pfn_offset which is respected by the DMA API.
>>>>> However, we often have multiple dma-ranges, not just one. This is the
>>>>> big issue.
>>>>>
>>>>
>>>> Given the recent attention to getting these APIs in shape, this may be
>>>> something Robin or Christoph may care to look into?
>>>
>>> It looks like this has been brought up before in the "[RFC PATCH] of:
>>> Fix DMA configuration for non-DT masters" thread aka
>>>
>>> https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html
>>>
>>> In the thread "Oza Oza", a Broadcom coworker probably dealing with the
>>> same exact problem as I, enumerates three problems. #1 and #2 are
>>> the exact same ones I've just given: the "dma-ranges" prop of the RC
>>> DT node is "skipped", and of_dma_get_range() only considers the first
>>> entry in any "dma-ranges".
>>
>> Robin, is that something that is expected or should the "dma-ranges"
>> somehow propagate from host bridge down the PCIe end-point drivers?
>
> Nope, the code is most definitely incomplete - it's sufficient to
> support the system it was originally needed for (i.e. platform devices
> with a single range), but can by no means even pretend to support the
> binding fully. Furthermore, the way that PCI support was later grafted
> into of_dma_configure() was *only* in support of dma-coherent without
> consideration for dma-ranges. Hence the current mess.
Is this the way we should go? If the PCIe root complex has a
"dma-ranges" property, we need to make sure that all child devices
behind it get that translation applied as well? Right now we tried to
follow Christoph's recommendations from the v1 through v4 submissions,
but that does not really seem to be working well.
I am really not a fan of having to go audit every architecture, and
possibly insert the right translation in there, while introducing a
possible layering problem too...
>
>>>
>>> Thanks, Jim
>>>
>>>>
>>>> In any case, the description of dma-ranges should be in sync with the
>>>> way Linux interprets it, so this is either a documentation bug or a
>>>> DMA layer bug.
>>>>
>>>>> There is another issue with of_dma_configure() being invoked by the EP
>>>>> driver on "bridge->parent->of_node", which is our RC device,
>>>>> Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of
>>>>> our RC's device node and this misses the dma-ranges property which is
>>>>> contained within the RC. I think I could workaround this but there is
>>>>> no getting around the first problem.
>>>>>
>>>>
>>>> IIUC dma-ranges should be added to the parent bus of a device, which I
>>>> guess is slightly ambiguous for a root complex that incorporates a
>>>> host bridge.
>>
>> Humm, why is that ambiguous for a host bridge/root complex?
>
> The real problem is that FDT machines don't describe the PCI hierarchy
> in DT as proper OF does, so we have this awkward crossing between the DT
> model and the Linux device model where the devices have no DT
> representation and the "parent bus" is a DT leaf node, which cocks up
> the way the current code is expecting to work.
OK, I see what you mean, we still have to work with what we have here,
which is FDT...
--
Florian
On Wed, Sep 19, 2018 at 10:31:55AM -0400, Jim Quinlan wrote:
> 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.
Whatever happened with this series? I saw some discussion that suggests
it's not quite ready to be merged, but there's a lot of good work here,
so I hope it can get finished up.
Bjorn
On 3/20/19 4:15 PM, Bjorn Helgaas wrote:
> On Wed, Sep 19, 2018 at 10:31:55AM -0400, Jim Quinlan wrote:
>> 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.
>
> Whatever happened with this series? I saw some discussion that suggests
> it's not quite ready to be merged, but there's a lot of good work here,
> so I hope it can get finished up.
Thanks, these are encouraging words! We've been side tracked with a
number of things but it is still planned to get this included upstream
sooner rather than later. I am not sure how we will approach the
mangling of DMA addresses to fit the PCIe's quirky address map, but
hopefully with Christoph's latest chunk of work, there is even less to
be done by drivers.
--
Florian
Hi Jim,
Am 24.09.18 um 17:01 schrieb Jim Quinlan:
> On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel
> <[email protected]> wrote:
>> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan <[email protected]> wrote:
>>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli <[email protected]> wrote:
>>>> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote:
>>>>> On 20 September 2018 at 14:31, Florian Fainelli <[email protected]> wrote:
>>>>>> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
>>>>>>> On 20 September 2018 at 13:55, Florian Fainelli <[email protected]> wrote:
>>>>>>>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>>>>>>>> On 19 September 2018 at 07:31, Jim Quinlan <[email protected]> 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.
are there any plans to release a new version of this series?
The Raspberry Pi 4 uses a similiar PCIe controller, so it would be nice
to get this upstream. Unfortunately i have no clue about PCI, so i the
only thing i can do is testing.
Regards
Stefan