Discussion:
[PATCH v9 0/4] APM X-Gene PCIe host controller
Tanmay Inamdar
2014-09-16 22:33:40 UTC
Permalink
This patch adds support for AppliedMicro X-Gene PCIe host controller. The
driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
cards.

X-Gene PCIe controller driver has depedency on the pcie arm64 arch support.
Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and
support for creating generic pcie bridge from device tree. Liviu's patches
are available here
https://lkml.org/lkml/2014/9/8/333

If someone wishes to test PCIe on X-Gene with this patch set, above mentioned
patches from Liviu must be applied before the patches in this patch set. Also
please use latest xgene u-boot firmware.

changes since V8:
1. Add 'dma-coherent' attribute in device node.

changes since V7:
1. Fix outbound region mapping for IO region. Thanks Liviu for the catch.

changes since V6:
1. Port driver to changed interface as per Liviu's v10 series.

changes since V5:
1. Port driver to changed interface of 'of_create_pci_host_bridge'
2. Fix the prefetch bit setting
3. Removed bunch of register programming which is already done by firmware

changes since V4:
1. fix section mismatch warnings
2. fix the patch description
3. fix indentation
4. update read/write cfg functions by passing both addr and offset.
5. use 'time_before' for timeout.
6. remove unnecessary 'IS_ERR_OR_NULL'. Keep 'IS_ERR' for 'clk_get'
7. remove BUG_ON for pci_ioremap_io.

changes since V3:
1. remove 'struct hw_pci' and supporting ops in hw_pci
2. add code to create the host bridge from dts
3. add code to scan the the host bridge
4. modify outbound windows setup function to get resource information from
'bridge->windows'
5. add compatible string in pcie dts node with current X-Gene SOC name.

changes since V2:
1. redefined each PCI port in different PCI domain correctly.
2. removed setup_lane and setup_link functions from driver.
3. removed scan_bus wrapper and set_primary_bus hack.
4. added pci_ioremap_io for io resources.

changes since V1:
1. added PCI domain support
2. reading cpu and pci addresses from device tree to configure regions.
3. got rid of unnecessary wrappers for readl and writel.
4. got rid of endpoint configuration code.
5. added 'dma-ranges' property support to read inbound region configuration.
6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
7. dropped 'clock-names' property from bindings
8. added comments whereever requested.


Tanmay Inamdar (4):
pci:host: APM X-Gene PCIe host controller driver
arm64: dts: APM X-Gene PCIe device tree nodes
dt-bindings: pci: xgene pcie device tree bindings
MAINTAINERS: entry for APM X-Gene PCIe host driver

.../devicetree/bindings/pci/xgene-pci.txt | 57 ++
MAINTAINERS | 8 +
arch/arm64/boot/dts/apm-mustang.dts | 8 +
arch/arm64/boot/dts/apm-storm.dtsi | 165 ++++++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++
7 files changed, 895 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
create mode 100644 drivers/pci/host/pci-xgene.c
--
1.9.1
Tanmay Inamdar
2014-09-16 22:33:41 UTC
Permalink
This patch adds the AppliedMicro X-Gene SOC PCIe host controller driver.
X-Gene PCIe controller supports maximum up to 8 lanes and GEN3 speed.
X-Gene SOC supports maximum 5 PCIe ports.

Reviewed-by: Liviu Dudau <***@arm.com>
Signed-off-by: Tanmay Inamdar <***@apm.com>
---
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 657 insertions(+)
create mode 100644 drivers/pci/host/pci-xgene.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 90f5cca..382fd3d 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -63,4 +63,14 @@ config PCIE_SPEAR13XX
help
Say Y here if you want PCIe support on SPEAr13XX SoCs.

+config PCI_XGENE
+ bool "X-Gene PCIe controller"
+ depends on ARCH_XGENE
+ depends on OF
+ select PCIEPORTBUS
+ help
+ Say Y here if you want internal PCI support on APM X-Gene SoC.
+ There are 5 internal PCIe ports available. Each port is GEN3 capable
+ and have varied lanes from x1 to x8.
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index d0e88f1..845611f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
+obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
new file mode 100644
index 0000000..dae61a6
--- /dev/null
+++ b/drivers/pci/host/pci-xgene.c
@@ -0,0 +1,646 @@
+/**
+ * APM X-Gene PCIe Driver
+ *
+ * Copyright (c) 2014 Applied Micro Circuits Corporation.
+ *
+ * Author: Tanmay Inamdar <***@apm.com>.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/clk-private.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/memblock.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define PCIECORE_CTLANDSTATUS 0x50
+#define PIM1_1L 0x80
+#define IBAR2 0x98
+#define IR2MSK 0x9c
+#define PIM2_1L 0xa0
+#define IBAR3L 0xb4
+#define IR3MSKL 0xbc
+#define PIM3_1L 0xc4
+#define OMR1BARL 0x100
+#define OMR2BARL 0x118
+#define OMR3BARL 0x130
+#define CFGBARL 0x154
+#define CFGBARH 0x158
+#define CFGCTL 0x15c
+#define RTDID 0x160
+#define BRIDGE_CFG_4 0x2010
+#define BRIDGE_STATUS_0 0x2600
+
+#define LINK_UP_MASK 0x00000100
+#define AXI_EP_CFG_ACCESS 0x10000
+#define EN_COHERENCY 0xF0000000
+#define EN_REG 0x00000001
+#define OB_LO_IO 0x00000002
+#define XGENE_PCIE_VENDORID 0x10E8
+#define XGENE_PCIE_DEVICEID 0xE004
+#define SZ_1T (SZ_1G*1024ULL)
+#define PIPE_PHY_RATE_RD(src) ((0xc000 & (u32)(src)) >> 0xe)
+
+struct xgene_pcie_port {
+ struct device_node *node;
+ struct device *dev;
+ struct clk *clk;
+ void __iomem *csr_base;
+ void __iomem *cfg_base;
+ unsigned long cfg_addr;
+ bool link_up;
+};
+
+static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
+{
+ return (addr & PCI_BASE_ADDRESS_MEM_MASK) | flags;
+}
+
+/* PCIE Configuration Out/In */
+static inline void xgene_pcie_cfg_out32(void __iomem *addr, int offset, u32 val)
+{
+ writel(val, addr + offset);
+}
+
+static inline void xgene_pcie_cfg_out16(void __iomem *addr, int offset, u16 val)
+{
+ u32 val32 = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ case 2:
+ val32 &= ~0xFFFF0000;
+ val32 |= (u32)val << 16;
+ break;
+ case 0:
+ default:
+ val32 &= ~0xFFFF;
+ val32 |= val;
+ break;
+ }
+ writel(val32, addr + (offset & ~0x3));
+}
+
+static inline void xgene_pcie_cfg_out8(void __iomem *addr, int offset, u8 val)
+{
+ u32 val32 = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ case 0:
+ val32 &= ~0xFF;
+ val32 |= val;
+ break;
+ case 1:
+ val32 &= ~0xFF00;
+ val32 |= (u32)val << 8;
+ break;
+ case 2:
+ val32 &= ~0xFF0000;
+ val32 |= (u32)val << 16;
+ break;
+ case 3:
+ default:
+ val32 &= ~0xFF000000;
+ val32 |= (u32)val << 24;
+ break;
+ }
+ writel(val32, addr + (offset & ~0x3));
+}
+
+static inline void xgene_pcie_cfg_in32(void __iomem *addr, int offset, u32 *val)
+{
+ *val = readl(addr + offset);
+}
+
+static inline void
+xgene_pcie_cfg_in16(void __iomem *addr, int offset, u32 *val)
+{
+ *val = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ case 2:
+ *val >>= 16;
+ break;
+ }
+
+ *val &= 0xFFFF;
+}
+
+static inline void
+xgene_pcie_cfg_in8(void __iomem *addr, int offset, u32 *val)
+{
+ *val = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ case 3:
+ *val = *val >> 24;
+ break;
+ case 2:
+ *val = *val >> 16;
+ break;
+ case 1:
+ *val = *val >> 8;
+ break;
+ }
+ *val &= 0xFF;
+}
+
+/* When the address bit [17:16] is 2'b01, the Configuration access will be
+ * treated as Type 1 and it will be forwarded to external PCIe device.
+ */
+static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
+{
+ struct xgene_pcie_port *port = bus->sysdata;
+
+ if (bus->number >= (bus->primary + 1))
+ return port->cfg_base + AXI_EP_CFG_ACCESS;
+
+ return port->cfg_base;
+}
+
+/* For Configuration request, RTDID register is used as Bus Number,
+ * Device Number and Function number of the header fields.
+ */
+static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
+{
+ struct xgene_pcie_port *port = bus->sysdata;
+ unsigned int b, d, f;
+ u32 rtdid_val = 0;
+
+ b = bus->number;
+ d = PCI_SLOT(devfn);
+ f = PCI_FUNC(devfn);
+
+ if (!pci_is_root_bus(bus))
+ rtdid_val = (b << 8) | (d << 3) | f;
+
+ writel(rtdid_val, port->csr_base + RTDID);
+ /* read the register back to ensure flush */
+ readl(port->csr_base + RTDID);
+}
+
+static int xgene_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 *val)
+{
+ struct xgene_pcie_port *port = bus->sysdata;
+ void __iomem *addr;
+
+ if ((pci_is_root_bus(bus) && devfn != 0) || !port->link_up)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ xgene_pcie_set_rtdid_reg(bus, devfn);
+ addr = xgene_pcie_get_cfg_base(bus);
+ switch (len) {
+ case 1:
+ xgene_pcie_cfg_in8(addr, offset, val);
+ break;
+ case 2:
+ xgene_pcie_cfg_in16(addr, offset, val);
+ break;
+ default:
+ xgene_pcie_cfg_in32(addr, offset, val);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int xgene_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 val)
+{
+ struct xgene_pcie_port *port = bus->sysdata;
+ void __iomem *addr;
+
+ if ((pci_is_root_bus(bus) && devfn != 0) || !port->link_up)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ xgene_pcie_set_rtdid_reg(bus, devfn);
+ addr = xgene_pcie_get_cfg_base(bus);
+ switch (len) {
+ case 1:
+ xgene_pcie_cfg_out8(addr, offset, (u8)val);
+ break;
+ case 2:
+ xgene_pcie_cfg_out16(addr, offset, (u16)val);
+ break;
+ default:
+ xgene_pcie_cfg_out32(addr, offset, val);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops xgene_pcie_ops = {
+ .read = xgene_pcie_read_config,
+ .write = xgene_pcie_write_config
+};
+
+static u64 xgene_pcie_set_ib_mask(void __iomem *csr_base, u32 addr,
+ u32 flags, u64 size)
+{
+ u64 mask = (~(size - 1) & PCI_BASE_ADDRESS_MEM_MASK) | flags;
+ u32 val32 = 0;
+ u32 val;
+
+ val32 = readl(csr_base + addr);
+ val = (val32 & 0x0000ffff) | (lower_32_bits(mask) << 16);
+ writel(val, csr_base + addr);
+
+ val32 = readl(csr_base + addr + 0x04);
+ val = (val32 & 0xffff0000) | (lower_32_bits(mask) >> 16);
+ writel(val, csr_base + addr + 0x04);
+
+ val32 = readl(csr_base + addr + 0x04);
+ val = (val32 & 0x0000ffff) | (upper_32_bits(mask) << 16);
+ writel(val, csr_base + addr + 0x04);
+
+ val32 = readl(csr_base + addr + 0x08);
+ val = (val32 & 0xffff0000) | (upper_32_bits(mask) >> 16);
+ writel(val, csr_base + addr + 0x08);
+
+ return mask;
+}
+
+static void xgene_pcie_linkup(struct xgene_pcie_port *port,
+ u32 *lanes, u32 *speed)
+{
+ void __iomem *csr_base = port->csr_base;
+ u32 val32;
+
+ port->link_up = false;
+ val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
+ if (val32 & LINK_UP_MASK) {
+ port->link_up = true;
+ *speed = PIPE_PHY_RATE_RD(val32);
+ val32 = readl(csr_base + BRIDGE_STATUS_0);
+ *lanes = val32 >> 26;
+ }
+}
+
+static int xgene_pcie_init_port(struct xgene_pcie_port *port)
+{
+ int rc;
+
+ port->clk = clk_get(port->dev, NULL);
+ if (IS_ERR(port->clk)) {
+ dev_err(port->dev, "clock not available\n");
+ return -ENODEV;
+ }
+
+ rc = clk_prepare_enable(port->clk);
+ if (rc) {
+ dev_err(port->dev, "clock enable failed\n");
+ return rc;
+ }
+
+ return 0;
+}
+
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ dev->resource[i].start = dev->resource[i].end = 0;
+ dev->resource[i].flags = 0;
+ }
+ dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
+ xgene_pcie_fixup_bridge);
+
+static int xgene_pcie_map_reg(struct xgene_pcie_port *port,
+ struct platform_device *pdev)
+{
+ struct resource *res;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "csr");
+ port->csr_base = devm_ioremap_resource(port->dev, res);
+ if (IS_ERR(port->csr_base))
+ return PTR_ERR(port->csr_base);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
+ port->cfg_base = devm_ioremap_resource(port->dev, res);
+ if (IS_ERR(port->cfg_base))
+ return PTR_ERR(port->cfg_base);
+ port->cfg_addr = res->start;
+
+ return 0;
+}
+
+static void xgene_pcie_setup_ob_reg(struct xgene_pcie_port *port,
+ struct resource *res, u32 offset,
+ u64 cpu_addr, u64 pci_addr)
+{
+ void __iomem *base = port->csr_base + offset;
+ resource_size_t size = resource_size(res);
+ u64 restype = resource_type(res);
+ u64 mask = 0;
+ u32 min_size;
+ u32 flag = EN_REG;
+
+ if (restype == IORESOURCE_MEM) {
+ min_size = SZ_128M;
+ } else {
+ min_size = 128;
+ flag |= OB_LO_IO;
+ }
+
+ if (size >= min_size)
+ mask = ~(size - 1) | flag;
+ else
+ dev_warn(port->dev, "res size 0x%llx less than minimum 0x%x\n",
+ (u64)size, min_size);
+
+ writel(lower_32_bits(cpu_addr), base);
+ writel(upper_32_bits(cpu_addr), base + 0x04);
+ writel(lower_32_bits(mask), base + 0x08);
+ writel(upper_32_bits(mask), base + 0x0c);
+ writel(lower_32_bits(pci_addr), base + 0x10);
+ writel(upper_32_bits(pci_addr), base + 0x14);
+}
+
+static void xgene_pcie_setup_cfg_reg(void __iomem *csr_base, u64 addr)
+{
+ writel(lower_32_bits(addr), csr_base + CFGBARL);
+ writel(upper_32_bits(addr), csr_base + CFGBARH);
+ writel(EN_REG, csr_base + CFGCTL);
+}
+
+static int xgene_pcie_map_ranges(struct xgene_pcie_port *port,
+ struct list_head *res,
+ resource_size_t io_base)
+{
+ struct pci_host_bridge_window *window;
+ struct device *dev = port->dev;
+ int ret;
+
+ list_for_each_entry(window, res, list) {
+ struct resource *res = window->res;
+ u64 restype = resource_type(res);
+
+ dev_dbg(port->dev, "0x%08lx 0x%016llx...0x%016llx\n",
+ res->flags, res->start, res->end);
+
+ switch (restype) {
+ case IORESOURCE_IO:
+ xgene_pcie_setup_ob_reg(port, res, OMR3BARL, io_base,
+ res->start - window->offset);
+ ret = pci_remap_iospace(res, io_base);
+ if (ret < 0)
+ return ret;
+ break;
+ case IORESOURCE_MEM:
+ xgene_pcie_setup_ob_reg(port, res, OMR1BARL, res->start,
+ res->start - window->offset);
+ break;
+ case IORESOURCE_BUS:
+ break;
+ default:
+ dev_err(dev, "invalid io resource!");
+ return -EINVAL;
+ }
+ }
+ xgene_pcie_setup_cfg_reg(port->csr_base, port->cfg_addr);
+
+ return 0;
+}
+
+static void xgene_pcie_setup_pims(void *addr, u64 pim, u64 size)
+{
+ writel(lower_32_bits(pim), addr);
+ writel(upper_32_bits(pim) | EN_COHERENCY, addr + 0x04);
+ writel(lower_32_bits(size), addr + 0x10);
+ writel(upper_32_bits(size), addr + 0x14);
+}
+
+/*
+ * X-Gene PCIe support maximum 3 inbound memory regions
+ * This function helps to select a region based on size of region
+ */
+static int xgene_pcie_select_ib_reg(u8 *ib_reg_mask, u64 size)
+{
+ if ((size > 4) && (size < SZ_16M) && !(*ib_reg_mask & (1 << 1))) {
+ *ib_reg_mask |= (1 << 1);
+ return 1;
+ }
+
+ if ((size > SZ_1K) && (size < SZ_1T) && !(*ib_reg_mask & (1 << 0))) {
+ *ib_reg_mask |= (1 << 0);
+ return 0;
+ }
+
+ if ((size > SZ_1M) && (size < SZ_1T) && !(*ib_reg_mask & (1 << 2))) {
+ *ib_reg_mask |= (1 << 2);
+ return 2;
+ }
+
+ return -EINVAL;
+}
+
+static void xgene_pcie_setup_ib_reg(struct xgene_pcie_port *port,
+ struct of_pci_range *range, u8 *ib_reg_mask)
+{
+ void __iomem *csr_base = port->csr_base;
+ void __iomem *cfg_base = port->cfg_base;
+ void *bar_addr;
+ void *pim_addr;
+ u64 cpu_addr = range->cpu_addr;
+ u64 pci_addr = range->pci_addr;
+ u64 size = range->size;
+ u64 mask = ~(size - 1) | EN_REG;
+ u32 flags = PCI_BASE_ADDRESS_MEM_TYPE_64;
+ u32 bar_low;
+ int region;
+
+ region = xgene_pcie_select_ib_reg(ib_reg_mask, range->size);
+ if (region < 0) {
+ dev_warn(port->dev, "invalid pcie dma-range config\n");
+ return;
+ }
+
+ if (range->flags & IORESOURCE_PREFETCH)
+ flags |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+
+ bar_low = pcie_bar_low_val((u32)cpu_addr, flags);
+ switch (region) {
+ case 0:
+ xgene_pcie_set_ib_mask(csr_base, BRIDGE_CFG_4, flags, size);
+ bar_addr = cfg_base + PCI_BASE_ADDRESS_0;
+ writel(bar_low, bar_addr);
+ writel(upper_32_bits(cpu_addr), bar_addr + 0x4);
+ pim_addr = csr_base + PIM1_1L;
+ break;
+ case 1:
+ bar_addr = csr_base + IBAR2;
+ writel(bar_low, bar_addr);
+ writel(lower_32_bits(mask), csr_base + IR2MSK);
+ pim_addr = csr_base + PIM2_1L;
+ break;
+ case 2:
+ bar_addr = csr_base + IBAR3L;
+ writel(bar_low, bar_addr);
+ writel(upper_32_bits(cpu_addr), bar_addr + 0x4);
+ writel(lower_32_bits(mask), csr_base + IR3MSKL);
+ writel(upper_32_bits(mask), csr_base + IR3MSKL + 0x4);
+ pim_addr = csr_base + PIM3_1L;
+ break;
+ }
+
+ xgene_pcie_setup_pims(pim_addr, pci_addr, ~(size - 1));
+}
+
+static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser->node = node;
+ parser->pna = of_n_addr_cells(node);
+ parser->np = parser->pna + na + ns;
+
+ parser->range = of_get_property(node, "dma-ranges", &rlen);
+ if (!parser->range)
+ return -ENOENT;
+ parser->end = parser->range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+static int xgene_pcie_parse_map_dma_ranges(struct xgene_pcie_port *port)
+{
+ struct device_node *np = port->node;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ struct device *dev = port->dev;
+ u8 ib_reg_mask = 0;
+
+ if (pci_dma_range_parser_init(&parser, np)) {
+ dev_err(dev, "missing dma-ranges property\n");
+ return -EINVAL;
+ }
+
+ /* Get the dma-ranges from DT */
+ for_each_of_pci_range(&parser, &range) {
+ u64 end = range.cpu_addr + range.size - 1;
+
+ dev_dbg(port->dev, "0x%08x 0x%016llx..0x%016llx -> 0x%016llx\n",
+ range.flags, range.cpu_addr, end, range.pci_addr);
+ xgene_pcie_setup_ib_reg(port, &range, &ib_reg_mask);
+ }
+ return 0;
+}
+
+/* clear bar configuration which was done by firmware */
+static void xgene_pcie_clear_config(struct xgene_pcie_port *port)
+{
+ int i;
+
+ for (i = PIM1_1L; i <= CFGCTL; i += 4)
+ writel(0x0, port->csr_base + i);
+}
+
+static int xgene_pcie_setup(struct xgene_pcie_port *port,
+ struct list_head *res,
+ resource_size_t io_base)
+{
+ u32 lanes = 0, speed = 0;
+ int ret;
+
+ xgene_pcie_clear_config(port);
+
+ ret = xgene_pcie_map_ranges(port, res, io_base);
+ if (ret)
+ return ret;
+
+ ret = xgene_pcie_parse_map_dma_ranges(port);
+ if (ret)
+ return ret;
+
+ xgene_pcie_linkup(port, &lanes, &speed);
+ if (!port->link_up)
+ dev_info(port->dev, "(rc) link down\n");
+ else
+ dev_info(port->dev, "(rc) x%d gen-%d link up\n",
+ lanes, speed + 1);
+ return 0;
+}
+
+static int xgene_pcie_probe_bridge(struct platform_device *pdev)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ struct xgene_pcie_port *port;
+ resource_size_t iobase = 0;
+ struct pci_bus *bus;
+ int ret;
+ LIST_HEAD(res);
+
+ port = devm_kzalloc(&pdev->dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+ port->node = of_node_get(pdev->dev.of_node);
+ port->dev = &pdev->dev;
+
+ ret = xgene_pcie_map_reg(port, pdev);
+ if (ret)
+ return ret;
+
+ ret = xgene_pcie_init_port(port);
+ if (ret)
+ return ret;
+
+ ret = of_pci_get_host_bridge_resources(dn, 0, 0xff, &res, &iobase);
+ if (ret)
+ return ret;
+
+ ret = xgene_pcie_setup(port, &res, iobase);
+ if (ret)
+ return ret;
+
+ bus = pci_scan_root_bus(&pdev->dev, 0, &xgene_pcie_ops, port, &res);
+ if (!bus)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, port);
+ return 0;
+}
+
+static const struct of_device_id xgene_pcie_match_table[] = {
+ {.compatible = "apm,xgene-pcie",},
+ {},
+};
+
+static struct platform_driver xgene_pcie_driver = {
+ .driver = {
+ .name = "xgene-pcie",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(xgene_pcie_match_table),
+ },
+ .probe = xgene_pcie_probe_bridge,
+};
+module_platform_driver(xgene_pcie_driver);
+
+MODULE_AUTHOR("Tanmay Inamdar <***@apm.com>");
+MODULE_DESCRIPTION("APM X-Gene PCIe driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas
2014-09-19 22:32:58 UTC
Permalink
Post by Tanmay Inamdar
This patch adds the AppliedMicro X-Gene SOC PCIe host controller driver.
X-Gene PCIe controller supports maximum up to 8 lanes and GEN3 speed.
X-Gene SOC supports maximum 5 PCIe ports.
---
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 657 insertions(+)
create mode 100644 drivers/pci/host/pci-xgene.c
...
+static inline void
+xgene_pcie_cfg_in16(void __iomem *addr, int offset, u32 *val)
Whitespace - can fit on one line. Also others below.
Post by Tanmay Inamdar
+{
+ *val = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ *val >>= 16;
+ break;
+ }
+
+ *val &= 0xFFFF;
+}
+
+static inline void
+xgene_pcie_cfg_in8(void __iomem *addr, int offset, u32 *val)
+{
+ *val = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ *val = *val >> 24;
+ break;
+ *val = *val >> 16;
+ break;
+ *val = *val >> 8;
+ break;
+ }
+ *val &= 0xFF;
+}
+
+/* When the address bit [17:16] is 2'b01, the Configuration access will be
+ * treated as Type 1 and it will be forwarded to external PCIe device.
+ */
Follow usual block comment style:

/*
* text
*/
Post by Tanmay Inamdar
...
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
This needs a better explanation than "doesn't fit well."

I *think* you're probably talking about something similar to the MVEBU
devices mentioned here:
http://lkml.kernel.org/r/***@mail.gmail.com

where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.

In any event, I'd like a description of exactly what these BARs are and wha
the problem is. Presumably the BARs exist and were sized by the PCI core
in __pci_read_base(). That will generate some log messages and possibly
some warnings, depending on how the host bridge windows are set up.

We might eventually need a way to skip BARs like that altogether so we
don't even try to size them.
Post by Tanmay Inamdar
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ dev->resource[i].start = dev->resource[i].end = 0;
+ dev->resource[i].flags = 0;
+ }
+ dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
+ xgene_pcie_fixup_bridge);
+
...
+static void xgene_pcie_setup_ob_reg(struct xgene_pcie_port *port,
+ struct resource *res, u32 offset,
+ u64 cpu_addr, u64 pci_addr)
+{
+ void __iomem *base = port->csr_base + offset;
+ resource_size_t size = resource_size(res);
+ u64 restype = resource_type(res);
+ u64 mask = 0;
+ u32 min_size;
+ u32 flag = EN_REG;
+
+ if (restype == IORESOURCE_MEM) {
+ min_size = SZ_128M;
+ } else {
+ min_size = 128;
+ flag |= OB_LO_IO;
+ }
+
+ if (size >= min_size)
+ mask = ~(size - 1) | flag;
+ else
+ dev_warn(port->dev, "res size 0x%llx less than minimum 0x%x\n",
+ (u64)size, min_size);
I'd include a %pR here to help identify the offending resource.
Post by Tanmay Inamdar
+static int xgene_pcie_map_ranges(struct xgene_pcie_port *port,
+ struct list_head *res,
+ resource_size_t io_base)
+{
+ struct pci_host_bridge_window *window;
+ struct device *dev = port->dev;
+ int ret;
+
+ list_for_each_entry(window, res, list) {
+ struct resource *res = window->res;
+ u64 restype = resource_type(res);
+
+ dev_dbg(port->dev, "0x%08lx 0x%016llx...0x%016llx\n",
+ res->flags, res->start, res->end);
Use %pR here.
Post by Tanmay Inamdar
+
+ switch (restype) {
+ xgene_pcie_setup_ob_reg(port, res, OMR3BARL, io_base,
+ res->start - window->offset);
+ ret = pci_remap_iospace(res, io_base);
+ if (ret < 0)
+ return ret;
+ break;
+ xgene_pcie_setup_ob_reg(port, res, OMR1BARL, res->start,
+ res->start - window->offset);
+ break;
+ break;
+ dev_err(dev, "invalid io resource!");
If you're going to print something here, you might as well include the type
that seems invalid. If you use %pR, I think it will do that automatically.
Post by Tanmay Inamdar
+ return -EINVAL;
+ }
+ }
+ xgene_pcie_setup_cfg_reg(port->csr_base, port->cfg_addr);
+
+ return 0;
+}
Bjorn
Tanmay Inamdar
2014-09-22 21:33:37 UTC
Permalink
Hello Bjorn,

Thanks for the review and comments. Please see my inline replies.

Thanks,
Tanmay
Post by Bjorn Helgaas
Post by Tanmay Inamdar
This patch adds the AppliedMicro X-Gene SOC PCIe host controller driver.
X-Gene PCIe controller supports maximum up to 8 lanes and GEN3 speed.
X-Gene SOC supports maximum 5 PCIe ports.
---
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 657 insertions(+)
create mode 100644 drivers/pci/host/pci-xgene.c
...
+static inline void
+xgene_pcie_cfg_in16(void __iomem *addr, int offset, u32 *val)
Whitespace - can fit on one line. Also others below.
Thanks. Will fix it.
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+{
+ *val = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ *val >>= 16;
+ break;
+ }
+
+ *val &= 0xFFFF;
+}
+
+static inline void
+xgene_pcie_cfg_in8(void __iomem *addr, int offset, u32 *val)
+{
+ *val = readl(addr + (offset & ~0x3));
+
+ switch (offset & 0x3) {
+ *val = *val >> 24;
+ break;
+ *val = *val >> 16;
+ break;
+ *val = *val >> 8;
+ break;
+ }
+ *val &= 0xFF;
+}
+
+/* When the address bit [17:16] is 2'b01, the Configuration access will be
+ * treated as Type 1 and it will be forwarded to external PCIe device.
+ */
/*
* text
*/
Thanks. Will fix it.
Post by Bjorn Helgaas
Post by Tanmay Inamdar
...
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
This needs a better explanation than "doesn't fit well."
I *think* you're probably talking about something similar to the MVEBU
where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.
It is true that X-Gene PCIe port can be configured as EP, however the
the FIXUP is required not because of the BARs are still visible when
configured as EP in past. X-Gene PCIe port, when configured as RC,
uses BAR0-BAR1 of RC's configuration space as inbound BARs. Entire DDR
region is mapped in these BARs so that it is accessible for EP devices
for DMA. So if the fixup is not done during enumeration, whole
outbound memory resource space gets assigned to RC and nothing is left
EP devices.
Post by Bjorn Helgaas
In any event, I'd like a description of exactly what these BARs are and wha
the problem is.
Is it ok to put above description in comment to explain the fixup?
Post by Bjorn Helgaas
Presumably the BARs exist and were sized by the PCI core
in __pci_read_base(). That will generate some log messages and possibly
some warnings, depending on how the host bridge windows are set up.
xgene-pcie 1f2b0000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0xe180000000-0xe1ffffffff]
(bus address [0x80000000-0xffffffff])
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: [10e8:e004] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x8000000000-0x807fffffff 64bit pref]
pci 0000:00:00.0: supports D1 D2
pci_bus 0000:00: fixups for bus
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: [15b3:1003] type 00 class 0x020000
pci 0000:01:00.0: reg 0x10: [mem 0x00100000-0x001fffff 64bit]
pci 0000:01:00.0: reg 0x18: [mem 0x00800000-0x00ffffff 64bit pref]
pci 0000:01:00.0: reg 0x30: [mem 0x01000000-0x010fffff pref]
pci_bus 0000:01: fixups for bus
pci_bus 0000:01: bus scan returning with max=01
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
pci_bus 0000:00: bus scan returning with max=01
pci 0000:00:00.0: BAR 0: assigned [mem 0xe180000000-0xe1ffffffff 64bit pref]
pci 0000:00:00.0: BAR 9: no space for [mem size 0x00800000 64bit pref]
pci 0000:00:00.0: BAR 9: failed to assign [mem size 0x00800000 64bit pref]
pci 0000:00:00.0: BAR 8: no space for [mem size 0x00200000]
pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00200000]
pci 0000:01:00.0: BAR 2: no space for [mem size 0x00800000 64bit pref]
pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00800000 64bit pref]
pci 0000:01:00.0: BAR 0: no space for [mem size 0x00100000 64bit]
pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00100000 64bit]
pci 0000:01:00.0: BAR 6: no space for [mem size 0x00100000 pref]
pci 0000:01:00.0: BAR 6: failed to assign [mem size 0x00100000 pref]
Post by Bjorn Helgaas
We might eventually need a way to skip BARs like that altogether so we
don't even try to size them.
Post by Tanmay Inamdar
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ dev->resource[i].start = dev->resource[i].end = 0;
+ dev->resource[i].flags = 0;
+ }
+ dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
+ xgene_pcie_fixup_bridge);
+
...
+static void xgene_pcie_setup_ob_reg(struct xgene_pcie_port *port,
+ struct resource *res, u32 offset,
+ u64 cpu_addr, u64 pci_addr)
+{
+ void __iomem *base = port->csr_base + offset;
+ resource_size_t size = resource_size(res);
+ u64 restype = resource_type(res);
+ u64 mask = 0;
+ u32 min_size;
+ u32 flag = EN_REG;
+
+ if (restype == IORESOURCE_MEM) {
+ min_size = SZ_128M;
+ } else {
+ min_size = 128;
+ flag |= OB_LO_IO;
+ }
+
+ if (size >= min_size)
+ mask = ~(size - 1) | flag;
+ else
+ dev_warn(port->dev, "res size 0x%llx less than minimum 0x%x\n",
+ (u64)size, min_size);
I'd include a %pR here to help identify the offending resource.
Will change it in next revision.
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+static int xgene_pcie_map_ranges(struct xgene_pcie_port *port,
+ struct list_head *res,
+ resource_size_t io_base)
+{
+ struct pci_host_bridge_window *window;
+ struct device *dev = port->dev;
+ int ret;
+
+ list_for_each_entry(window, res, list) {
+ struct resource *res = window->res;
+ u64 restype = resource_type(res);
+
+ dev_dbg(port->dev, "0x%08lx 0x%016llx...0x%016llx\n",
+ res->flags, res->start, res->end);
Use %pR here.
Will change it in next revision.
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+
+ switch (restype) {
+ xgene_pcie_setup_ob_reg(port, res, OMR3BARL, io_base,
+ res->start - window->offset);
+ ret = pci_remap_iospace(res, io_base);
+ if (ret < 0)
+ return ret;
+ break;
+ xgene_pcie_setup_ob_reg(port, res, OMR1BARL, res->start,
+ res->start - window->offset);
+ break;
+ break;
+ dev_err(dev, "invalid io resource!");
If you're going to print something here, you might as well include the type
that seems invalid. If you use %pR, I think it will do that automatically.
Will change it in next revision.
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+ return -EINVAL;
+ }
+ }
+ xgene_pcie_setup_cfg_reg(port->csr_base, port->cfg_addr);
+
+ return 0;
+}
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas
2014-09-22 22:09:03 UTC
Permalink
Post by Tanmay Inamdar
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
This needs a better explanation than "doesn't fit well."
I *think* you're probably talking about something similar to the MVEBU
where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.
It is true that X-Gene PCIe port can be configured as EP, however the
the FIXUP is required not because of the BARs are still visible when
configured as EP in past. X-Gene PCIe port, when configured as RC,
uses BAR0-BAR1 of RC's configuration space as inbound BARs. Entire DDR
region is mapped in these BARs so that it is accessible for EP devices
for DMA. So if the fixup is not done during enumeration, whole
outbound memory resource space gets assigned to RC and nothing is left
EP devices.
I'm not familiar with the concept of an "inbound BAR"; at least I'm
not aware of anything like this in the PCI specs. I think it might
reduce confusion if we avoided calling them "BARs". They happen to be
at the same addresses where real BARs would be, but they certainly
don't behave like real BARs.

It sounds like this is basically a trivial IOMMU that determines which
DMA accesses can reach main memory.
Post by Tanmay Inamdar
Post by Bjorn Helgaas
In any event, I'd like a description of exactly what these BARs are and wha
the problem is.
Is it ok to put above description in comment to explain the fixup?
Post by Bjorn Helgaas
Presumably the BARs exist and were sized by the PCI core
in __pci_read_base(). That will generate some log messages and possibly
some warnings, depending on how the host bridge windows are set up.
Instead of doing this in a fixup, can you change the PCI config
accessors so that when accessing these inbound DMA mapping registers,
they drop writes and return zeros for reads? Then the PCI core won't
think there are BARs there, and it won't mistakenly corrupt them when
it tries to size them.

Bjorn
Jason Gunthorpe
2014-09-22 22:27:27 UTC
Permalink
Post by Bjorn Helgaas
Post by Tanmay Inamdar
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
This needs a better explanation than "doesn't fit well."
I *think* you're probably talking about something similar to the MVEBU
where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.
It is true that X-Gene PCIe port can be configured as EP, however the
the FIXUP is required not because of the BARs are still visible when
configured as EP in past. X-Gene PCIe port, when configured as RC,
uses BAR0-BAR1 of RC's configuration space as inbound BARs. Entire DDR
region is mapped in these BARs so that it is accessible for EP devices
for DMA. So if the fixup is not done during enumeration, whole
outbound memory resource space gets assigned to RC and nothing is left
EP devices.
I'm not familiar with the concept of an "inbound BAR"; at least I'm
not aware of anything like this in the PCI specs. I think it might
reduce confusion if we avoided calling them "BARs". They happen to be
at the same addresses where real BARs would be, but they certainly
don't behave like real BARs.
So what does the lspci look like?

If x-gene has an otherwise correct bridge config space and only the
0/1 BARs have a non-standard meaning, that I'd agree with Bjorn, hide
all access to these registers from the kernel (and tell your HW crew
to read the specs, because it is very clear what those registers are
supposed to do) .

If x-gene doesn't even have a bridge config space, then there are much
bigger problems, and these corrupt BARs are just the start.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tanmay Inamdar
2014-09-22 22:59:35 UTC
Permalink
On Mon, Sep 22, 2014 at 3:27 PM, Jason Gunthorpe
Post by Jason Gunthorpe
Post by Bjorn Helgaas
Post by Tanmay Inamdar
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
This needs a better explanation than "doesn't fit well."
I *think* you're probably talking about something similar to the MVEBU
where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.
It is true that X-Gene PCIe port can be configured as EP, however the
the FIXUP is required not because of the BARs are still visible when
configured as EP in past. X-Gene PCIe port, when configured as RC,
uses BAR0-BAR1 of RC's configuration space as inbound BARs. Entire DDR
region is mapped in these BARs so that it is accessible for EP devices
for DMA. So if the fixup is not done during enumeration, whole
outbound memory resource space gets assigned to RC and nothing is left
EP devices.
I'm not familiar with the concept of an "inbound BAR"; at least I'm
not aware of anything like this in the PCI specs. I think it might
reduce confusion if we avoided calling them "BARs". They happen to be
at the same addresses where real BARs would be, but they certainly
don't behave like real BARs.
So what does the lspci look like?
[***@mustang ~]# lspci -s 0000:00:00.0 -v
0000:00:00.0 PCI bridge: Applied Micro Circuits Corp. Device e004 (rev
04) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at <ignored> (64-bit, prefetchable)
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: 80800000-809fffff
Prefetchable memory behind bridge: 0000000080000000-00000000807fffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [180] #19
Capabilities: [150] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Kernel driver in use: pcieport
Post by Jason Gunthorpe
If x-gene has an otherwise correct bridge config space and only the
0/1 BARs have a non-standard meaning, that I'd agree with Bjorn, hide
all access to these registers from the kernel (and tell your HW crew
to read the specs, because it is very clear what those registers are
supposed to do) .
Ok.
Post by Jason Gunthorpe
If x-gene doesn't even have a bridge config space, then there are much
bigger problems, and these corrupt BARs are just the start.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tanmay Inamdar
2014-09-22 22:40:03 UTC
Permalink
Post by Bjorn Helgaas
Post by Tanmay Inamdar
Post by Bjorn Helgaas
Post by Tanmay Inamdar
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
This needs a better explanation than "doesn't fit well."
I *think* you're probably talking about something similar to the MVEBU
where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.
It is true that X-Gene PCIe port can be configured as EP, however the
the FIXUP is required not because of the BARs are still visible when
configured as EP in past. X-Gene PCIe port, when configured as RC,
uses BAR0-BAR1 of RC's configuration space as inbound BARs. Entire DDR
region is mapped in these BARs so that it is accessible for EP devices
for DMA. So if the fixup is not done during enumeration, whole
outbound memory resource space gets assigned to RC and nothing is left
EP devices.
I'm not familiar with the concept of an "inbound BAR"; at least I'm
not aware of anything like this in the PCI specs. I think it might
reduce confusion if we avoided calling them "BARs". They happen to be
at the same addresses where real BARs would be, but they certainly
don't behave like real BARs.
It sounds like this is basically a trivial IOMMU that determines which
DMA accesses can reach main memory.
Yes. That is correct.
Post by Bjorn Helgaas
Post by Tanmay Inamdar
Post by Bjorn Helgaas
In any event, I'd like a description of exactly what these BARs are and wha
the problem is.
Is it ok to put above description in comment to explain the fixup?
Post by Bjorn Helgaas
Presumably the BARs exist and were sized by the PCI core
in __pci_read_base(). That will generate some log messages and possibly
some warnings, depending on how the host bridge windows are set up.
Instead of doing this in a fixup, can you change the PCI config
accessors so that when accessing these inbound DMA mapping registers,
they drop writes and return zeros for reads? Then the PCI core won't
think there are BARs there, and it won't mistakenly corrupt them when
it tries to size them.
I suppose this can be done. I will fix this in next revision.
Post by Bjorn Helgaas
Bjorn
Tanmay Inamdar
2014-09-16 22:33:43 UTC
Permalink
This patch adds the bindings for X-Gene PCIe driver. The driver resides
under 'drivers/pci/host/pci-xgene.c' file.

Signed-off-by: Tanmay Inamdar <***@apm.com>
---
.../devicetree/bindings/pci/xgene-pci.txt | 57 ++++++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt

diff --git a/Documentation/devicetree/bindings/pci/xgene-pci.txt b/Documentation/devicetree/bindings/pci/xgene-pci.txt
new file mode 100644
index 0000000..1070b06
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xgene-pci.txt
@@ -0,0 +1,57 @@
+* AppliedMicro X-Gene PCIe interface
+
+Required properties:
+- device_type: set to "pci"
+- compatible: should contain "apm,xgene-pcie" to identify the core.
+- reg: A list of physical base address and length for each set of controller
+ registers. Must contain an entry for each entry in the reg-names
+ property.
+- reg-names: Must include the following entries:
+ "csr": controller configuration registers.
+ "cfg": pcie configuration space registers.
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- ranges: ranges for the outbound memory, I/O regions.
+- dma-ranges: ranges for the inbound memory regions.
+- #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.
+- clocks: from common clock binding: handle to pci clock.
+
+Optional properties:
+- status: Either "ok" or "disabled".
+- dma-coherent: Present if dma operations are coherent
+
+Example:
+
+SoC specific DT Entry:
+
+ pcie0: ***@1f2b0000 {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */
+ 0xe0 0xd0000000 0x0 0x00040000>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x01000000 0x00 0x00000000 0xe0 0x10000000 0x00 0x00010000 /* io */
+ 0x02000000 0x00 0x80000000 0xe1 0x80000000 0x00 0x80000000>; /* mem */
+ dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
+ 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
+ 0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
+ 0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
+ 0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
+ dma-coherent;
+ clocks = <&pcie0clk 0>;
+ };
+
+
+Board specific DT Entry:
+ &pcie0 {
+ status = "ok";
+ };
--
1.9.1
Tanmay Inamdar
2014-09-16 22:33:44 UTC
Permalink
Add entry for AppliedMicro X-Gene PCIe host driver.

Signed-off-by: Tanmay Inamdar <***@apm.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e7866a..cd9bb3da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6941,6 +6941,14 @@ L: linux-***@vger.kernel.org
S: Maintained
F: drivers/pci/host/*spear*

+PCI DRIVER FOR APPLIEDMICRO XGENE
+M: Tanmay Inamdar <***@apm.com>
+L: linux-***@vger.kernel.org
+L: linux-arm-***@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/xgene-pci.txt
+F: drivers/pci/host/pci-xgene.c
+
PCMCIA SUBSYSTEM
P: Linux PCMCIA Team
L: linux-***@lists.infradead.org
--
1.9.1
Tanmay Inamdar
2014-09-16 22:33:42 UTC
Permalink
This patch adds the device tree nodes for APM X-Gene PCIe host controller and
PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts
nodes are added.

Signed-off-by: Tanmay Inamdar <***@apm.com>
---
arch/arm64/boot/dts/apm-mustang.dts | 8 ++
arch/arm64/boot/dts/apm-storm.dtsi | 165 ++++++++++++++++++++++++++++++++++++
2 files changed, 173 insertions(+)

diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
index b2f5622..f649000 100644
--- a/arch/arm64/boot/dts/apm-mustang.dts
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -25,6 +25,14 @@
};
};

+&pcie0clk {
+ status = "ok";
+};
+
+&pcie0 {
+ status = "ok";
+};
+
&serial0 {
status = "ok";
};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
index c0aceef..403197a 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -269,6 +269,171 @@
enable-mask = <0x2>;
clock-output-names = "rtcclk";
};
+
+ pcie0clk: ***@1f2bc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f2bc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie0clk";
+ };
+
+ pcie1clk: ***@1f2cc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f2cc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie1clk";
+ };
+
+ pcie2clk: ***@1f2dc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f2dc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie2clk";
+ };
+
+ pcie3clk: ***@1f50c000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f50c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie3clk";
+ };
+
+ pcie4clk: ***@1f51c000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f51c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie4clk";
+ };
+ };
+
+ pcie0: ***@1f2b0000 {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */
+ 0xe0 0xd0000000 0x0 0x00040000>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x01000000 0x00 0x00000000 0xe0 0x10000000 0x00 0x00010000 /* io */
+ 0x02000000 0x00 0x80000000 0xe1 0x80000000 0x00 0x80000000>; /* mem */
+ dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
+ 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
+ 0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
+ 0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
+ 0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
+ dma-coherent;
+ clocks = <&pcie0clk 0>;
+ };
+
+ pcie1: ***@1f2c0000 {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2c0000 0x0 0x00010000 /* Controller registers */
+ 0xd0 0xd0000000 0x0 0x00040000>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x01000000 0x0 0x00000000 0xd0 0x10000000 0x00 0x00010000 /* io */
+ 0x02000000 0x0 0x80000000 0xd1 0x80000000 0x00 0x80000000>; /* mem */
+ dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
+ 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc8 0x1
+ 0x0 0x0 0x0 0x2 &gic 0x0 0xc9 0x1
+ 0x0 0x0 0x0 0x3 &gic 0x0 0xca 0x1
+ 0x0 0x0 0x0 0x4 &gic 0x0 0xcb 0x1>;
+ dma-coherent;
+ clocks = <&pcie1clk 0>;
+ };
+
+ pcie2: ***@1f2d0000 {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2d0000 0x0 0x00010000 /* Controller registers */
+ 0x90 0xd0000000 0x0 0x00040000>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x01000000 0x0 0x00000000 0x90 0x10000000 0x0 0x00010000 /* io */
+ 0x02000000 0x0 0x80000000 0x91 0x80000000 0x0 0x80000000>; /* mem */
+ dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
+ 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xce 0x1
+ 0x0 0x0 0x0 0x2 &gic 0x0 0xcf 0x1
+ 0x0 0x0 0x0 0x3 &gic 0x0 0xd0 0x1
+ 0x0 0x0 0x0 0x4 &gic 0x0 0xd1 0x1>;
+ dma-coherent;
+ clocks = <&pcie2clk 0>;
+ };
+
+ pcie3: ***@1f500000 {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f500000 0x0 0x00010000 /* Controller registers */
+ 0xa0 0xd0000000 0x0 0x00040000>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x01000000 0x0 0x00000000 0xa0 0x10000000 0x0 0x00010000 /* io */
+ 0x02000000 0x0 0x80000000 0xa1 0x80000000 0x0 0x80000000>; /* mem */
+ dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
+ 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xd4 0x1
+ 0x0 0x0 0x0 0x2 &gic 0x0 0xd5 0x1
+ 0x0 0x0 0x0 0x3 &gic 0x0 0xd6 0x1
+ 0x0 0x0 0x0 0x4 &gic 0x0 0xd7 0x1>;
+ dma-coherent;
+ clocks = <&pcie3clk 0>;
+ };
+
+ pcie4: ***@1f510000 {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f510000 0x0 0x00010000 /* Controller registers */
+ 0xc0 0xd0000000 0x0 0x00200000>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x01000000 0x0 0x00000000 0xc0 0x10000000 0x0 0x00010000 /* io */
+ 0x02000000 0x0 0x80000000 0xc1 0x80000000 0x0 0x80000000>; /* mem */
+ dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
+ 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xda 0x1
+ 0x0 0x0 0x0 0x2 &gic 0x0 0xdb 0x1
+ 0x0 0x0 0x0 0x3 &gic 0x0 0xdc 0x1
+ 0x0 0x0 0x0 0x4 &gic 0x0 0xdd 0x1>;
+ dma-coherent;
+ clocks = <&pcie4clk 0>;
};

serial0: ***@1c020000 {
--
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ming Lei
2014-09-19 03:08:29 UTC
Permalink
Hi Tanmay,
Post by Tanmay Inamdar
This patch adds support for AppliedMicro X-Gene PCIe host controller. The
driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
cards.
X-Gene PCIe controller driver has depedency on the pcie arm64 arch support.
Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and
support for creating generic pcie bridge from device tree. Liviu's patches
are available here
https://lkml.org/lkml/2014/9/8/333
If someone wishes to test PCIe on X-Gene with this patch set, above mentioned
patches from Liviu must be applied before the patches in this patch set. Also
please use latest xgene u-boot firmware.
1. Add 'dma-coherent' attribute in device node.
I just tested your V9 patches plus Liviu's V10 PCI/ARM64 patches
against 3.17-rc5 on Mustang, and the following failure is triggered:

[ 1.190131] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit
Ethernet Driver bnx2x 1.78.19-0 (2014/02/10)
[ 1.200249] tg3.c:v3.137 (May 11, 2014)
[ 1.204087] ------------[ cut here ]------------
[ 1.208682] WARNING: CPU: 1 PID: 1 at drivers/pci/pci.c:131
pci_ioremap_bar+0x70/0x78()
[ 1.216646] Modules linked in:
[ 1.219696] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5+ #1
[ 1.226018] Call trace:
[ 1.228453] [<ffffffc0000884f0>] dump_backtrace+0x0/0x16c
[ 1.233826] [<ffffffc00008866c>] show_stack+0x10/0x1c
[ 1.238851] [<ffffffc0006e3210>] dump_stack+0x74/0x94
[ 1.243878] [<ffffffc0000a934c>] warn_slowpath_common+0x88/0xb0
[ 1.249767] [<ffffffc0000a9438>] warn_slowpath_null+0x14/0x20
[ 1.255485] [<ffffffc0003994c4>] pci_ioremap_bar+0x6c/0x78
[ 1.260942] [<ffffffc0005598cc>] tg3_init_one+0x148/0x16f4
[ 1.266401] [<ffffffc00039ccf0>] pci_device_probe+0x78/0xd4
[ 1.271946] [<ffffffc00042785c>] driver_probe_device+0x94/0x390
[ 1.277834] [<ffffffc000427c44>] __driver_attach+0x98/0xa0
[ 1.283293] [<ffffffc000425a54>] bus_for_each_dev+0x54/0x98
[ 1.288835] [<ffffffc00042730c>] driver_attach+0x1c/0x28
[ 1.294121] [<ffffffc000426f04>] bus_add_driver+0x164/0x240
[ 1.299663] [<ffffffc000428430>] driver_register+0x64/0x130
[ 1.305207] [<ffffffc00039c97c>] __pci_register_driver+0x3c/0x48
[ 1.311181] [<ffffffc000aa8a5c>] tg3_driver_init+0x1c/0x28
[ 1.316640] [<ffffffc0000814e0>] do_one_initcall+0xc4/0x1b4
[ 1.322186] [<ffffffc000a74b64>] kernel_init_freeable+0x1b8/0x25c
[ 1.328246] [<ffffffc0006de318>] kernel_init+0xc/0xd4
[ 1.333278] ---[ end trace f4dca5ab5b436080 ]---
[ 1.337871] tg3 0000:01:00.0: Cannot map device registers, aborting
[ 1.344122] tg3: probe of 0000:01:00.0 failed with error -12



Thanks,
Post by Tanmay Inamdar
1. Fix outbound region mapping for IO region. Thanks Liviu for the catch.
1. Port driver to changed interface as per Liviu's v10 series.
1. Port driver to changed interface of 'of_create_pci_host_bridge'
2. Fix the prefetch bit setting
3. Removed bunch of register programming which is already done by firmware
1. fix section mismatch warnings
2. fix the patch description
3. fix indentation
4. update read/write cfg functions by passing both addr and offset.
5. use 'time_before' for timeout.
6. remove unnecessary 'IS_ERR_OR_NULL'. Keep 'IS_ERR' for 'clk_get'
7. remove BUG_ON for pci_ioremap_io.
1. remove 'struct hw_pci' and supporting ops in hw_pci
2. add code to create the host bridge from dts
3. add code to scan the the host bridge
4. modify outbound windows setup function to get resource information from
'bridge->windows'
5. add compatible string in pcie dts node with current X-Gene SOC name.
1. redefined each PCI port in different PCI domain correctly.
2. removed setup_lane and setup_link functions from driver.
3. removed scan_bus wrapper and set_primary_bus hack.
4. added pci_ioremap_io for io resources.
1. added PCI domain support
2. reading cpu and pci addresses from device tree to configure regions.
3. got rid of unnecessary wrappers for readl and writel.
4. got rid of endpoint configuration code.
5. added 'dma-ranges' property support to read inbound region configuration.
6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
7. dropped 'clock-names' property from bindings
8. added comments whereever requested.
pci:host: APM X-Gene PCIe host controller driver
arm64: dts: APM X-Gene PCIe device tree nodes
dt-bindings: pci: xgene pcie device tree bindings
MAINTAINERS: entry for APM X-Gene PCIe host driver
.../devicetree/bindings/pci/xgene-pci.txt | 57 ++
MAINTAINERS | 8 +
arch/arm64/boot/dts/apm-mustang.dts | 8 +
arch/arm64/boot/dts/apm-storm.dtsi | 165 ++++++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++
7 files changed, 895 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
create mode 100644 drivers/pci/host/pci-xgene.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Ming Lei
Tanmay Inamdar
2014-09-19 17:15:45 UTC
Permalink
Hi Ming Lei,
Post by Ming Lei
Hi Tanmay,
Post by Tanmay Inamdar
This patch adds support for AppliedMicro X-Gene PCIe host controller. The
driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
cards.
X-Gene PCIe controller driver has depedency on the pcie arm64 arch support.
Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and
support for creating generic pcie bridge from device tree. Liviu's patches
are available here
https://lkml.org/lkml/2014/9/8/333
If someone wishes to test PCIe on X-Gene with this patch set, above mentioned
patches from Liviu must be applied before the patches in this patch set. Also
please use latest xgene u-boot firmware.
1. Add 'dma-coherent' attribute in device node.
I just tested your V9 patches plus Liviu's V10 PCI/ARM64 patches
[ 1.190131] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit
Ethernet Driver bnx2x 1.78.19-0 (2014/02/10)
[ 1.200249] tg3.c:v3.137 (May 11, 2014)
[ 1.204087] ------------[ cut here ]------------
[ 1.208682] WARNING: CPU: 1 PID: 1 at drivers/pci/pci.c:131
pci_ioremap_bar+0x70/0x78()
[ 1.219696] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5+ #1
[ 1.228453] [<ffffffc0000884f0>] dump_backtrace+0x0/0x16c
[ 1.233826] [<ffffffc00008866c>] show_stack+0x10/0x1c
[ 1.238851] [<ffffffc0006e3210>] dump_stack+0x74/0x94
[ 1.243878] [<ffffffc0000a934c>] warn_slowpath_common+0x88/0xb0
[ 1.249767] [<ffffffc0000a9438>] warn_slowpath_null+0x14/0x20
[ 1.255485] [<ffffffc0003994c4>] pci_ioremap_bar+0x6c/0x78
[ 1.260942] [<ffffffc0005598cc>] tg3_init_one+0x148/0x16f4
[ 1.266401] [<ffffffc00039ccf0>] pci_device_probe+0x78/0xd4
[ 1.271946] [<ffffffc00042785c>] driver_probe_device+0x94/0x390
[ 1.277834] [<ffffffc000427c44>] __driver_attach+0x98/0xa0
[ 1.283293] [<ffffffc000425a54>] bus_for_each_dev+0x54/0x98
[ 1.288835] [<ffffffc00042730c>] driver_attach+0x1c/0x28
[ 1.294121] [<ffffffc000426f04>] bus_add_driver+0x164/0x240
[ 1.299663] [<ffffffc000428430>] driver_register+0x64/0x130
[ 1.305207] [<ffffffc00039c97c>] __pci_register_driver+0x3c/0x48
[ 1.311181] [<ffffffc000aa8a5c>] tg3_driver_init+0x1c/0x28
[ 1.316640] [<ffffffc0000814e0>] do_one_initcall+0xc4/0x1b4
[ 1.322186] [<ffffffc000a74b64>] kernel_init_freeable+0x1b8/0x25c
[ 1.328246] [<ffffffc0006de318>] kernel_init+0xc/0xd4
[ 1.333278] ---[ end trace f4dca5ab5b436080 ]---
[ 1.337871] tg3 0000:01:00.0: Cannot map device registers, aborting
[ 1.344122] tg3: probe of 0000:01:00.0 failed with error -12
Thanks for trying out the patches. Which firmware version are you
using? We may have release new firmware version for PCI to work if not
released yet.
Also can you please send out the entire boot log?

Thanks,
Tanmay
Post by Ming Lei
Thanks,
Post by Tanmay Inamdar
1. Fix outbound region mapping for IO region. Thanks Liviu for the catch.
1. Port driver to changed interface as per Liviu's v10 series.
1. Port driver to changed interface of 'of_create_pci_host_bridge'
2. Fix the prefetch bit setting
3. Removed bunch of register programming which is already done by firmware
1. fix section mismatch warnings
2. fix the patch description
3. fix indentation
4. update read/write cfg functions by passing both addr and offset.
5. use 'time_before' for timeout.
6. remove unnecessary 'IS_ERR_OR_NULL'. Keep 'IS_ERR' for 'clk_get'
7. remove BUG_ON for pci_ioremap_io.
1. remove 'struct hw_pci' and supporting ops in hw_pci
2. add code to create the host bridge from dts
3. add code to scan the the host bridge
4. modify outbound windows setup function to get resource information from
'bridge->windows'
5. add compatible string in pcie dts node with current X-Gene SOC name.
1. redefined each PCI port in different PCI domain correctly.
2. removed setup_lane and setup_link functions from driver.
3. removed scan_bus wrapper and set_primary_bus hack.
4. added pci_ioremap_io for io resources.
1. added PCI domain support
2. reading cpu and pci addresses from device tree to configure regions.
3. got rid of unnecessary wrappers for readl and writel.
4. got rid of endpoint configuration code.
5. added 'dma-ranges' property support to read inbound region configuration.
6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
7. dropped 'clock-names' property from bindings
8. added comments whereever requested.
pci:host: APM X-Gene PCIe host controller driver
arm64: dts: APM X-Gene PCIe device tree nodes
dt-bindings: pci: xgene pcie device tree bindings
MAINTAINERS: entry for APM X-Gene PCIe host driver
.../devicetree/bindings/pci/xgene-pci.txt | 57 ++
MAINTAINERS | 8 +
arch/arm64/boot/dts/apm-mustang.dts | 8 +
arch/arm64/boot/dts/apm-storm.dtsi | 165 ++++++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++
7 files changed, 895 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
create mode 100644 drivers/pci/host/pci-xgene.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Ming Lei
Ming Lei
2014-09-22 01:23:51 UTC
Permalink
Hi Tanmay,
Post by Tanmay Inamdar
Hi Ming Lei,
Post by Ming Lei
Hi Tanmay,
Post by Tanmay Inamdar
This patch adds support for AppliedMicro X-Gene PCIe host controller. The
driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
cards.
X-Gene PCIe controller driver has depedency on the pcie arm64 arch support.
Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and
support for creating generic pcie bridge from device tree. Liviu's patches
are available here
https://lkml.org/lkml/2014/9/8/333
If someone wishes to test PCIe on X-Gene with this patch set, above mentioned
patches from Liviu must be applied before the patches in this patch set. Also
please use latest xgene u-boot firmware.
1. Add 'dma-coherent' attribute in device node.
I just tested your V9 patches plus Liviu's V10 PCI/ARM64 patches
[ 1.190131] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit
Ethernet Driver bnx2x 1.78.19-0 (2014/02/10)
[ 1.200249] tg3.c:v3.137 (May 11, 2014)
[ 1.204087] ------------[ cut here ]------------
[ 1.208682] WARNING: CPU: 1 PID: 1 at drivers/pci/pci.c:131
pci_ioremap_bar+0x70/0x78()
[ 1.219696] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5+ #1
[ 1.228453] [<ffffffc0000884f0>] dump_backtrace+0x0/0x16c
[ 1.233826] [<ffffffc00008866c>] show_stack+0x10/0x1c
[ 1.238851] [<ffffffc0006e3210>] dump_stack+0x74/0x94
[ 1.243878] [<ffffffc0000a934c>] warn_slowpath_common+0x88/0xb0
[ 1.249767] [<ffffffc0000a9438>] warn_slowpath_null+0x14/0x20
[ 1.255485] [<ffffffc0003994c4>] pci_ioremap_bar+0x6c/0x78
[ 1.260942] [<ffffffc0005598cc>] tg3_init_one+0x148/0x16f4
[ 1.266401] [<ffffffc00039ccf0>] pci_device_probe+0x78/0xd4
[ 1.271946] [<ffffffc00042785c>] driver_probe_device+0x94/0x390
[ 1.277834] [<ffffffc000427c44>] __driver_attach+0x98/0xa0
[ 1.283293] [<ffffffc000425a54>] bus_for_each_dev+0x54/0x98
[ 1.288835] [<ffffffc00042730c>] driver_attach+0x1c/0x28
[ 1.294121] [<ffffffc000426f04>] bus_add_driver+0x164/0x240
[ 1.299663] [<ffffffc000428430>] driver_register+0x64/0x130
[ 1.305207] [<ffffffc00039c97c>] __pci_register_driver+0x3c/0x48
[ 1.311181] [<ffffffc000aa8a5c>] tg3_driver_init+0x1c/0x28
[ 1.316640] [<ffffffc0000814e0>] do_one_initcall+0xc4/0x1b4
[ 1.322186] [<ffffffc000a74b64>] kernel_init_freeable+0x1b8/0x25c
[ 1.328246] [<ffffffc0006de318>] kernel_init+0xc/0xd4
[ 1.333278] ---[ end trace f4dca5ab5b436080 ]---
[ 1.337871] tg3 0000:01:00.0: Cannot map device registers, aborting
[ 1.344122] tg3: probe of 0000:01:00.0 failed with error -12
Thanks for trying out the patches. Which firmware version are you
using? We may have release new firmware version for PCI to work if not
released yet.
U-Boot 2013.04-mustang_sw_1.13.28-beta (Aug 25 2014 - 14:16:10)

I will check if there is newer fw available.
Post by Tanmay Inamdar
Also can you please send out the entire boot log?
Please see below link:

http://pastebin.com/fLqaDn6t

Thanks,
--
Ming Lei
Post by Tanmay Inamdar
Thanks,
Tanmay
Post by Ming Lei
Thanks,
Post by Tanmay Inamdar
1. Fix outbound region mapping for IO region. Thanks Liviu for the catch.
1. Port driver to changed interface as per Liviu's v10 series.
1. Port driver to changed interface of 'of_create_pci_host_bridge'
2. Fix the prefetch bit setting
3. Removed bunch of register programming which is already done by firmware
1. fix section mismatch warnings
2. fix the patch description
3. fix indentation
4. update read/write cfg functions by passing both addr and offset.
5. use 'time_before' for timeout.
6. remove unnecessary 'IS_ERR_OR_NULL'. Keep 'IS_ERR' for 'clk_get'
7. remove BUG_ON for pci_ioremap_io.
1. remove 'struct hw_pci' and supporting ops in hw_pci
2. add code to create the host bridge from dts
3. add code to scan the the host bridge
4. modify outbound windows setup function to get resource information from
'bridge->windows'
5. add compatible string in pcie dts node with current X-Gene SOC name.
1. redefined each PCI port in different PCI domain correctly.
2. removed setup_lane and setup_link functions from driver.
3. removed scan_bus wrapper and set_primary_bus hack.
4. added pci_ioremap_io for io resources.
1. added PCI domain support
2. reading cpu and pci addresses from device tree to configure regions.
3. got rid of unnecessary wrappers for readl and writel.
4. got rid of endpoint configuration code.
5. added 'dma-ranges' property support to read inbound region configuration.
6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
7. dropped 'clock-names' property from bindings
8. added comments whereever requested.
pci:host: APM X-Gene PCIe host controller driver
arm64: dts: APM X-Gene PCIe device tree nodes
dt-bindings: pci: xgene pcie device tree bindings
MAINTAINERS: entry for APM X-Gene PCIe host driver
.../devicetree/bindings/pci/xgene-pci.txt | 57 ++
MAINTAINERS | 8 +
arch/arm64/boot/dts/apm-mustang.dts | 8 +
arch/arm64/boot/dts/apm-storm.dtsi | 165 ++++++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++
7 files changed, 895 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
create mode 100644 drivers/pci/host/pci-xgene.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Ming Lei
--
Ming Lei
Bjorn Helgaas
2014-09-30 16:53:53 UTC
Permalink
Post by Ming Lei
Hi Tanmay,
Post by Tanmay Inamdar
Hi Ming Lei,
Post by Ming Lei
Hi Tanmay,
Post by Tanmay Inamdar
This patch adds support for AppliedMicro X-Gene PCIe host controller. The
driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
cards.
X-Gene PCIe controller driver has depedency on the pcie arm64 arch support.
Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and
support for creating generic pcie bridge from device tree. Liviu's patches
are available here
https://lkml.org/lkml/2014/9/8/333
If someone wishes to test PCIe on X-Gene with this patch set, above mentioned
patches from Liviu must be applied before the patches in this patch set. Also
please use latest xgene u-boot firmware.
1. Add 'dma-coherent' attribute in device node.
I just tested your V9 patches plus Liviu's V10 PCI/ARM64 patches
[ 1.190131] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit
Ethernet Driver bnx2x 1.78.19-0 (2014/02/10)
[ 1.200249] tg3.c:v3.137 (May 11, 2014)
[ 1.204087] ------------[ cut here ]------------
[ 1.208682] WARNING: CPU: 1 PID: 1 at drivers/pci/pci.c:131
pci_ioremap_bar+0x70/0x78()
[ 1.219696] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5+ #1
[ 1.228453] [<ffffffc0000884f0>] dump_backtrace+0x0/0x16c
[ 1.233826] [<ffffffc00008866c>] show_stack+0x10/0x1c
[ 1.238851] [<ffffffc0006e3210>] dump_stack+0x74/0x94
[ 1.243878] [<ffffffc0000a934c>] warn_slowpath_common+0x88/0xb0
[ 1.249767] [<ffffffc0000a9438>] warn_slowpath_null+0x14/0x20
[ 1.255485] [<ffffffc0003994c4>] pci_ioremap_bar+0x6c/0x78
[ 1.260942] [<ffffffc0005598cc>] tg3_init_one+0x148/0x16f4
[ 1.266401] [<ffffffc00039ccf0>] pci_device_probe+0x78/0xd4
[ 1.271946] [<ffffffc00042785c>] driver_probe_device+0x94/0x390
[ 1.277834] [<ffffffc000427c44>] __driver_attach+0x98/0xa0
[ 1.283293] [<ffffffc000425a54>] bus_for_each_dev+0x54/0x98
[ 1.288835] [<ffffffc00042730c>] driver_attach+0x1c/0x28
[ 1.294121] [<ffffffc000426f04>] bus_add_driver+0x164/0x240
[ 1.299663] [<ffffffc000428430>] driver_register+0x64/0x130
[ 1.305207] [<ffffffc00039c97c>] __pci_register_driver+0x3c/0x48
[ 1.311181] [<ffffffc000aa8a5c>] tg3_driver_init+0x1c/0x28
[ 1.316640] [<ffffffc0000814e0>] do_one_initcall+0xc4/0x1b4
[ 1.322186] [<ffffffc000a74b64>] kernel_init_freeable+0x1b8/0x25c
[ 1.328246] [<ffffffc0006de318>] kernel_init+0xc/0xd4
[ 1.333278] ---[ end trace f4dca5ab5b436080 ]---
[ 1.337871] tg3 0000:01:00.0: Cannot map device registers, aborting
[ 1.344122] tg3: probe of 0000:01:00.0 failed with error -12
Thanks for trying out the patches. Which firmware version are you
using? We may have release new firmware version for PCI to work if not
released yet.
U-Boot 2013.04-mustang_sw_1.13.28-beta (Aug 25 2014 - 14:16:10)
I will check if there is newer fw available.
Post by Tanmay Inamdar
Also can you please send out the entire boot log?
http://pastebin.com/fLqaDn6t
PCI host bridge /soc/***@1f2b0000 ranges:
No bus range found for /soc/***@1f2b0000, using [??? 0xffffffc3eb4292c0-0xffffffc0005e3b8c flags 0x40]

What's going on here? It looks like it's from
of_pci_get_host_bridge_resources(), but I don't see how this output could
happen.

IO 0xe010000000..0xe01000ffff -> 0x00000000
MEM 0xe180000000..0xe1ffffffff -> 0x80000000
xgene-pcie 1f2b0000.pcie: (rc) x1 gen-1 link up
xgene-pcie 1f2b0000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0xe180000000-0xe1ffffffff] (bus address [0x80000000-0xffffffff])
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: [19aa:e008] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x8000000000-0x807fffffff 64bit pref]

I guess this is the "inbound BAR" that you hid in the v10 patches. Hiding
it will prevent some of BAR assignment problems below. This is probably
what caused the tg3 mapping problem Ming initially reported above. We
tried to reassign the inbound BAR, and it took up the entire space that we
thought was available for CPU accesses to the PCI bus, leaving none for the
tg3 device.

Was Ming just unlucky by having an unusual configuration, e.g., with a lot
of memory or something? He certainly doesn't have a complicated PCIe
hierarchy. I assume you've tested this and had it work *somewhere*.

pci 0000:00:00.0: supports D1 D2
pci_bus 0000:00: fixups for bus
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: [14e4:165a] type 00 class 0x020000
pci 0000:01:00.0: reg 0x10: [mem 0x00100000-0x0010ffff 64bit]
pci 0000:01:00.0: PME# supported from D3hot
pci 0000:01:00.0: PME# disabled
pci_bus 0000:01: fixups for bus
pci_bus 0000:01: bus scan returning with max=01
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
pci_bus 0000:00: bus scan returning with max=01
pci 0000:00:00.0: BAR 0: assigned [mem 0xe180000000-0xe1ffffffff 64bit pref]
pci 0000:00:00.0: BAR 8: no space for [mem size 0x00100000]
pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00100000]
pci 0000:01:00.0: BAR 0: no space for [mem size 0x00010000 64bit]
pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00010000 64bit]
pci 0000:00:00.0: PCI bridge to [bus 01]
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Liviu Dudau
2014-09-30 17:01:01 UTC
Permalink
Post by Bjorn Helgaas
Post by Ming Lei
Hi Tanmay,
=20
Post by Tanmay Inamdar
Hi Ming Lei,
Post by Ming Lei
Hi Tanmay,
This patch adds support for AppliedMicro X-Gene PCIe host contr=
oller. The
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
driver is tested on X-Gene platform with different gen1/2/3 PCI=
e endpoint
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
cards.
X-Gene PCIe controller driver has depedency on the pcie arm64 a=
rch support.
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
Liviu Dudau from ARM has sent a patch set for pcie arm64 arch s=
upport and
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
support for creating generic pcie bridge from device tree. Livi=
u's patches
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
are available here
https://lkml.org/lkml/2014/9/8/333
If someone wishes to test PCIe on X-Gene with this patch set, a=
bove mentioned
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
patches from Liviu must be applied before the patches in this p=
atch set. Also
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
please use latest xgene u-boot firmware.
1. Add 'dma-coherent' attribute in device node.
I just tested your V9 patches plus Liviu's V10 PCI/ARM64 patches
against 3.17-rc5 on Mustang, and the following failure is trigge=
[ 1.190131] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gi=
gabit
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
Ethernet Driver bnx2x 1.78.19-0 (2014/02/10)
[ 1.200249] tg3.c:v3.137 (May 11, 2014)
[ 1.204087] ------------[ cut here ]------------
[ 1.208682] WARNING: CPU: 1 PID: 1 at drivers/pci/pci.c:131
pci_ioremap_bar+0x70/0x78()
[ 1.219696] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0-=
rc5+ #1
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
[ 1.228453] [<ffffffc0000884f0>] dump_backtrace+0x0/0x16c
[ 1.233826] [<ffffffc00008866c>] show_stack+0x10/0x1c
[ 1.238851] [<ffffffc0006e3210>] dump_stack+0x74/0x94
[ 1.243878] [<ffffffc0000a934c>] warn_slowpath_common+0x88/0x=
b0
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
[ 1.249767] [<ffffffc0000a9438>] warn_slowpath_null+0x14/0x20
[ 1.255485] [<ffffffc0003994c4>] pci_ioremap_bar+0x6c/0x78
[ 1.260942] [<ffffffc0005598cc>] tg3_init_one+0x148/0x16f4
[ 1.266401] [<ffffffc00039ccf0>] pci_device_probe+0x78/0xd4
[ 1.271946] [<ffffffc00042785c>] driver_probe_device+0x94/0x3=
90
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
[ 1.277834] [<ffffffc000427c44>] __driver_attach+0x98/0xa0
[ 1.283293] [<ffffffc000425a54>] bus_for_each_dev+0x54/0x98
[ 1.288835] [<ffffffc00042730c>] driver_attach+0x1c/0x28
[ 1.294121] [<ffffffc000426f04>] bus_add_driver+0x164/0x240
[ 1.299663] [<ffffffc000428430>] driver_register+0x64/0x130
[ 1.305207] [<ffffffc00039c97c>] __pci_register_driver+0x3c/0=
x48
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
[ 1.311181] [<ffffffc000aa8a5c>] tg3_driver_init+0x1c/0x28
[ 1.316640] [<ffffffc0000814e0>] do_one_initcall+0xc4/0x1b4
[ 1.322186] [<ffffffc000a74b64>] kernel_init_freeable+0x1b8/0=
x25c
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
[ 1.328246] [<ffffffc0006de318>] kernel_init+0xc/0xd4
[ 1.333278] ---[ end trace f4dca5ab5b436080 ]---
[ 1.337871] tg3 0000:01:00.0: Cannot map device registers, ab=
orting
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
Post by Ming Lei
[ 1.344122] tg3: probe of 0000:01:00.0 failed with error -12
Thanks for trying out the patches. Which firmware version are you
using? We may have release new firmware version for PCI to work i=
f not
Post by Bjorn Helgaas
Post by Ming Lei
Post by Tanmay Inamdar
released yet.
=20
U-Boot 2013.04-mustang_sw_1.13.28-beta (Aug 25 2014 - 14:16:10)
=20
I will check if there is newer fw available.
=20
Post by Tanmay Inamdar
Also can you please send out the entire boot log?
=20
=20
http://pastebin.com/fLqaDn6t
=20
=20
b4292c0-0xffffffc0005e3b8c flags 0x40]
Post by Bjorn Helgaas
=20
What's going on here? It looks like it's from
of_pci_get_host_bridge_resources(), but I don't see how this output c=
ould
Post by Bjorn Helgaas
happen.
Sorry, v9 to v11 had a bug in the print message where the range was pas=
sed as a reference. I have since
fixed it in v12. I've noticed this log when preparing for v12 but someh=
ow missed it in the change log?

Best regards,
Liviu
Post by Bjorn Helgaas
=20
IO 0xe010000000..0xe01000ffff -> 0x00000000
MEM 0xe180000000..0xe1ffffffff -> 0x80000000
xgene-pcie 1f2b0000.pcie: (rc) x1 gen-1 link up
xgene-pcie 1f2b0000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0xe180000000-0xe1ffffffff] =
(bus address [0x80000000-0xffffffff])
Post by Bjorn Helgaas
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: [19aa:e008] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x8000000000-0x807fffffff 64bit pr=
ef]
Post by Bjorn Helgaas
=20
I guess this is the "inbound BAR" that you hid in the v10 patches. H=
iding
Post by Bjorn Helgaas
it will prevent some of BAR assignment problems below. This is proba=
bly
Post by Bjorn Helgaas
what caused the tg3 mapping problem Ming initially reported above. W=
e
Post by Bjorn Helgaas
tried to reassign the inbound BAR, and it took up the entire space th=
at we
Post by Bjorn Helgaas
thought was available for CPU accesses to the PCI bus, leaving none f=
or the
Post by Bjorn Helgaas
tg3 device.
=20
Was Ming just unlucky by having an unusual configuration, e.g., with =
a lot
Post by Bjorn Helgaas
of memory or something? He certainly doesn't have a complicated PCIe
hierarchy. I assume you've tested this and had it work *somewhere*.
=20
pci 0000:00:00.0: supports D1 D2
pci_bus 0000:00: fixups for bus
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: [14e4:165a] type 00 class 0x020000
pci 0000:01:00.0: reg 0x10: [mem 0x00100000-0x0010ffff 64bit]
pci 0000:01:00.0: PME# supported from D3hot
pci 0000:01:00.0: PME# disabled
pci_bus 0000:01: fixups for bus
pci_bus 0000:01: bus scan returning with max=3D01
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
pci_bus 0000:00: bus scan returning with max=3D01
pci 0000:00:00.0: BAR 0: assigned [mem 0xe180000000-0xe1ffffffff 64=
bit pref]
Post by Bjorn Helgaas
pci 0000:00:00.0: BAR 8: no space for [mem size 0x00100000]
pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00100000]
pci 0000:01:00.0: BAR 0: no space for [mem size 0x00010000 64bit]
pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00010000 64bi=
t]
Post by Bjorn Helgaas
pci 0000:00:00.0: PCI bridge to [bus 01]
=20
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
=C2=AF\_(=E3=83=84)_/=C2=AF

Loading...