* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-16 8:20 ` Sean Cross
0 siblings, 0 replies; 59+ messages in thread
From: Sean Cross @ 2013-09-16 8:20 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sascha Hauer, Zhu Richard-R65037, Shawn Guo,
tharvey-UMMOYl/HMS+akBO8gow8eQ, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
Sean Cross
Add support for the PCIe port present on the i.MX6 family of controllers.
These use the Synopsis Designware core tied to their own PHY.
Signed-off-by: Sean Cross <xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>
Acked-by: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
.../devicetree/bindings/pci/designware-pcie.txt | 7 +-
arch/arm/boot/dts/imx6qdl.dtsi | 16 +
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/clk-imx6q.c | 4 +
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-imx6.c | 576 ++++++++++++++++++++
7 files changed, 611 insertions(+), 1 deletion(-)
create mode 100644 drivers/pci/host/pci-imx6.c
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index eabcb4b..dd8d920 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -3,7 +3,7 @@
Required properties:
- compatible: should contain "snps,dw-pcie" to identify the
core, plus an identifier for the specific instance, such
- as "samsung,exynos5440-pcie".
+ as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
- reg: base addresses and lengths of the pcie controller,
the phy controller, additional register for the phy controller.
- interrupts: interrupt values for level interrupt,
@@ -21,6 +21,11 @@ Required properties:
- num-lanes: number of lanes to use
- reset-gpio: gpio pin number of power good signal
+Optional properties for fsl,imx6q-pcie
+- power-on-gpio: gpio pin number of power-enable signal
+- wake-up-gpio: gpio pin number of incoming wakeup signal
+- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
+
Example:
SoC specific DT Entry:
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index ccd55c2..125202e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -116,6 +116,22 @@
arm,data-latency = <4 2 3>;
};
+ pcie: pcie@0x01000000 {
+ compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
+ reg = <0x01ffc000 0x4000>; /* DBI */
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
+ 0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
+ 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
+ num-lanes = <1>;
+ interrupts = <0 123 0x04>;
+ clocks = <&clks 189>, <&clks 187>, <&clks 205>, <&clks 144>;
+ clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
+ status = "disabled";
+ };
+
pmu {
compatible = "arm,cortex-a9-pmu";
interrupts = <0 94 0x04>;
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 29a8af6..e6ac281 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -801,6 +801,8 @@ config SOC_IMX6Q
select HAVE_IMX_SRC
select HAVE_SMP
select MFD_SYSCON
+ select MIGHT_HAVE_PCI
+ select PCI_DOMAINS if PCI
select PINCTRL
select PINCTRL_IMX6Q
select PL310_ERRATA_588369 if CACHE_PL310
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index d94be84..6956995 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -621,6 +621,10 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
if (ret)
pr_warn("failed to set up CLKO: %d\n", ret);
+ /* All existing boards with PCIe use LVDS1 */
+ if (IS_ENABLED(CONFIG_PCI_IMX6))
+ clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
+
/* Set initial power mode */
imx6q_set_lpm(WAIT_CLOCKED);
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 3d95048..efa24d9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,12 @@ config PCI_EXYNOS
select PCIEPORTBUS
select PCIE_DW
+config PCI_IMX6
+ bool "Freescale i.MX6 PCIe controller"
+ depends on SOC_IMX6Q
+ select PCIEPORTBUS
+ select PCIE_DW
+
config PCI_TEGRA
bool "NVIDIA Tegra PCIe controller"
depends on ARCH_TEGRA
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index c9a997b..287d6a0 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_PCIE_DW) += pcie-designware.o
obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
+obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
new file mode 100644
index 0000000..f68cc2e
--- /dev/null
+++ b/drivers/pci/host/pci-imx6.c
@@ -0,0 +1,576 @@
+/*
+ * PCIe host controller driver for Freescale i.MX6 SoCs
+ *
+ * Copyright (C) 2013 Kosagi
+ * http://www.kosagi.com
+ *
+ * Author: Sean Cross <xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/resource.h>
+#include <linux/signal.h>
+#include <linux/types.h>
+
+#include "pcie-designware.h"
+
+#define to_imx6_pcie(x) container_of(x, struct imx6_pcie, pp)
+
+struct imx6_pcie {
+ int reset_gpio;
+ int power_on_gpio;
+ int wake_up_gpio;
+ int disable_gpio;
+ struct clk *lvds_gate;
+ struct clk *sata_ref_100m;
+ struct clk *pcie_ref_125m;
+ struct clk *pcie_axi;
+ struct pcie_port pp;
+ struct regmap *iomuxc_gpr;
+ void __iomem *mem_base;
+};
+
+/* PCIe Port Logic registers (memory-mapped) */
+#define PL_OFFSET 0x700
+#define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
+#define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
+
+#define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
+#define PCIE_PHY_CTRL_DATA_LOC 0
+#define PCIE_PHY_CTRL_CAP_ADR_LOC 16
+#define PCIE_PHY_CTRL_CAP_DAT_LOC 17
+#define PCIE_PHY_CTRL_WR_LOC 18
+#define PCIE_PHY_CTRL_RD_LOC 19
+
+#define PCIE_PHY_STAT (PL_OFFSET + 0x110)
+#define PCIE_PHY_STAT_ACK_LOC 16
+
+/* PHY registers (not memory-mapped) */
+#define PCIE_PHY_RX_ASIC_OUT 0x100D
+
+#define PHY_RX_OVRD_IN_LO 0x1005
+#define PHY_RX_OVRD_IN_LO_RX_DATA_EN (1 << 5)
+#define PHY_RX_OVRD_IN_LO_RX_PLL_EN (1 << 3)
+
+static int pcie_phy_poll_ack(void __iomem *dbi_base, int exp_val)
+{
+ u32 val;
+ u32 max_iterations = 10;
+ u32 wait_counter = 0;
+
+ do {
+ val = readl(dbi_base + PCIE_PHY_STAT);
+ val = (val >> PCIE_PHY_STAT_ACK_LOC) & 0x1;
+ wait_counter++;
+
+ if (val == exp_val)
+ return 0;
+
+ udelay(1);
+ } while ((wait_counter < max_iterations) && (val != exp_val));
+
+ return -ETIMEDOUT;
+}
+
+static int pcie_phy_wait_ack(void __iomem *dbi_base, int addr)
+{
+ u32 val;
+ int ret;
+
+ val = addr << PCIE_PHY_CTRL_DATA_LOC;
+ writel(val, dbi_base + PCIE_PHY_CTRL);
+
+ val |= (0x1 << PCIE_PHY_CTRL_CAP_ADR_LOC);
+ writel(val, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ val = addr << PCIE_PHY_CTRL_DATA_LOC;
+ writel(val, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+/* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */
+static int pcie_phy_read(void __iomem *dbi_base, int addr , int *data)
+{
+ u32 val, phy_ctl;
+ int ret;
+
+ ret = pcie_phy_wait_ack(dbi_base, addr);
+ if (ret)
+ return ret;
+
+ /* assert Read signal */
+ phy_ctl = 0x1 << PCIE_PHY_CTRL_RD_LOC;
+ writel(phy_ctl, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ val = readl(dbi_base + PCIE_PHY_STAT);
+ *data = val & 0xffff;
+
+ /* deassert Read signal */
+ writel(0x00, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int pcie_phy_write(void __iomem *dbi_base, int addr, int data)
+{
+ u32 var;
+ int ret;
+
+ /* write addr */
+ /* cap addr */
+ ret = pcie_phy_wait_ack(dbi_base, addr);
+ if (ret)
+ return ret;
+
+ var = data << PCIE_PHY_CTRL_DATA_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* capture data */
+ var |= (0x1 << PCIE_PHY_CTRL_CAP_DAT_LOC);
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ /* deassert cap data */
+ var = data << PCIE_PHY_CTRL_DATA_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* wait for ack de-assetion */
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ /* assert wr signal */
+ var = 0x1 << PCIE_PHY_CTRL_WR_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* wait for ack */
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ /* deassert wr signal */
+ var = data << PCIE_PHY_CTRL_DATA_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* wait for ack de-assetion */
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ writel(0x0, dbi_base + PCIE_PHY_CTRL);
+
+ return 0;
+}
+
+/* Added for PCI abort handling */
+static int imx6q_pcie_abort_handler(unsigned long addr,
+ unsigned int fsr, struct pt_regs *regs)
+{
+ /*
+ * If it was an imprecise abort, then we need to correct the
+ * return address to be _after_ the instruction.
+ */
+ if (fsr & (1 << 10))
+ regs->ARM_pc += 4;
+ return 0;
+}
+
+static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
+{
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
+
+ gpio_set_value(imx6_pcie->reset_gpio, 0);
+ msleep(100);
+ gpio_set_value(imx6_pcie->reset_gpio, 1);
+
+ return 0;
+}
+
+static int imx6_pcie_deassert_core_reset(struct pcie_port *pp)
+{
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+ int ret;
+
+ if (gpio_is_valid(imx6_pcie->power_on_gpio))
+ gpio_set_value(imx6_pcie->power_on_gpio, 1);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
+
+ ret = clk_prepare_enable(imx6_pcie->sata_ref_100m);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable sata_ref_100m\n");
+ goto err_sata_ref;
+ }
+
+ ret = clk_prepare_enable(imx6_pcie->pcie_ref_125m);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable pcie_ref_125m\n");
+ goto err_pcie_ref;
+ }
+
+ ret = clk_prepare_enable(imx6_pcie->lvds_gate);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable lvds_gate\n");
+ goto err_lvds_gate;
+ }
+
+ ret = clk_prepare_enable(imx6_pcie->pcie_axi);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable pcie_axi\n");
+ goto err_pcie_axi;
+ }
+
+ /* allow the clocks to stabilize */
+ usleep_range(200, 500);
+
+ return 0;
+
+err_pcie_axi:
+ clk_disable_unprepare(imx6_pcie->lvds_gate);
+err_lvds_gate:
+ clk_disable_unprepare(imx6_pcie->pcie_ref_125m);
+err_pcie_ref:
+ clk_disable_unprepare(imx6_pcie->sata_ref_100m);
+err_sata_ref:
+ return ret;
+
+}
+
+static void imx6_pcie_init_phy(struct pcie_port *pp)
+{
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
+
+ /* configure constant input signal to the pcie ctrl and phy */
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_DEVICE_TYPE, PCI_EXP_TYPE_ROOT_PORT << 12);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN1, 0 << 0);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB, 0 << 6);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB, 20 << 12);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_SWING_FULL, 127 << 18);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_SWING_LOW, 127 << 25);
+}
+
+static void imx6_pcie_host_init(struct pcie_port *pp)
+{
+ int count = 0;
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+
+ imx6_pcie_assert_core_reset(pp);
+
+ imx6_pcie_init_phy(pp);
+
+ imx6_pcie_deassert_core_reset(pp);
+
+ dw_pcie_setup_rc(pp);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
+
+ while (!dw_pcie_link_up(pp)) {
+ usleep_range(100, 1000);
+ count++;
+ if (count >= 10) {
+ dev_err(pp->dev, "phy link never came up\n");
+ dev_dbg(pp->dev,
+ "DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
+ readl(pp->dbi_base + PCIE_PHY_DEBUG_R0),
+ readl(pp->dbi_base + PCIE_PHY_DEBUG_R1));
+ break;
+ }
+ }
+
+ return;
+}
+
+static int imx6_pcie_link_up(struct pcie_port *pp)
+{
+ u32 rc, ltssm, rx_valid, temp;
+
+ /* link is debug bit 36, debug register 1 starts at bit 32 */
+ rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
+ if (rc)
+ return -EAGAIN;
+
+ /*
+ * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
+ * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
+ * If (MAC/LTSSM.state == Recovery.RcvrLock)
+ * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
+ * to gen2 is stuck
+ */
+ pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
+ ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
+
+ if (rx_valid & 0x01)
+ return 0;
+
+ if (ltssm != 0x0d)
+ return 0;
+
+ dev_err(pp->dev,
+ "transition to gen2 is stuck, reset PHY!\n");
+
+ pcie_phy_read(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, &temp);
+ temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
+ | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
+ pcie_phy_write(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, temp);
+
+ usleep_range(2000, 3000);
+
+ pcie_phy_read(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, &temp);
+ temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
+ | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
+ pcie_phy_write(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, temp);
+
+ return 0;
+}
+
+static struct pcie_host_ops imx6_pcie_host_ops = {
+ .link_up = imx6_pcie_link_up,
+ .host_init = imx6_pcie_host_init,
+};
+
+static int imx6_add_pcie_port(struct pcie_port *pp,
+ struct platform_device *pdev)
+{
+ int ret;
+
+ pp->irq = platform_get_irq(pdev, 0);
+ if (!pp->irq) {
+ dev_err(&pdev->dev, "failed to get irq\n");
+ return -ENODEV;
+ }
+
+ pp->root_bus_nr = -1;
+ pp->ops = &imx6_pcie_host_ops;
+
+ spin_lock_init(&pp->conf_lock);
+ ret = dw_pcie_host_init(pp);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to initialize host\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __init imx6_pcie_probe(struct platform_device *pdev)
+{
+ struct imx6_pcie *imx6_pcie;
+ struct pcie_port *pp;
+ struct device_node *np = pdev->dev.of_node;
+ struct resource *dbi_base;
+ int ret;
+
+ imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
+ if (!imx6_pcie)
+ return -ENOMEM;
+
+ pp = &imx6_pcie->pp;
+ pp->dev = &pdev->dev;
+
+ /* Added for PCI abort handling */
+ hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
+ "imprecise external abort");
+
+ dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!dbi_base) {
+ dev_err(&pdev->dev, "dbi_base memory resource not found\n");
+ return -ENODEV;
+ }
+
+ pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
+ if (IS_ERR(pp->dbi_base)) {
+ dev_err(&pdev->dev, "unable to remap dbi_base\n");
+ ret = PTR_ERR(pp->dbi_base);
+ goto err;
+ }
+
+ /* Fetch GPIOs */
+ imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
+ if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
+ dev_err(&pdev->dev, "no reset-gpio defined\n");
+ ret = -ENODEV;
+ }
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->reset_gpio,
+ GPIOF_OUT_INIT_LOW,
+ "PCIe reset");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get reset gpio\n");
+ goto err;
+ }
+
+ imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
+ if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->power_on_gpio,
+ GPIOF_OUT_INIT_LOW,
+ "PCIe power enable");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get power-on gpio\n");
+ goto err;
+ }
+ }
+
+ imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
+ if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->wake_up_gpio,
+ GPIOF_IN,
+ "PCIe wake up");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get wake-up gpio\n");
+ goto err;
+ }
+ }
+
+ imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
+ if (gpio_is_valid(imx6_pcie->disable_gpio)) {
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->disable_gpio,
+ GPIOF_OUT_INIT_HIGH,
+ "PCIe disable endpoint");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
+ goto err;
+ }
+ }
+
+ /* Fetch clocks */
+ imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
+ if (IS_ERR(imx6_pcie->lvds_gate)) {
+ dev_err(&pdev->dev,
+ "lvds_gate clock select missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->lvds_gate);
+ goto err;
+ }
+
+ imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
+ if (IS_ERR(imx6_pcie->sata_ref_100m)) {
+ dev_err(&pdev->dev,
+ "sata_ref_100m clock source missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->sata_ref_100m);
+ goto err;
+ }
+
+ imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
+ if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
+ dev_err(&pdev->dev,
+ "pcie_ref_125m clock source missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
+ goto err;
+ }
+
+ imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
+ if (IS_ERR(imx6_pcie->pcie_axi)) {
+ dev_err(&pdev->dev,
+ "pcie_axi clock source missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->pcie_axi);
+ goto err;
+ }
+
+ /* Grab GPR config register range */
+ imx6_pcie->iomuxc_gpr =
+ syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+ if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
+ dev_err(&pdev->dev, "unable to find iomuxc registers\n");
+ ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
+ goto err;
+ }
+
+ ret = imx6_add_pcie_port(pp, pdev);
+ if (ret < 0)
+ goto err;
+
+ platform_set_drvdata(pdev, imx6_pcie);
+ return 0;
+
+err:
+ return ret;
+}
+
+static const struct of_device_id imx6_pcie_of_match[] = {
+ { .compatible = "fsl,imx6q-pcie", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
+
+static struct platform_driver imx6_pcie_driver = {
+ .driver = {
+ .name = "imx6q-pcie",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(imx6_pcie_of_match),
+ },
+};
+
+/* Freescale PCIe driver does not allow module unload */
+
+static int __init imx6_init(void)
+{
+ return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
+}
+module_init(imx6_init);
+
+MODULE_AUTHOR("Sean Cross <xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>");
+MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-16 8:20 ` Sean Cross
0 siblings, 0 replies; 59+ messages in thread
From: Sean Cross @ 2013-09-16 8:20 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the PCIe port present on the i.MX6 family of controllers.
These use the Synopsis Designware core tied to their own PHY.
Signed-off-by: Sean Cross <xobs@kosagi.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
.../devicetree/bindings/pci/designware-pcie.txt | 7 +-
arch/arm/boot/dts/imx6qdl.dtsi | 16 +
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/clk-imx6q.c | 4 +
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-imx6.c | 576 ++++++++++++++++++++
7 files changed, 611 insertions(+), 1 deletion(-)
create mode 100644 drivers/pci/host/pci-imx6.c
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index eabcb4b..dd8d920 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -3,7 +3,7 @@
Required properties:
- compatible: should contain "snps,dw-pcie" to identify the
core, plus an identifier for the specific instance, such
- as "samsung,exynos5440-pcie".
+ as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
- reg: base addresses and lengths of the pcie controller,
the phy controller, additional register for the phy controller.
- interrupts: interrupt values for level interrupt,
@@ -21,6 +21,11 @@ Required properties:
- num-lanes: number of lanes to use
- reset-gpio: gpio pin number of power good signal
+Optional properties for fsl,imx6q-pcie
+- power-on-gpio: gpio pin number of power-enable signal
+- wake-up-gpio: gpio pin number of incoming wakeup signal
+- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
+
Example:
SoC specific DT Entry:
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index ccd55c2..125202e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -116,6 +116,22 @@
arm,data-latency = <4 2 3>;
};
+ pcie: pcie at 0x01000000 {
+ compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
+ reg = <0x01ffc000 0x4000>; /* DBI */
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
+ 0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
+ 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
+ num-lanes = <1>;
+ interrupts = <0 123 0x04>;
+ clocks = <&clks 189>, <&clks 187>, <&clks 205>, <&clks 144>;
+ clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
+ status = "disabled";
+ };
+
pmu {
compatible = "arm,cortex-a9-pmu";
interrupts = <0 94 0x04>;
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 29a8af6..e6ac281 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -801,6 +801,8 @@ config SOC_IMX6Q
select HAVE_IMX_SRC
select HAVE_SMP
select MFD_SYSCON
+ select MIGHT_HAVE_PCI
+ select PCI_DOMAINS if PCI
select PINCTRL
select PINCTRL_IMX6Q
select PL310_ERRATA_588369 if CACHE_PL310
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index d94be84..6956995 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -621,6 +621,10 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
if (ret)
pr_warn("failed to set up CLKO: %d\n", ret);
+ /* All existing boards with PCIe use LVDS1 */
+ if (IS_ENABLED(CONFIG_PCI_IMX6))
+ clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
+
/* Set initial power mode */
imx6q_set_lpm(WAIT_CLOCKED);
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 3d95048..efa24d9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,12 @@ config PCI_EXYNOS
select PCIEPORTBUS
select PCIE_DW
+config PCI_IMX6
+ bool "Freescale i.MX6 PCIe controller"
+ depends on SOC_IMX6Q
+ select PCIEPORTBUS
+ select PCIE_DW
+
config PCI_TEGRA
bool "NVIDIA Tegra PCIe controller"
depends on ARCH_TEGRA
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index c9a997b..287d6a0 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_PCIE_DW) += pcie-designware.o
obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
+obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
new file mode 100644
index 0000000..f68cc2e
--- /dev/null
+++ b/drivers/pci/host/pci-imx6.c
@@ -0,0 +1,576 @@
+/*
+ * PCIe host controller driver for Freescale i.MX6 SoCs
+ *
+ * Copyright (C) 2013 Kosagi
+ * http://www.kosagi.com
+ *
+ * Author: Sean Cross <xobs@kosagi.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/resource.h>
+#include <linux/signal.h>
+#include <linux/types.h>
+
+#include "pcie-designware.h"
+
+#define to_imx6_pcie(x) container_of(x, struct imx6_pcie, pp)
+
+struct imx6_pcie {
+ int reset_gpio;
+ int power_on_gpio;
+ int wake_up_gpio;
+ int disable_gpio;
+ struct clk *lvds_gate;
+ struct clk *sata_ref_100m;
+ struct clk *pcie_ref_125m;
+ struct clk *pcie_axi;
+ struct pcie_port pp;
+ struct regmap *iomuxc_gpr;
+ void __iomem *mem_base;
+};
+
+/* PCIe Port Logic registers (memory-mapped) */
+#define PL_OFFSET 0x700
+#define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
+#define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
+
+#define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
+#define PCIE_PHY_CTRL_DATA_LOC 0
+#define PCIE_PHY_CTRL_CAP_ADR_LOC 16
+#define PCIE_PHY_CTRL_CAP_DAT_LOC 17
+#define PCIE_PHY_CTRL_WR_LOC 18
+#define PCIE_PHY_CTRL_RD_LOC 19
+
+#define PCIE_PHY_STAT (PL_OFFSET + 0x110)
+#define PCIE_PHY_STAT_ACK_LOC 16
+
+/* PHY registers (not memory-mapped) */
+#define PCIE_PHY_RX_ASIC_OUT 0x100D
+
+#define PHY_RX_OVRD_IN_LO 0x1005
+#define PHY_RX_OVRD_IN_LO_RX_DATA_EN (1 << 5)
+#define PHY_RX_OVRD_IN_LO_RX_PLL_EN (1 << 3)
+
+static int pcie_phy_poll_ack(void __iomem *dbi_base, int exp_val)
+{
+ u32 val;
+ u32 max_iterations = 10;
+ u32 wait_counter = 0;
+
+ do {
+ val = readl(dbi_base + PCIE_PHY_STAT);
+ val = (val >> PCIE_PHY_STAT_ACK_LOC) & 0x1;
+ wait_counter++;
+
+ if (val == exp_val)
+ return 0;
+
+ udelay(1);
+ } while ((wait_counter < max_iterations) && (val != exp_val));
+
+ return -ETIMEDOUT;
+}
+
+static int pcie_phy_wait_ack(void __iomem *dbi_base, int addr)
+{
+ u32 val;
+ int ret;
+
+ val = addr << PCIE_PHY_CTRL_DATA_LOC;
+ writel(val, dbi_base + PCIE_PHY_CTRL);
+
+ val |= (0x1 << PCIE_PHY_CTRL_CAP_ADR_LOC);
+ writel(val, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ val = addr << PCIE_PHY_CTRL_DATA_LOC;
+ writel(val, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+/* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */
+static int pcie_phy_read(void __iomem *dbi_base, int addr , int *data)
+{
+ u32 val, phy_ctl;
+ int ret;
+
+ ret = pcie_phy_wait_ack(dbi_base, addr);
+ if (ret)
+ return ret;
+
+ /* assert Read signal */
+ phy_ctl = 0x1 << PCIE_PHY_CTRL_RD_LOC;
+ writel(phy_ctl, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ val = readl(dbi_base + PCIE_PHY_STAT);
+ *data = val & 0xffff;
+
+ /* deassert Read signal */
+ writel(0x00, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int pcie_phy_write(void __iomem *dbi_base, int addr, int data)
+{
+ u32 var;
+ int ret;
+
+ /* write addr */
+ /* cap addr */
+ ret = pcie_phy_wait_ack(dbi_base, addr);
+ if (ret)
+ return ret;
+
+ var = data << PCIE_PHY_CTRL_DATA_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* capture data */
+ var |= (0x1 << PCIE_PHY_CTRL_CAP_DAT_LOC);
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ /* deassert cap data */
+ var = data << PCIE_PHY_CTRL_DATA_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* wait for ack de-assetion */
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ /* assert wr signal */
+ var = 0x1 << PCIE_PHY_CTRL_WR_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* wait for ack */
+ ret = pcie_phy_poll_ack(dbi_base, 1);
+ if (ret)
+ return ret;
+
+ /* deassert wr signal */
+ var = data << PCIE_PHY_CTRL_DATA_LOC;
+ writel(var, dbi_base + PCIE_PHY_CTRL);
+
+ /* wait for ack de-assetion */
+ ret = pcie_phy_poll_ack(dbi_base, 0);
+ if (ret)
+ return ret;
+
+ writel(0x0, dbi_base + PCIE_PHY_CTRL);
+
+ return 0;
+}
+
+/* Added for PCI abort handling */
+static int imx6q_pcie_abort_handler(unsigned long addr,
+ unsigned int fsr, struct pt_regs *regs)
+{
+ /*
+ * If it was an imprecise abort, then we need to correct the
+ * return address to be _after_ the instruction.
+ */
+ if (fsr & (1 << 10))
+ regs->ARM_pc += 4;
+ return 0;
+}
+
+static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
+{
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
+
+ gpio_set_value(imx6_pcie->reset_gpio, 0);
+ msleep(100);
+ gpio_set_value(imx6_pcie->reset_gpio, 1);
+
+ return 0;
+}
+
+static int imx6_pcie_deassert_core_reset(struct pcie_port *pp)
+{
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+ int ret;
+
+ if (gpio_is_valid(imx6_pcie->power_on_gpio))
+ gpio_set_value(imx6_pcie->power_on_gpio, 1);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+ IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
+
+ ret = clk_prepare_enable(imx6_pcie->sata_ref_100m);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable sata_ref_100m\n");
+ goto err_sata_ref;
+ }
+
+ ret = clk_prepare_enable(imx6_pcie->pcie_ref_125m);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable pcie_ref_125m\n");
+ goto err_pcie_ref;
+ }
+
+ ret = clk_prepare_enable(imx6_pcie->lvds_gate);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable lvds_gate\n");
+ goto err_lvds_gate;
+ }
+
+ ret = clk_prepare_enable(imx6_pcie->pcie_axi);
+ if (ret) {
+ dev_err(pp->dev, "unable to enable pcie_axi\n");
+ goto err_pcie_axi;
+ }
+
+ /* allow the clocks to stabilize */
+ usleep_range(200, 500);
+
+ return 0;
+
+err_pcie_axi:
+ clk_disable_unprepare(imx6_pcie->lvds_gate);
+err_lvds_gate:
+ clk_disable_unprepare(imx6_pcie->pcie_ref_125m);
+err_pcie_ref:
+ clk_disable_unprepare(imx6_pcie->sata_ref_100m);
+err_sata_ref:
+ return ret;
+
+}
+
+static void imx6_pcie_init_phy(struct pcie_port *pp)
+{
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
+
+ /* configure constant input signal to the pcie ctrl and phy */
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_DEVICE_TYPE, PCI_EXP_TYPE_ROOT_PORT << 12);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN1, 0 << 0);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB, 0 << 6);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB, 20 << 12);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_SWING_FULL, 127 << 18);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_SWING_LOW, 127 << 25);
+}
+
+static void imx6_pcie_host_init(struct pcie_port *pp)
+{
+ int count = 0;
+ struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+
+ imx6_pcie_assert_core_reset(pp);
+
+ imx6_pcie_init_phy(pp);
+
+ imx6_pcie_deassert_core_reset(pp);
+
+ dw_pcie_setup_rc(pp);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
+
+ while (!dw_pcie_link_up(pp)) {
+ usleep_range(100, 1000);
+ count++;
+ if (count >= 10) {
+ dev_err(pp->dev, "phy link never came up\n");
+ dev_dbg(pp->dev,
+ "DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
+ readl(pp->dbi_base + PCIE_PHY_DEBUG_R0),
+ readl(pp->dbi_base + PCIE_PHY_DEBUG_R1));
+ break;
+ }
+ }
+
+ return;
+}
+
+static int imx6_pcie_link_up(struct pcie_port *pp)
+{
+ u32 rc, ltssm, rx_valid, temp;
+
+ /* link is debug bit 36, debug register 1 starts at bit 32 */
+ rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
+ if (rc)
+ return -EAGAIN;
+
+ /*
+ * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
+ * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
+ * If (MAC/LTSSM.state == Recovery.RcvrLock)
+ * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
+ * to gen2 is stuck
+ */
+ pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
+ ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
+
+ if (rx_valid & 0x01)
+ return 0;
+
+ if (ltssm != 0x0d)
+ return 0;
+
+ dev_err(pp->dev,
+ "transition to gen2 is stuck, reset PHY!\n");
+
+ pcie_phy_read(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, &temp);
+ temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
+ | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
+ pcie_phy_write(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, temp);
+
+ usleep_range(2000, 3000);
+
+ pcie_phy_read(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, &temp);
+ temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
+ | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
+ pcie_phy_write(pp->dbi_base,
+ PHY_RX_OVRD_IN_LO, temp);
+
+ return 0;
+}
+
+static struct pcie_host_ops imx6_pcie_host_ops = {
+ .link_up = imx6_pcie_link_up,
+ .host_init = imx6_pcie_host_init,
+};
+
+static int imx6_add_pcie_port(struct pcie_port *pp,
+ struct platform_device *pdev)
+{
+ int ret;
+
+ pp->irq = platform_get_irq(pdev, 0);
+ if (!pp->irq) {
+ dev_err(&pdev->dev, "failed to get irq\n");
+ return -ENODEV;
+ }
+
+ pp->root_bus_nr = -1;
+ pp->ops = &imx6_pcie_host_ops;
+
+ spin_lock_init(&pp->conf_lock);
+ ret = dw_pcie_host_init(pp);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to initialize host\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __init imx6_pcie_probe(struct platform_device *pdev)
+{
+ struct imx6_pcie *imx6_pcie;
+ struct pcie_port *pp;
+ struct device_node *np = pdev->dev.of_node;
+ struct resource *dbi_base;
+ int ret;
+
+ imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
+ if (!imx6_pcie)
+ return -ENOMEM;
+
+ pp = &imx6_pcie->pp;
+ pp->dev = &pdev->dev;
+
+ /* Added for PCI abort handling */
+ hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
+ "imprecise external abort");
+
+ dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!dbi_base) {
+ dev_err(&pdev->dev, "dbi_base memory resource not found\n");
+ return -ENODEV;
+ }
+
+ pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
+ if (IS_ERR(pp->dbi_base)) {
+ dev_err(&pdev->dev, "unable to remap dbi_base\n");
+ ret = PTR_ERR(pp->dbi_base);
+ goto err;
+ }
+
+ /* Fetch GPIOs */
+ imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
+ if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
+ dev_err(&pdev->dev, "no reset-gpio defined\n");
+ ret = -ENODEV;
+ }
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->reset_gpio,
+ GPIOF_OUT_INIT_LOW,
+ "PCIe reset");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get reset gpio\n");
+ goto err;
+ }
+
+ imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
+ if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->power_on_gpio,
+ GPIOF_OUT_INIT_LOW,
+ "PCIe power enable");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get power-on gpio\n");
+ goto err;
+ }
+ }
+
+ imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
+ if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->wake_up_gpio,
+ GPIOF_IN,
+ "PCIe wake up");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get wake-up gpio\n");
+ goto err;
+ }
+ }
+
+ imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
+ if (gpio_is_valid(imx6_pcie->disable_gpio)) {
+ ret = devm_gpio_request_one(&pdev->dev,
+ imx6_pcie->disable_gpio,
+ GPIOF_OUT_INIT_HIGH,
+ "PCIe disable endpoint");
+ if (ret) {
+ dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
+ goto err;
+ }
+ }
+
+ /* Fetch clocks */
+ imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
+ if (IS_ERR(imx6_pcie->lvds_gate)) {
+ dev_err(&pdev->dev,
+ "lvds_gate clock select missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->lvds_gate);
+ goto err;
+ }
+
+ imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
+ if (IS_ERR(imx6_pcie->sata_ref_100m)) {
+ dev_err(&pdev->dev,
+ "sata_ref_100m clock source missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->sata_ref_100m);
+ goto err;
+ }
+
+ imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
+ if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
+ dev_err(&pdev->dev,
+ "pcie_ref_125m clock source missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
+ goto err;
+ }
+
+ imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
+ if (IS_ERR(imx6_pcie->pcie_axi)) {
+ dev_err(&pdev->dev,
+ "pcie_axi clock source missing or invalid\n");
+ ret = PTR_ERR(imx6_pcie->pcie_axi);
+ goto err;
+ }
+
+ /* Grab GPR config register range */
+ imx6_pcie->iomuxc_gpr =
+ syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+ if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
+ dev_err(&pdev->dev, "unable to find iomuxc registers\n");
+ ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
+ goto err;
+ }
+
+ ret = imx6_add_pcie_port(pp, pdev);
+ if (ret < 0)
+ goto err;
+
+ platform_set_drvdata(pdev, imx6_pcie);
+ return 0;
+
+err:
+ return ret;
+}
+
+static const struct of_device_id imx6_pcie_of_match[] = {
+ { .compatible = "fsl,imx6q-pcie", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
+
+static struct platform_driver imx6_pcie_driver = {
+ .driver = {
+ .name = "imx6q-pcie",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(imx6_pcie_of_match),
+ },
+};
+
+/* Freescale PCIe driver does not allow module unload */
+
+static int __init imx6_init(void)
+{
+ return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
+}
+module_init(imx6_init);
+
+MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");
+MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 59+ messages in thread* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-16 8:20 ` Sean Cross
@ 2013-09-16 9:25 ` Sascha Hauer
-1 siblings, 0 replies; 59+ messages in thread
From: Sascha Hauer @ 2013-09-16 9:25 UTC (permalink / raw)
To: Sean Cross
Cc: devicetree, linux-pci, linux-arm-kernel, Zhu Richard-R65037,
Shawn Guo, tharvey, bhelgaas
On Mon, Sep 16, 2013 at 08:20:54AM +0000, Sean Cross wrote:
> Add support for the PCIe port present on the i.MX6 family of controllers.
> These use the Synopsis Designware core tied to their own PHY.
>
> +static int pcie_phy_poll_ack(void __iomem *dbi_base, int exp_val)
> +{
> + u32 val;
> + u32 max_iterations = 10;
> + u32 wait_counter = 0;
> +
> + do {
> + val = readl(dbi_base + PCIE_PHY_STAT);
> + val = (val >> PCIE_PHY_STAT_ACK_LOC) & 0x1;
> + wait_counter++;
> +
> + if (val == exp_val)
> + return 0;
> +
> + udelay(1);
> + } while ((wait_counter < max_iterations) && (val != exp_val));
The test for val != exp_val is unnecessary now of course.
With this and the devm_clk_get Shawn mentioned:
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-16 9:25 ` Sascha Hauer
0 siblings, 0 replies; 59+ messages in thread
From: Sascha Hauer @ 2013-09-16 9:25 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 16, 2013 at 08:20:54AM +0000, Sean Cross wrote:
> Add support for the PCIe port present on the i.MX6 family of controllers.
> These use the Synopsis Designware core tied to their own PHY.
>
> +static int pcie_phy_poll_ack(void __iomem *dbi_base, int exp_val)
> +{
> + u32 val;
> + u32 max_iterations = 10;
> + u32 wait_counter = 0;
> +
> + do {
> + val = readl(dbi_base + PCIE_PHY_STAT);
> + val = (val >> PCIE_PHY_STAT_ACK_LOC) & 0x1;
> + wait_counter++;
> +
> + if (val == exp_val)
> + return 0;
> +
> + udelay(1);
> + } while ((wait_counter < max_iterations) && (val != exp_val));
The test for val != exp_val is unnecessary now of course.
With this and the devm_clk_get Shawn mentioned:
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-16 8:20 ` Sean Cross
@ 2013-09-25 16:05 ` Frank Li
-1 siblings, 0 replies; 59+ messages in thread
From: Frank Li @ 2013-09-25 16:05 UTC (permalink / raw)
To: Sean Cross
Cc: devicetree, linux-pci, linux-arm-kernel@lists.infradead.org,
Zhu Richard-R65037, Sascha Hauer, bhelgaas, Shawn Guo, tharvey
On Mon, Sep 16, 2013 at 3:20 AM, Sean Cross <xobs@kosagi.com> wrote:
> Add support for the PCIe port present on the i.MX6 family of controllers.
> These use the Synopsis Designware core tied to their own PHY.
>
> Signed-off-by: Sean Cross <xobs@kosagi.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
What is the status of this patch, is it queued in next or need future change ?
Best regards
Frank Li
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-25 16:05 ` Frank Li
0 siblings, 0 replies; 59+ messages in thread
From: Frank Li @ 2013-09-25 16:05 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 16, 2013 at 3:20 AM, Sean Cross <xobs@kosagi.com> wrote:
> Add support for the PCIe port present on the i.MX6 family of controllers.
> These use the Synopsis Designware core tied to their own PHY.
>
> Signed-off-by: Sean Cross <xobs@kosagi.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
What is the status of this patch, is it queued in next or need future change ?
Best regards
Frank Li
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-16 8:20 ` Sean Cross
(?)
@ 2013-09-26 5:54 ` Tim Harvey
-1 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-09-26 5:54 UTC (permalink / raw)
To: Sean Cross
Cc: devicetree, linux-pci, linux-arm-kernel, Sascha Hauer,
Zhu Richard-R65037, Shawn Guo, bhelgaas
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 3d95048..efa24d9 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,12 @@ config PCI_EXYNOS
> select PCIEPORTBUS
> select PCIE_DW
>
> +config PCI_IMX6
> + bool "Freescale i.MX6 PCIe controller"
> + depends on SOC_IMX6Q
> + select PCIEPORTBUS
What is PCIEPORTBUS really for? When I enable this with a PCIe switch
off the root complex I get invalid IRQ messages during enumeration of
ports on the switch:
[ 6.572410] PCI: Device 0000:00:00.0 not available because of
resource collisi
[ 6.572433] pcieport: probe of 0000:00:00.0 failed with error -22
[ 6.572489] pcieport 0000:01:00.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS [ 6.572536] pcieport: probe of
0000:01:00.0 failed with error -22
[ 6.572593] pcieport 0000:02:01.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
[ 6.572621] PCI: enabling device 0000:02:01.0 (0140 -> 0143)
[ 6.572672] pcieport 0000:02:01.0: enabling bus mastering
[ 6.573045] pcieport 0000:02:04.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
if I remove PCIEPORTBUS these go away however cards behind the switch
don't operate correctly (I believe the interrupts do not get mapped
properly). Is there some logic perhaps missing in the driver required
for PCIe switches?
> +
> +/* Added for PCI abort handling */
> +static int imx6q_pcie_abort_handler(unsigned long addr,
> + unsigned int fsr, struct pt_regs *regs)
> +{
> + /*
> + * If it was an imprecise abort, then we need to correct the
> + * return address to be _after_ the instruction.
> + */
> + if (fsr & (1 << 10))
> + regs->ARM_pc += 4;
> + return 0;
> +}
> +
you added this per my request but after more testing I'm not sure now
it should be needed. On the i.MX6, imprecise aborts will occur when
an un-populated device behind a bridge is accessed. However somewhere
a few kernels back (3.9 I believe) this behavior changed such that the
aborts were not enabled/checked until the kernel completed init.
Therefore with the current kernel any un-populated device will cause a
single imprecise abort to be caught at the end of init and as such it
should be ignored 'without touching the PC'. I'm not clear if this
should happen - whatever enables the catching of the abort should
perhaps clear any pending flags I would think. I'm also not clear if
an abort handler should really be required as the current kernel has a
default handler that results in:
...
Freeing unused kernel memory: 6600K (80817000 - 80e89000)
Unhandled fault: imprecise external abort (0x1406) at 0xca8c0d71
...
Do we hook a handler that does nothing but 'return 0' just to
eliminate the Unhandled fault message?
> +static void imx6_pcie_host_init(struct pcie_port *pp)
> +{
> + int count = 0;
> + struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> +
> + imx6_pcie_assert_core_reset(pp);
> +
> + imx6_pcie_init_phy(pp);
> +
> + imx6_pcie_deassert_core_reset(pp);
> +
> + dw_pcie_setup_rc(pp);
> +
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> + IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
> +
> + while (!dw_pcie_link_up(pp)) {
> + usleep_range(100, 1000);
I've found that I needed to increase this delay in order for a link
detect with a PLX PEX8609 switch off the root complex. A
usleep_range(2000, 3000) worked in my testing.
> +static int imx6_pcie_link_up(struct pcie_port *pp)
> +{
> + u32 rc, ltssm, rx_valid, temp;
> +
> + /* link is debug bit 36, debug register 1 starts at bit 32 */
> + rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
> + if (rc)
> + return -EAGAIN;
I'm still having trouble accessing devices behind a PCIe switch in
3.12-rc2. Device enumeration goes fine however after kernel init it
seems that any access to a switch port fails the check for link in
dw_pcie_valid_config which calls imx6_pcie_link_up here. I'm
wondering if this is some ASPM issue (I've tried both with that
enabled and disabled). When I backport this driver to 3.11 I do not
see this behavior and can access config space of all devices behind
the bridge within userspace. Any ideas here?
Tim
>
> +
> + /*
> + * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> + * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
> + * If (MAC/LTSSM.state == Recovery.RcvrLock)
> + * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
> + * to gen2 is stuck
> + */
> + pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
> + ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
> +
> + if (rx_valid & 0x01)
> + return 0;
> +
> + if (ltssm != 0x0d)
> + return 0;
> +
> + dev_err(pp->dev,
> + "transition to gen2 is stuck, reset PHY!\n");
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + usleep_range(2000, 3000);
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + return 0;
> +}
> +
> +static struct pcie_host_ops imx6_pcie_host_ops = {
> + .link_up = imx6_pcie_link_up,
> + .host_init = imx6_pcie_host_init,
> +};
> +
> +static int imx6_add_pcie_port(struct pcie_port *pp,
> + struct platform_device *pdev)
> +{
> + int ret;
> +
> + pp->irq = platform_get_irq(pdev, 0);
> + if (!pp->irq) {
> + dev_err(&pdev->dev, "failed to get irq\n");
> + return -ENODEV;
> + }
> +
> + pp->root_bus_nr = -1;
> + pp->ops = &imx6_pcie_host_ops;
> +
> + spin_lock_init(&pp->conf_lock);
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init imx6_pcie_probe(struct platform_device *pdev)
> +{
> + struct imx6_pcie *imx6_pcie;
> + struct pcie_port *pp;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *dbi_base;
> + int ret;
> +
> + imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
> + if (!imx6_pcie)
> + return -ENOMEM;
> +
> + pp = &imx6_pcie->pp;
> + pp->dev = &pdev->dev;
> +
> + /* Added for PCI abort handling */
> + hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
> + "imprecise external abort");
> +
> + dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!dbi_base) {
> + dev_err(&pdev->dev, "dbi_base memory resource not found\n");
> + return -ENODEV;
> + }
> +
> + pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
> + if (IS_ERR(pp->dbi_base)) {
> + dev_err(&pdev->dev, "unable to remap dbi_base\n");
> + ret = PTR_ERR(pp->dbi_base);
> + goto err;
> + }
> +
> + /* Fetch GPIOs */
> + imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> + if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
> + dev_err(&pdev->dev, "no reset-gpio defined\n");
> + ret = -ENODEV;
> + }
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->reset_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe reset");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get reset gpio\n");
> + goto err;
> + }
> +
> + imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->power_on_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe power enable");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get power-on gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->wake_up_gpio,
> + GPIOF_IN,
> + "PCIe wake up");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get wake-up gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->disable_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->disable_gpio,
> + GPIOF_OUT_INIT_HIGH,
> + "PCIe disable endpoint");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
> + goto err;
> + }
> + }
> +
> + /* Fetch clocks */
> + imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
> + if (IS_ERR(imx6_pcie->lvds_gate)) {
> + dev_err(&pdev->dev,
> + "lvds_gate clock select missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->lvds_gate);
> + goto err;
> + }
> +
> + imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
> + if (IS_ERR(imx6_pcie->sata_ref_100m)) {
> + dev_err(&pdev->dev,
> + "sata_ref_100m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->sata_ref_100m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
> + if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
> + dev_err(&pdev->dev,
> + "pcie_ref_125m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
> + if (IS_ERR(imx6_pcie->pcie_axi)) {
> + dev_err(&pdev->dev,
> + "pcie_axi clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_axi);
> + goto err;
> + }
> +
> + /* Grab GPR config register range */
> + imx6_pcie->iomuxc_gpr =
> + syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
> + dev_err(&pdev->dev, "unable to find iomuxc registers\n");
> + ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
> + goto err;
> + }
> +
> + ret = imx6_add_pcie_port(pp, pdev);
> + if (ret < 0)
> + goto err;
> +
> + platform_set_drvdata(pdev, imx6_pcie);
> + return 0;
> +
> +err:
> + return ret;
> +}
> +
> +static const struct of_device_id imx6_pcie_of_match[] = {
> + { .compatible = "fsl,imx6q-pcie", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
> +
> +static struct platform_driver imx6_pcie_driver = {
> + .driver = {
> + .name = "imx6q-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(imx6_pcie_of_match),
> + },
> +};
> +
> +/* Freescale PCIe driver does not allow module unload */
> +
> +static int __init imx6_init(void)
> +{
> + return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
> +}
> +module_init(imx6_init);
> +
> +MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");
> +MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-26 5:54 ` Tim Harvey
0 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-09-26 5:54 UTC (permalink / raw)
To: Sean Cross
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sascha Hauer,
Zhu Richard-R65037, Shawn Guo, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 3d95048..efa24d9 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,12 @@ config PCI_EXYNOS
> select PCIEPORTBUS
> select PCIE_DW
>
> +config PCI_IMX6
> + bool "Freescale i.MX6 PCIe controller"
> + depends on SOC_IMX6Q
> + select PCIEPORTBUS
What is PCIEPORTBUS really for? When I enable this with a PCIe switch
off the root complex I get invalid IRQ messages during enumeration of
ports on the switch:
[ 6.572410] PCI: Device 0000:00:00.0 not available because of
resource collisi
[ 6.572433] pcieport: probe of 0000:00:00.0 failed with error -22
[ 6.572489] pcieport 0000:01:00.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS [ 6.572536] pcieport: probe of
0000:01:00.0 failed with error -22
[ 6.572593] pcieport 0000:02:01.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
[ 6.572621] PCI: enabling device 0000:02:01.0 (0140 -> 0143)
[ 6.572672] pcieport 0000:02:01.0: enabling bus mastering
[ 6.573045] pcieport 0000:02:04.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
if I remove PCIEPORTBUS these go away however cards behind the switch
don't operate correctly (I believe the interrupts do not get mapped
properly). Is there some logic perhaps missing in the driver required
for PCIe switches?
> +
> +/* Added for PCI abort handling */
> +static int imx6q_pcie_abort_handler(unsigned long addr,
> + unsigned int fsr, struct pt_regs *regs)
> +{
> + /*
> + * If it was an imprecise abort, then we need to correct the
> + * return address to be _after_ the instruction.
> + */
> + if (fsr & (1 << 10))
> + regs->ARM_pc += 4;
> + return 0;
> +}
> +
you added this per my request but after more testing I'm not sure now
it should be needed. On the i.MX6, imprecise aborts will occur when
an un-populated device behind a bridge is accessed. However somewhere
a few kernels back (3.9 I believe) this behavior changed such that the
aborts were not enabled/checked until the kernel completed init.
Therefore with the current kernel any un-populated device will cause a
single imprecise abort to be caught at the end of init and as such it
should be ignored 'without touching the PC'. I'm not clear if this
should happen - whatever enables the catching of the abort should
perhaps clear any pending flags I would think. I'm also not clear if
an abort handler should really be required as the current kernel has a
default handler that results in:
...
Freeing unused kernel memory: 6600K (80817000 - 80e89000)
Unhandled fault: imprecise external abort (0x1406) at 0xca8c0d71
...
Do we hook a handler that does nothing but 'return 0' just to
eliminate the Unhandled fault message?
> +static void imx6_pcie_host_init(struct pcie_port *pp)
> +{
> + int count = 0;
> + struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> +
> + imx6_pcie_assert_core_reset(pp);
> +
> + imx6_pcie_init_phy(pp);
> +
> + imx6_pcie_deassert_core_reset(pp);
> +
> + dw_pcie_setup_rc(pp);
> +
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> + IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
> +
> + while (!dw_pcie_link_up(pp)) {
> + usleep_range(100, 1000);
I've found that I needed to increase this delay in order for a link
detect with a PLX PEX8609 switch off the root complex. A
usleep_range(2000, 3000) worked in my testing.
> +static int imx6_pcie_link_up(struct pcie_port *pp)
> +{
> + u32 rc, ltssm, rx_valid, temp;
> +
> + /* link is debug bit 36, debug register 1 starts at bit 32 */
> + rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
> + if (rc)
> + return -EAGAIN;
I'm still having trouble accessing devices behind a PCIe switch in
3.12-rc2. Device enumeration goes fine however after kernel init it
seems that any access to a switch port fails the check for link in
dw_pcie_valid_config which calls imx6_pcie_link_up here. I'm
wondering if this is some ASPM issue (I've tried both with that
enabled and disabled). When I backport this driver to 3.11 I do not
see this behavior and can access config space of all devices behind
the bridge within userspace. Any ideas here?
Tim
>
> +
> + /*
> + * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> + * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
> + * If (MAC/LTSSM.state == Recovery.RcvrLock)
> + * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
> + * to gen2 is stuck
> + */
> + pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
> + ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
> +
> + if (rx_valid & 0x01)
> + return 0;
> +
> + if (ltssm != 0x0d)
> + return 0;
> +
> + dev_err(pp->dev,
> + "transition to gen2 is stuck, reset PHY!\n");
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + usleep_range(2000, 3000);
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + return 0;
> +}
> +
> +static struct pcie_host_ops imx6_pcie_host_ops = {
> + .link_up = imx6_pcie_link_up,
> + .host_init = imx6_pcie_host_init,
> +};
> +
> +static int imx6_add_pcie_port(struct pcie_port *pp,
> + struct platform_device *pdev)
> +{
> + int ret;
> +
> + pp->irq = platform_get_irq(pdev, 0);
> + if (!pp->irq) {
> + dev_err(&pdev->dev, "failed to get irq\n");
> + return -ENODEV;
> + }
> +
> + pp->root_bus_nr = -1;
> + pp->ops = &imx6_pcie_host_ops;
> +
> + spin_lock_init(&pp->conf_lock);
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init imx6_pcie_probe(struct platform_device *pdev)
> +{
> + struct imx6_pcie *imx6_pcie;
> + struct pcie_port *pp;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *dbi_base;
> + int ret;
> +
> + imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
> + if (!imx6_pcie)
> + return -ENOMEM;
> +
> + pp = &imx6_pcie->pp;
> + pp->dev = &pdev->dev;
> +
> + /* Added for PCI abort handling */
> + hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
> + "imprecise external abort");
> +
> + dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!dbi_base) {
> + dev_err(&pdev->dev, "dbi_base memory resource not found\n");
> + return -ENODEV;
> + }
> +
> + pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
> + if (IS_ERR(pp->dbi_base)) {
> + dev_err(&pdev->dev, "unable to remap dbi_base\n");
> + ret = PTR_ERR(pp->dbi_base);
> + goto err;
> + }
> +
> + /* Fetch GPIOs */
> + imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> + if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
> + dev_err(&pdev->dev, "no reset-gpio defined\n");
> + ret = -ENODEV;
> + }
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->reset_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe reset");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get reset gpio\n");
> + goto err;
> + }
> +
> + imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->power_on_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe power enable");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get power-on gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->wake_up_gpio,
> + GPIOF_IN,
> + "PCIe wake up");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get wake-up gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->disable_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->disable_gpio,
> + GPIOF_OUT_INIT_HIGH,
> + "PCIe disable endpoint");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
> + goto err;
> + }
> + }
> +
> + /* Fetch clocks */
> + imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
> + if (IS_ERR(imx6_pcie->lvds_gate)) {
> + dev_err(&pdev->dev,
> + "lvds_gate clock select missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->lvds_gate);
> + goto err;
> + }
> +
> + imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
> + if (IS_ERR(imx6_pcie->sata_ref_100m)) {
> + dev_err(&pdev->dev,
> + "sata_ref_100m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->sata_ref_100m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
> + if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
> + dev_err(&pdev->dev,
> + "pcie_ref_125m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
> + if (IS_ERR(imx6_pcie->pcie_axi)) {
> + dev_err(&pdev->dev,
> + "pcie_axi clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_axi);
> + goto err;
> + }
> +
> + /* Grab GPR config register range */
> + imx6_pcie->iomuxc_gpr =
> + syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
> + dev_err(&pdev->dev, "unable to find iomuxc registers\n");
> + ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
> + goto err;
> + }
> +
> + ret = imx6_add_pcie_port(pp, pdev);
> + if (ret < 0)
> + goto err;
> +
> + platform_set_drvdata(pdev, imx6_pcie);
> + return 0;
> +
> +err:
> + return ret;
> +}
> +
> +static const struct of_device_id imx6_pcie_of_match[] = {
> + { .compatible = "fsl,imx6q-pcie", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
> +
> +static struct platform_driver imx6_pcie_driver = {
> + .driver = {
> + .name = "imx6q-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(imx6_pcie_of_match),
> + },
> +};
> +
> +/* Freescale PCIe driver does not allow module unload */
> +
> +static int __init imx6_init(void)
> +{
> + return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
> +}
> +module_init(imx6_init);
> +
> +MODULE_AUTHOR("Sean Cross <xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>");
> +MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-26 5:54 ` Tim Harvey
0 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-09-26 5:54 UTC (permalink / raw)
To: linux-arm-kernel
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 3d95048..efa24d9 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,12 @@ config PCI_EXYNOS
> select PCIEPORTBUS
> select PCIE_DW
>
> +config PCI_IMX6
> + bool "Freescale i.MX6 PCIe controller"
> + depends on SOC_IMX6Q
> + select PCIEPORTBUS
What is PCIEPORTBUS really for? When I enable this with a PCIe switch
off the root complex I get invalid IRQ messages during enumeration of
ports on the switch:
[ 6.572410] PCI: Device 0000:00:00.0 not available because of
resource collisi
[ 6.572433] pcieport: probe of 0000:00:00.0 failed with error -22
[ 6.572489] pcieport 0000:01:00.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS [ 6.572536] pcieport: probe of
0000:01:00.0 failed with error -22
[ 6.572593] pcieport 0000:02:01.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
[ 6.572621] PCI: enabling device 0000:02:01.0 (0140 -> 0143)
[ 6.572672] pcieport 0000:02:01.0: enabling bus mastering
[ 6.573045] pcieport 0000:02:04.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
if I remove PCIEPORTBUS these go away however cards behind the switch
don't operate correctly (I believe the interrupts do not get mapped
properly). Is there some logic perhaps missing in the driver required
for PCIe switches?
> +
> +/* Added for PCI abort handling */
> +static int imx6q_pcie_abort_handler(unsigned long addr,
> + unsigned int fsr, struct pt_regs *regs)
> +{
> + /*
> + * If it was an imprecise abort, then we need to correct the
> + * return address to be _after_ the instruction.
> + */
> + if (fsr & (1 << 10))
> + regs->ARM_pc += 4;
> + return 0;
> +}
> +
you added this per my request but after more testing I'm not sure now
it should be needed. On the i.MX6, imprecise aborts will occur when
an un-populated device behind a bridge is accessed. However somewhere
a few kernels back (3.9 I believe) this behavior changed such that the
aborts were not enabled/checked until the kernel completed init.
Therefore with the current kernel any un-populated device will cause a
single imprecise abort to be caught at the end of init and as such it
should be ignored 'without touching the PC'. I'm not clear if this
should happen - whatever enables the catching of the abort should
perhaps clear any pending flags I would think. I'm also not clear if
an abort handler should really be required as the current kernel has a
default handler that results in:
...
Freeing unused kernel memory: 6600K (80817000 - 80e89000)
Unhandled fault: imprecise external abort (0x1406) at 0xca8c0d71
...
Do we hook a handler that does nothing but 'return 0' just to
eliminate the Unhandled fault message?
> +static void imx6_pcie_host_init(struct pcie_port *pp)
> +{
> + int count = 0;
> + struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> +
> + imx6_pcie_assert_core_reset(pp);
> +
> + imx6_pcie_init_phy(pp);
> +
> + imx6_pcie_deassert_core_reset(pp);
> +
> + dw_pcie_setup_rc(pp);
> +
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> + IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
> +
> + while (!dw_pcie_link_up(pp)) {
> + usleep_range(100, 1000);
I've found that I needed to increase this delay in order for a link
detect with a PLX PEX8609 switch off the root complex. A
usleep_range(2000, 3000) worked in my testing.
> +static int imx6_pcie_link_up(struct pcie_port *pp)
> +{
> + u32 rc, ltssm, rx_valid, temp;
> +
> + /* link is debug bit 36, debug register 1 starts at bit 32 */
> + rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
> + if (rc)
> + return -EAGAIN;
I'm still having trouble accessing devices behind a PCIe switch in
3.12-rc2. Device enumeration goes fine however after kernel init it
seems that any access to a switch port fails the check for link in
dw_pcie_valid_config which calls imx6_pcie_link_up here. I'm
wondering if this is some ASPM issue (I've tried both with that
enabled and disabled). When I backport this driver to 3.11 I do not
see this behavior and can access config space of all devices behind
the bridge within userspace. Any ideas here?
Tim
>
> +
> + /*
> + * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> + * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
> + * If (MAC/LTSSM.state == Recovery.RcvrLock)
> + * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
> + * to gen2 is stuck
> + */
> + pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
> + ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
> +
> + if (rx_valid & 0x01)
> + return 0;
> +
> + if (ltssm != 0x0d)
> + return 0;
> +
> + dev_err(pp->dev,
> + "transition to gen2 is stuck, reset PHY!\n");
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + usleep_range(2000, 3000);
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + return 0;
> +}
> +
> +static struct pcie_host_ops imx6_pcie_host_ops = {
> + .link_up = imx6_pcie_link_up,
> + .host_init = imx6_pcie_host_init,
> +};
> +
> +static int imx6_add_pcie_port(struct pcie_port *pp,
> + struct platform_device *pdev)
> +{
> + int ret;
> +
> + pp->irq = platform_get_irq(pdev, 0);
> + if (!pp->irq) {
> + dev_err(&pdev->dev, "failed to get irq\n");
> + return -ENODEV;
> + }
> +
> + pp->root_bus_nr = -1;
> + pp->ops = &imx6_pcie_host_ops;
> +
> + spin_lock_init(&pp->conf_lock);
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init imx6_pcie_probe(struct platform_device *pdev)
> +{
> + struct imx6_pcie *imx6_pcie;
> + struct pcie_port *pp;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *dbi_base;
> + int ret;
> +
> + imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
> + if (!imx6_pcie)
> + return -ENOMEM;
> +
> + pp = &imx6_pcie->pp;
> + pp->dev = &pdev->dev;
> +
> + /* Added for PCI abort handling */
> + hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
> + "imprecise external abort");
> +
> + dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!dbi_base) {
> + dev_err(&pdev->dev, "dbi_base memory resource not found\n");
> + return -ENODEV;
> + }
> +
> + pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
> + if (IS_ERR(pp->dbi_base)) {
> + dev_err(&pdev->dev, "unable to remap dbi_base\n");
> + ret = PTR_ERR(pp->dbi_base);
> + goto err;
> + }
> +
> + /* Fetch GPIOs */
> + imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> + if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
> + dev_err(&pdev->dev, "no reset-gpio defined\n");
> + ret = -ENODEV;
> + }
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->reset_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe reset");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get reset gpio\n");
> + goto err;
> + }
> +
> + imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->power_on_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe power enable");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get power-on gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->wake_up_gpio,
> + GPIOF_IN,
> + "PCIe wake up");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get wake-up gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->disable_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->disable_gpio,
> + GPIOF_OUT_INIT_HIGH,
> + "PCIe disable endpoint");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
> + goto err;
> + }
> + }
> +
> + /* Fetch clocks */
> + imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
> + if (IS_ERR(imx6_pcie->lvds_gate)) {
> + dev_err(&pdev->dev,
> + "lvds_gate clock select missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->lvds_gate);
> + goto err;
> + }
> +
> + imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
> + if (IS_ERR(imx6_pcie->sata_ref_100m)) {
> + dev_err(&pdev->dev,
> + "sata_ref_100m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->sata_ref_100m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
> + if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
> + dev_err(&pdev->dev,
> + "pcie_ref_125m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
> + if (IS_ERR(imx6_pcie->pcie_axi)) {
> + dev_err(&pdev->dev,
> + "pcie_axi clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_axi);
> + goto err;
> + }
> +
> + /* Grab GPR config register range */
> + imx6_pcie->iomuxc_gpr =
> + syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
> + dev_err(&pdev->dev, "unable to find iomuxc registers\n");
> + ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
> + goto err;
> + }
> +
> + ret = imx6_add_pcie_port(pp, pdev);
> + if (ret < 0)
> + goto err;
> +
> + platform_set_drvdata(pdev, imx6_pcie);
> + return 0;
> +
> +err:
> + return ret;
> +}
> +
> +static const struct of_device_id imx6_pcie_of_match[] = {
> + { .compatible = "fsl,imx6q-pcie", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
> +
> +static struct platform_driver imx6_pcie_driver = {
> + .driver = {
> + .name = "imx6q-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(imx6_pcie_of_match),
> + },
> +};
> +
> +/* Freescale PCIe driver does not allow module unload */
> +
> +static int __init imx6_init(void)
> +{
> + return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
> +}
> +module_init(imx6_init);
> +
> +MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");
> +MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>
^ permalink raw reply [flat|nested] 59+ messages in thread* RE: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-26 5:54 ` Tim Harvey
(?)
@ 2013-09-27 1:38 ` Zhu Richard-R65037
-1 siblings, 0 replies; 59+ messages in thread
From: Zhu Richard-R65037 @ 2013-09-27 1:38 UTC (permalink / raw)
To: Tim Harvey, Sean Cross
Cc: devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Sascha Hauer, Shawn Guo,
bhelgaas@google.com
Hi Tim:
Thanks for your tests.
Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
is ok on FSL imx_3.0.35 kernels.
I'm debugging this issue now, and would summit the patches asap.
Best Regards
Richard Zhu
-----Original Message-----
From: Tim Harvey [mailto:tharvey@gateworks.com]
Sent: Thursday, September 26, 2013 1:54 PM
To: Sean Cross
Cc: devicetree@vger.kernel.org; linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Sascha Hauer; Zhu Richard-R65037; Shawn Guo; bhelgaas@google.com
Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index
> 3d95048..efa24d9 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,12 @@ config PCI_EXYNOS
> select PCIEPORTBUS
> select PCIE_DW
>
> +config PCI_IMX6
> + bool "Freescale i.MX6 PCIe controller"
> + depends on SOC_IMX6Q
> + select PCIEPORTBUS
What is PCIEPORTBUS really for? When I enable this with a PCIe switch off the root complex I get invalid IRQ messages during enumeration of ports on the switch:
[ 6.572410] PCI: Device 0000:00:00.0 not available because of
resource collisi
[ 6.572433] pcieport: probe of 0000:00:00.0 failed with error -22
[ 6.572489] pcieport 0000:01:00.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS [ 6.572536] pcieport: probe of
0000:01:00.0 failed with error -22
[ 6.572593] pcieport 0000:02:01.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
[ 6.572621] PCI: enabling device 0000:02:01.0 (0140 -> 0143)
[ 6.572672] pcieport 0000:02:01.0: enabling bus mastering
[ 6.573045] pcieport 0000:02:04.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
if I remove PCIEPORTBUS these go away however cards behind the switch don't operate correctly (I believe the interrupts do not get mapped properly). Is there some logic perhaps missing in the driver required for PCIe switches?
> +
> +/* Added for PCI abort handling */
> +static int imx6q_pcie_abort_handler(unsigned long addr,
> + unsigned int fsr, struct pt_regs *regs) {
> + /*
> + * If it was an imprecise abort, then we need to correct the
> + * return address to be _after_ the instruction.
> + */
> + if (fsr & (1 << 10))
> + regs->ARM_pc += 4;
> + return 0;
> +}
> +
you added this per my request but after more testing I'm not sure now it should be needed. On the i.MX6, imprecise aborts will occur when an un-populated device behind a bridge is accessed. However somewhere a few kernels back (3.9 I believe) this behavior changed such that the aborts were not enabled/checked until the kernel completed init.
Therefore with the current kernel any un-populated device will cause a single imprecise abort to be caught at the end of init and as such it should be ignored 'without touching the PC'. I'm not clear if this should happen - whatever enables the catching of the abort should perhaps clear any pending flags I would think. I'm also not clear if an abort handler should really be required as the current kernel has a default handler that results in:
...
Freeing unused kernel memory: 6600K (80817000 - 80e89000) Unhandled fault: imprecise external abort (0x1406) at 0xca8c0d71 ...
Do we hook a handler that does nothing but 'return 0' just to eliminate the Unhandled fault message?
> +static void imx6_pcie_host_init(struct pcie_port *pp) {
> + int count = 0;
> + struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> +
> + imx6_pcie_assert_core_reset(pp);
> +
> + imx6_pcie_init_phy(pp);
> +
> + imx6_pcie_deassert_core_reset(pp);
> +
> + dw_pcie_setup_rc(pp);
> +
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> + IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
> +
> + while (!dw_pcie_link_up(pp)) {
> + usleep_range(100, 1000);
I've found that I needed to increase this delay in order for a link detect with a PLX PEX8609 switch off the root complex. A usleep_range(2000, 3000) worked in my testing.
> +static int imx6_pcie_link_up(struct pcie_port *pp) {
> + u32 rc, ltssm, rx_valid, temp;
> +
> + /* link is debug bit 36, debug register 1 starts at bit 32 */
> + rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
> + if (rc)
> + return -EAGAIN;
I'm still having trouble accessing devices behind a PCIe switch in 3.12-rc2. Device enumeration goes fine however after kernel init it seems that any access to a switch port fails the check for link in dw_pcie_valid_config which calls imx6_pcie_link_up here. I'm wondering if this is some ASPM issue (I've tried both with that enabled and disabled). When I backport this driver to 3.11 I do not see this behavior and can access config space of all devices behind the bridge within userspace. Any ideas here?
Tim
>
> +
> + /*
> + * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> + * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
> + * If (MAC/LTSSM.state == Recovery.RcvrLock)
> + * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
> + * to gen2 is stuck
> + */
> + pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
> + ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
> +
> + if (rx_valid & 0x01)
> + return 0;
> +
> + if (ltssm != 0x0d)
> + return 0;
> +
> + dev_err(pp->dev,
> + "transition to gen2 is stuck, reset PHY!\n");
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + usleep_range(2000, 3000);
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + return 0;
> +}
> +
> +static struct pcie_host_ops imx6_pcie_host_ops = {
> + .link_up = imx6_pcie_link_up,
> + .host_init = imx6_pcie_host_init, };
> +
> +static int imx6_add_pcie_port(struct pcie_port *pp,
> + struct platform_device *pdev) {
> + int ret;
> +
> + pp->irq = platform_get_irq(pdev, 0);
> + if (!pp->irq) {
> + dev_err(&pdev->dev, "failed to get irq\n");
> + return -ENODEV;
> + }
> +
> + pp->root_bus_nr = -1;
> + pp->ops = &imx6_pcie_host_ops;
> +
> + spin_lock_init(&pp->conf_lock);
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init imx6_pcie_probe(struct platform_device *pdev) {
> + struct imx6_pcie *imx6_pcie;
> + struct pcie_port *pp;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *dbi_base;
> + int ret;
> +
> + imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
> + if (!imx6_pcie)
> + return -ENOMEM;
> +
> + pp = &imx6_pcie->pp;
> + pp->dev = &pdev->dev;
> +
> + /* Added for PCI abort handling */
> + hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
> + "imprecise external abort");
> +
> + dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!dbi_base) {
> + dev_err(&pdev->dev, "dbi_base memory resource not found\n");
> + return -ENODEV;
> + }
> +
> + pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
> + if (IS_ERR(pp->dbi_base)) {
> + dev_err(&pdev->dev, "unable to remap dbi_base\n");
> + ret = PTR_ERR(pp->dbi_base);
> + goto err;
> + }
> +
> + /* Fetch GPIOs */
> + imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> + if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
> + dev_err(&pdev->dev, "no reset-gpio defined\n");
> + ret = -ENODEV;
> + }
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->reset_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe reset");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get reset gpio\n");
> + goto err;
> + }
> +
> + imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->power_on_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe power enable");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get power-on gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->wake_up_gpio,
> + GPIOF_IN,
> + "PCIe wake up");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get wake-up gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->disable_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->disable_gpio,
> + GPIOF_OUT_INIT_HIGH,
> + "PCIe disable endpoint");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
> + goto err;
> + }
> + }
> +
> + /* Fetch clocks */
> + imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
> + if (IS_ERR(imx6_pcie->lvds_gate)) {
> + dev_err(&pdev->dev,
> + "lvds_gate clock select missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->lvds_gate);
> + goto err;
> + }
> +
> + imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
> + if (IS_ERR(imx6_pcie->sata_ref_100m)) {
> + dev_err(&pdev->dev,
> + "sata_ref_100m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->sata_ref_100m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
> + if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
> + dev_err(&pdev->dev,
> + "pcie_ref_125m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
> + if (IS_ERR(imx6_pcie->pcie_axi)) {
> + dev_err(&pdev->dev,
> + "pcie_axi clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_axi);
> + goto err;
> + }
> +
> + /* Grab GPR config register range */
> + imx6_pcie->iomuxc_gpr =
> + syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
> + dev_err(&pdev->dev, "unable to find iomuxc registers\n");
> + ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
> + goto err;
> + }
> +
> + ret = imx6_add_pcie_port(pp, pdev);
> + if (ret < 0)
> + goto err;
> +
> + platform_set_drvdata(pdev, imx6_pcie);
> + return 0;
> +
> +err:
> + return ret;
> +}
> +
> +static const struct of_device_id imx6_pcie_of_match[] = {
> + { .compatible = "fsl,imx6q-pcie", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
> +
> +static struct platform_driver imx6_pcie_driver = {
> + .driver = {
> + .name = "imx6q-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(imx6_pcie_of_match),
> + },
> +};
> +
> +/* Freescale PCIe driver does not allow module unload */
> +
> +static int __init imx6_init(void)
> +{
> + return platform_driver_probe(&imx6_pcie_driver,
> +imx6_pcie_probe); } module_init(imx6_init);
> +
> +MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");
> +MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>
^ permalink raw reply [flat|nested] 59+ messages in thread* RE: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 1:38 ` Zhu Richard-R65037
0 siblings, 0 replies; 59+ messages in thread
From: Zhu Richard-R65037 @ 2013-09-27 1:38 UTC (permalink / raw)
To: Tim Harvey, Sean Cross
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer, Shawn Guo,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Hi Tim:
Thanks for your tests.
Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
is ok on FSL imx_3.0.35 kernels.
I'm debugging this issue now, and would summit the patches asap.
Best Regards
Richard Zhu
-----Original Message-----
From: Tim Harvey [mailto:tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org]
Sent: Thursday, September 26, 2013 1:54 PM
To: Sean Cross
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Sascha Hauer; Zhu Richard-R65037; Shawn Guo; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index
> 3d95048..efa24d9 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,12 @@ config PCI_EXYNOS
> select PCIEPORTBUS
> select PCIE_DW
>
> +config PCI_IMX6
> + bool "Freescale i.MX6 PCIe controller"
> + depends on SOC_IMX6Q
> + select PCIEPORTBUS
What is PCIEPORTBUS really for? When I enable this with a PCIe switch off the root complex I get invalid IRQ messages during enumeration of ports on the switch:
[ 6.572410] PCI: Device 0000:00:00.0 not available because of
resource collisi
[ 6.572433] pcieport: probe of 0000:00:00.0 failed with error -22
[ 6.572489] pcieport 0000:01:00.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS [ 6.572536] pcieport: probe of
0000:01:00.0 failed with error -22
[ 6.572593] pcieport 0000:02:01.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
[ 6.572621] PCI: enabling device 0000:02:01.0 (0140 -> 0143)
[ 6.572672] pcieport 0000:02:01.0: enabling bus mastering
[ 6.573045] pcieport 0000:02:04.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
if I remove PCIEPORTBUS these go away however cards behind the switch don't operate correctly (I believe the interrupts do not get mapped properly). Is there some logic perhaps missing in the driver required for PCIe switches?
> +
> +/* Added for PCI abort handling */
> +static int imx6q_pcie_abort_handler(unsigned long addr,
> + unsigned int fsr, struct pt_regs *regs) {
> + /*
> + * If it was an imprecise abort, then we need to correct the
> + * return address to be _after_ the instruction.
> + */
> + if (fsr & (1 << 10))
> + regs->ARM_pc += 4;
> + return 0;
> +}
> +
you added this per my request but after more testing I'm not sure now it should be needed. On the i.MX6, imprecise aborts will occur when an un-populated device behind a bridge is accessed. However somewhere a few kernels back (3.9 I believe) this behavior changed such that the aborts were not enabled/checked until the kernel completed init.
Therefore with the current kernel any un-populated device will cause a single imprecise abort to be caught at the end of init and as such it should be ignored 'without touching the PC'. I'm not clear if this should happen - whatever enables the catching of the abort should perhaps clear any pending flags I would think. I'm also not clear if an abort handler should really be required as the current kernel has a default handler that results in:
...
Freeing unused kernel memory: 6600K (80817000 - 80e89000) Unhandled fault: imprecise external abort (0x1406) at 0xca8c0d71 ...
Do we hook a handler that does nothing but 'return 0' just to eliminate the Unhandled fault message?
> +static void imx6_pcie_host_init(struct pcie_port *pp) {
> + int count = 0;
> + struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> +
> + imx6_pcie_assert_core_reset(pp);
> +
> + imx6_pcie_init_phy(pp);
> +
> + imx6_pcie_deassert_core_reset(pp);
> +
> + dw_pcie_setup_rc(pp);
> +
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> + IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
> +
> + while (!dw_pcie_link_up(pp)) {
> + usleep_range(100, 1000);
I've found that I needed to increase this delay in order for a link detect with a PLX PEX8609 switch off the root complex. A usleep_range(2000, 3000) worked in my testing.
> +static int imx6_pcie_link_up(struct pcie_port *pp) {
> + u32 rc, ltssm, rx_valid, temp;
> +
> + /* link is debug bit 36, debug register 1 starts at bit 32 */
> + rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
> + if (rc)
> + return -EAGAIN;
I'm still having trouble accessing devices behind a PCIe switch in 3.12-rc2. Device enumeration goes fine however after kernel init it seems that any access to a switch port fails the check for link in dw_pcie_valid_config which calls imx6_pcie_link_up here. I'm wondering if this is some ASPM issue (I've tried both with that enabled and disabled). When I backport this driver to 3.11 I do not see this behavior and can access config space of all devices behind the bridge within userspace. Any ideas here?
Tim
>
> +
> + /*
> + * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> + * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
> + * If (MAC/LTSSM.state == Recovery.RcvrLock)
> + * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
> + * to gen2 is stuck
> + */
> + pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
> + ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
> +
> + if (rx_valid & 0x01)
> + return 0;
> +
> + if (ltssm != 0x0d)
> + return 0;
> +
> + dev_err(pp->dev,
> + "transition to gen2 is stuck, reset PHY!\n");
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + usleep_range(2000, 3000);
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + return 0;
> +}
> +
> +static struct pcie_host_ops imx6_pcie_host_ops = {
> + .link_up = imx6_pcie_link_up,
> + .host_init = imx6_pcie_host_init, };
> +
> +static int imx6_add_pcie_port(struct pcie_port *pp,
> + struct platform_device *pdev) {
> + int ret;
> +
> + pp->irq = platform_get_irq(pdev, 0);
> + if (!pp->irq) {
> + dev_err(&pdev->dev, "failed to get irq\n");
> + return -ENODEV;
> + }
> +
> + pp->root_bus_nr = -1;
> + pp->ops = &imx6_pcie_host_ops;
> +
> + spin_lock_init(&pp->conf_lock);
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init imx6_pcie_probe(struct platform_device *pdev) {
> + struct imx6_pcie *imx6_pcie;
> + struct pcie_port *pp;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *dbi_base;
> + int ret;
> +
> + imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
> + if (!imx6_pcie)
> + return -ENOMEM;
> +
> + pp = &imx6_pcie->pp;
> + pp->dev = &pdev->dev;
> +
> + /* Added for PCI abort handling */
> + hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
> + "imprecise external abort");
> +
> + dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!dbi_base) {
> + dev_err(&pdev->dev, "dbi_base memory resource not found\n");
> + return -ENODEV;
> + }
> +
> + pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
> + if (IS_ERR(pp->dbi_base)) {
> + dev_err(&pdev->dev, "unable to remap dbi_base\n");
> + ret = PTR_ERR(pp->dbi_base);
> + goto err;
> + }
> +
> + /* Fetch GPIOs */
> + imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> + if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
> + dev_err(&pdev->dev, "no reset-gpio defined\n");
> + ret = -ENODEV;
> + }
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->reset_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe reset");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get reset gpio\n");
> + goto err;
> + }
> +
> + imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->power_on_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe power enable");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get power-on gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->wake_up_gpio,
> + GPIOF_IN,
> + "PCIe wake up");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get wake-up gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->disable_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->disable_gpio,
> + GPIOF_OUT_INIT_HIGH,
> + "PCIe disable endpoint");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
> + goto err;
> + }
> + }
> +
> + /* Fetch clocks */
> + imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
> + if (IS_ERR(imx6_pcie->lvds_gate)) {
> + dev_err(&pdev->dev,
> + "lvds_gate clock select missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->lvds_gate);
> + goto err;
> + }
> +
> + imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
> + if (IS_ERR(imx6_pcie->sata_ref_100m)) {
> + dev_err(&pdev->dev,
> + "sata_ref_100m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->sata_ref_100m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
> + if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
> + dev_err(&pdev->dev,
> + "pcie_ref_125m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
> + if (IS_ERR(imx6_pcie->pcie_axi)) {
> + dev_err(&pdev->dev,
> + "pcie_axi clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_axi);
> + goto err;
> + }
> +
> + /* Grab GPR config register range */
> + imx6_pcie->iomuxc_gpr =
> + syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
> + dev_err(&pdev->dev, "unable to find iomuxc registers\n");
> + ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
> + goto err;
> + }
> +
> + ret = imx6_add_pcie_port(pp, pdev);
> + if (ret < 0)
> + goto err;
> +
> + platform_set_drvdata(pdev, imx6_pcie);
> + return 0;
> +
> +err:
> + return ret;
> +}
> +
> +static const struct of_device_id imx6_pcie_of_match[] = {
> + { .compatible = "fsl,imx6q-pcie", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
> +
> +static struct platform_driver imx6_pcie_driver = {
> + .driver = {
> + .name = "imx6q-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(imx6_pcie_of_match),
> + },
> +};
> +
> +/* Freescale PCIe driver does not allow module unload */
> +
> +static int __init imx6_init(void)
> +{
> + return platform_driver_probe(&imx6_pcie_driver,
> +imx6_pcie_probe); } module_init(imx6_init);
> +
> +MODULE_AUTHOR("Sean Cross <xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>");
> +MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 1:38 ` Zhu Richard-R65037
0 siblings, 0 replies; 59+ messages in thread
From: Zhu Richard-R65037 @ 2013-09-27 1:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tim:
Thanks for your tests.
Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
is ok on FSL imx_3.0.35 kernels.
I'm debugging this issue now, and would summit the patches asap.
Best Regards
Richard Zhu
-----Original Message-----
From: Tim Harvey [mailto:tharvey at gateworks.com]
Sent: Thursday, September 26, 2013 1:54 PM
To: Sean Cross
Cc: devicetree at vger.kernel.org; linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Sascha Hauer; Zhu Richard-R65037; Shawn Guo; bhelgaas at google.com
Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index
> 3d95048..efa24d9 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,12 @@ config PCI_EXYNOS
> select PCIEPORTBUS
> select PCIE_DW
>
> +config PCI_IMX6
> + bool "Freescale i.MX6 PCIe controller"
> + depends on SOC_IMX6Q
> + select PCIEPORTBUS
What is PCIEPORTBUS really for? When I enable this with a PCIe switch off the root complex I get invalid IRQ messages during enumeration of ports on the switch:
[ 6.572410] PCI: Device 0000:00:00.0 not available because of
resource collisi
[ 6.572433] pcieport: probe of 0000:00:00.0 failed with error -22
[ 6.572489] pcieport 0000:01:00.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS [ 6.572536] pcieport: probe of
0000:01:00.0 failed with error -22
[ 6.572593] pcieport 0000:02:01.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
[ 6.572621] PCI: enabling device 0000:02:01.0 (0140 -> 0143)
[ 6.572672] pcieport 0000:02:01.0: enabling bus mastering
[ 6.573045] pcieport 0000:02:04.0: device [10b5:8609] has invalid
IRQ; check vendor BIOS
if I remove PCIEPORTBUS these go away however cards behind the switch don't operate correctly (I believe the interrupts do not get mapped properly). Is there some logic perhaps missing in the driver required for PCIe switches?
> +
> +/* Added for PCI abort handling */
> +static int imx6q_pcie_abort_handler(unsigned long addr,
> + unsigned int fsr, struct pt_regs *regs) {
> + /*
> + * If it was an imprecise abort, then we need to correct the
> + * return address to be _after_ the instruction.
> + */
> + if (fsr & (1 << 10))
> + regs->ARM_pc += 4;
> + return 0;
> +}
> +
you added this per my request but after more testing I'm not sure now it should be needed. On the i.MX6, imprecise aborts will occur when an un-populated device behind a bridge is accessed. However somewhere a few kernels back (3.9 I believe) this behavior changed such that the aborts were not enabled/checked until the kernel completed init.
Therefore with the current kernel any un-populated device will cause a single imprecise abort to be caught at the end of init and as such it should be ignored 'without touching the PC'. I'm not clear if this should happen - whatever enables the catching of the abort should perhaps clear any pending flags I would think. I'm also not clear if an abort handler should really be required as the current kernel has a default handler that results in:
...
Freeing unused kernel memory: 6600K (80817000 - 80e89000) Unhandled fault: imprecise external abort (0x1406) at 0xca8c0d71 ...
Do we hook a handler that does nothing but 'return 0' just to eliminate the Unhandled fault message?
> +static void imx6_pcie_host_init(struct pcie_port *pp) {
> + int count = 0;
> + struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> +
> + imx6_pcie_assert_core_reset(pp);
> +
> + imx6_pcie_init_phy(pp);
> +
> + imx6_pcie_deassert_core_reset(pp);
> +
> + dw_pcie_setup_rc(pp);
> +
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> + IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
> +
> + while (!dw_pcie_link_up(pp)) {
> + usleep_range(100, 1000);
I've found that I needed to increase this delay in order for a link detect with a PLX PEX8609 switch off the root complex. A usleep_range(2000, 3000) worked in my testing.
> +static int imx6_pcie_link_up(struct pcie_port *pp) {
> + u32 rc, ltssm, rx_valid, temp;
> +
> + /* link is debug bit 36, debug register 1 starts at bit 32 */
> + rc = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) & (0x1 << (36 - 32));
> + if (rc)
> + return -EAGAIN;
I'm still having trouble accessing devices behind a PCIe switch in 3.12-rc2. Device enumeration goes fine however after kernel init it seems that any access to a switch port fails the check for link in dw_pcie_valid_config which calls imx6_pcie_link_up here. I'm wondering if this is some ASPM issue (I've tried both with that enabled and disabled). When I backport this driver to 3.11 I do not see this behavior and can access config space of all devices behind the bridge within userspace. Any ideas here?
Tim
>
> +
> + /*
> + * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> + * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
> + * If (MAC/LTSSM.state == Recovery.RcvrLock)
> + * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
> + * to gen2 is stuck
> + */
> + pcie_phy_read(pp->dbi_base, PCIE_PHY_RX_ASIC_OUT, &rx_valid);
> + ltssm = readl(pp->dbi_base + PCIE_PHY_DEBUG_R0) & 0x3F;
> +
> + if (rx_valid & 0x01)
> + return 0;
> +
> + if (ltssm != 0x0d)
> + return 0;
> +
> + dev_err(pp->dev,
> + "transition to gen2 is stuck, reset PHY!\n");
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + usleep_range(2000, 3000);
> +
> + pcie_phy_read(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, &temp);
> + temp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN
> + | PHY_RX_OVRD_IN_LO_RX_PLL_EN);
> + pcie_phy_write(pp->dbi_base,
> + PHY_RX_OVRD_IN_LO, temp);
> +
> + return 0;
> +}
> +
> +static struct pcie_host_ops imx6_pcie_host_ops = {
> + .link_up = imx6_pcie_link_up,
> + .host_init = imx6_pcie_host_init, };
> +
> +static int imx6_add_pcie_port(struct pcie_port *pp,
> + struct platform_device *pdev) {
> + int ret;
> +
> + pp->irq = platform_get_irq(pdev, 0);
> + if (!pp->irq) {
> + dev_err(&pdev->dev, "failed to get irq\n");
> + return -ENODEV;
> + }
> +
> + pp->root_bus_nr = -1;
> + pp->ops = &imx6_pcie_host_ops;
> +
> + spin_lock_init(&pp->conf_lock);
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init imx6_pcie_probe(struct platform_device *pdev) {
> + struct imx6_pcie *imx6_pcie;
> + struct pcie_port *pp;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *dbi_base;
> + int ret;
> +
> + imx6_pcie = devm_kzalloc(&pdev->dev, sizeof(*imx6_pcie), GFP_KERNEL);
> + if (!imx6_pcie)
> + return -ENOMEM;
> +
> + pp = &imx6_pcie->pp;
> + pp->dev = &pdev->dev;
> +
> + /* Added for PCI abort handling */
> + hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
> + "imprecise external abort");
> +
> + dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!dbi_base) {
> + dev_err(&pdev->dev, "dbi_base memory resource not found\n");
> + return -ENODEV;
> + }
> +
> + pp->dbi_base = devm_ioremap_resource(&pdev->dev, dbi_base);
> + if (IS_ERR(pp->dbi_base)) {
> + dev_err(&pdev->dev, "unable to remap dbi_base\n");
> + ret = PTR_ERR(pp->dbi_base);
> + goto err;
> + }
> +
> + /* Fetch GPIOs */
> + imx6_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> + if (!gpio_is_valid(imx6_pcie->reset_gpio)) {
> + dev_err(&pdev->dev, "no reset-gpio defined\n");
> + ret = -ENODEV;
> + }
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->reset_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe reset");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get reset gpio\n");
> + goto err;
> + }
> +
> + imx6_pcie->power_on_gpio = of_get_named_gpio(np, "power-on-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->power_on_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->power_on_gpio,
> + GPIOF_OUT_INIT_LOW,
> + "PCIe power enable");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get power-on gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->wake_up_gpio = of_get_named_gpio(np, "wake-up-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->wake_up_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->wake_up_gpio,
> + GPIOF_IN,
> + "PCIe wake up");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get wake-up gpio\n");
> + goto err;
> + }
> + }
> +
> + imx6_pcie->disable_gpio = of_get_named_gpio(np, "disable-gpio", 0);
> + if (gpio_is_valid(imx6_pcie->disable_gpio)) {
> + ret = devm_gpio_request_one(&pdev->dev,
> + imx6_pcie->disable_gpio,
> + GPIOF_OUT_INIT_HIGH,
> + "PCIe disable endpoint");
> + if (ret) {
> + dev_err(&pdev->dev, "unable to get disable-ep gpio\n");
> + goto err;
> + }
> + }
> +
> + /* Fetch clocks */
> + imx6_pcie->lvds_gate = clk_get(&pdev->dev, "lvds_gate");
> + if (IS_ERR(imx6_pcie->lvds_gate)) {
> + dev_err(&pdev->dev,
> + "lvds_gate clock select missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->lvds_gate);
> + goto err;
> + }
> +
> + imx6_pcie->sata_ref_100m = clk_get(&pdev->dev, "sata_ref_100m");
> + if (IS_ERR(imx6_pcie->sata_ref_100m)) {
> + dev_err(&pdev->dev,
> + "sata_ref_100m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->sata_ref_100m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_ref_125m = clk_get(&pdev->dev, "pcie_ref_125m");
> + if (IS_ERR(imx6_pcie->pcie_ref_125m)) {
> + dev_err(&pdev->dev,
> + "pcie_ref_125m clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_ref_125m);
> + goto err;
> + }
> +
> + imx6_pcie->pcie_axi = clk_get(&pdev->dev, "pcie_axi");
> + if (IS_ERR(imx6_pcie->pcie_axi)) {
> + dev_err(&pdev->dev,
> + "pcie_axi clock source missing or invalid\n");
> + ret = PTR_ERR(imx6_pcie->pcie_axi);
> + goto err;
> + }
> +
> + /* Grab GPR config register range */
> + imx6_pcie->iomuxc_gpr =
> + syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
> + dev_err(&pdev->dev, "unable to find iomuxc registers\n");
> + ret = PTR_ERR(imx6_pcie->iomuxc_gpr);
> + goto err;
> + }
> +
> + ret = imx6_add_pcie_port(pp, pdev);
> + if (ret < 0)
> + goto err;
> +
> + platform_set_drvdata(pdev, imx6_pcie);
> + return 0;
> +
> +err:
> + return ret;
> +}
> +
> +static const struct of_device_id imx6_pcie_of_match[] = {
> + { .compatible = "fsl,imx6q-pcie", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
> +
> +static struct platform_driver imx6_pcie_driver = {
> + .driver = {
> + .name = "imx6q-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(imx6_pcie_of_match),
> + },
> +};
> +
> +/* Freescale PCIe driver does not allow module unload */
> +
> +static int __init imx6_init(void)
> +{
> + return platform_driver_probe(&imx6_pcie_driver,
> +imx6_pcie_probe); } module_init(imx6_init);
> +
> +MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");
> +MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-27 1:38 ` Zhu Richard-R65037
(?)
@ 2013-09-27 2:19 ` Shawn Guo
-1 siblings, 0 replies; 59+ messages in thread
From: Shawn Guo @ 2013-09-27 2:19 UTC (permalink / raw)
To: Zhu Richard-R65037
Cc: Tim Harvey, Sean Cross, devicetree@vger.kernel.org,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Sascha Hauer, bhelgaas@google.com
On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
> Hi Tim:
> Thanks for your tests.
> Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
> is ok on FSL imx_3.0.35 kernels.
> I'm debugging this issue now, and would summit the patches asap.
>
>From what I read, it seems Sean's series does not support PCIe switch.
At least, he hasn't got any device to test it. And there is some
problem with PCIe switch running the latest kernel, which might not be
related to the controller driver.
I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
can have a same base to work on, and add PCIe switch support with
incremental patches. Does that sound good to you, Tim?
Shawn
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 2:19 ` Shawn Guo
0 siblings, 0 replies; 59+ messages in thread
From: Shawn Guo @ 2013-09-27 2:19 UTC (permalink / raw)
To: Zhu Richard-R65037
Cc: Tim Harvey, Sean Cross,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
> Hi Tim:
> Thanks for your tests.
> Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
> is ok on FSL imx_3.0.35 kernels.
> I'm debugging this issue now, and would summit the patches asap.
>
>From what I read, it seems Sean's series does not support PCIe switch.
At least, he hasn't got any device to test it. And there is some
problem with PCIe switch running the latest kernel, which might not be
related to the controller driver.
I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
can have a same base to work on, and add PCIe switch support with
incremental patches. Does that sound good to you, Tim?
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 2:19 ` Shawn Guo
0 siblings, 0 replies; 59+ messages in thread
From: Shawn Guo @ 2013-09-27 2:19 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
> Hi Tim:
> Thanks for your tests.
> Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
> is ok on FSL imx_3.0.35 kernels.
> I'm debugging this issue now, and would summit the patches asap.
>
>From what I read, it seems Sean's series does not support PCIe switch.
At least, he hasn't got any device to test it. And there is some
problem with PCIe switch running the latest kernel, which might not be
related to the controller driver.
I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
can have a same base to work on, and add PCIe switch support with
incremental patches. Does that sound good to you, Tim?
Shawn
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-27 2:19 ` Shawn Guo
(?)
@ 2013-09-27 3:40 ` Jingoo Han
-1 siblings, 0 replies; 59+ messages in thread
From: Jingoo Han @ 2013-09-27 3:40 UTC (permalink / raw)
To: 'Shawn Guo'
Cc: 'Zhu Richard-R65037', 'Tim Harvey',
'Sean Cross', devicetree, linux-pci, linux-arm-kernel,
'Sascha Hauer', bhelgaas, 'Jingoo Han'
On Friday, September 27, 2013 11:19 AM, Shawn Guo wrote:
> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
> > Hi Tim:
> > Thanks for your tests.
> > Yes, it is. There are some problems when the PCIe switch is used
> > on the 3.1x kernel at my side too,
> although the PCIe switch
> > is ok on FSL imx_3.0.35 kernels.
> > I'm debugging this issue now, and would summit the patches asap.
> >
>
> From what I read, it seems Sean's series does not support PCIe switch.
> At least, he hasn't got any device to test it. And there is some
> problem with PCIe switch running the latest kernel, which might not be
> related to the controller driver.
>
> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
> can have a same base to work on, and add PCIe switch support with
> incremental patches. Does that sound good to you, Tim?
>
Hi Shawn Guo,
I agree with your suggestion. :-)
The PCIe switch support patches can be added later, after the v7 patch for
i.MX6 PCIe controller driver is merged.
Also, if the PCIe switch support patches modify the synopsys designware PCIe
driver (pcie-designware.c), it should be confirmed by other related people.
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 3:40 ` Jingoo Han
0 siblings, 0 replies; 59+ messages in thread
From: Jingoo Han @ 2013-09-27 3:40 UTC (permalink / raw)
To: 'Shawn Guo'
Cc: 'Zhu Richard-R65037', 'Tim Harvey',
'Sean Cross', devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
'Sascha Hauer', bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
'Jingoo Han'
On Friday, September 27, 2013 11:19 AM, Shawn Guo wrote:
> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
> > Hi Tim:
> > Thanks for your tests.
> > Yes, it is. There are some problems when the PCIe switch is used
> > on the 3.1x kernel at my side too,
> although the PCIe switch
> > is ok on FSL imx_3.0.35 kernels.
> > I'm debugging this issue now, and would summit the patches asap.
> >
>
> From what I read, it seems Sean's series does not support PCIe switch.
> At least, he hasn't got any device to test it. And there is some
> problem with PCIe switch running the latest kernel, which might not be
> related to the controller driver.
>
> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
> can have a same base to work on, and add PCIe switch support with
> incremental patches. Does that sound good to you, Tim?
>
Hi Shawn Guo,
I agree with your suggestion. :-)
The PCIe switch support patches can be added later, after the v7 patch for
i.MX6 PCIe controller driver is merged.
Also, if the PCIe switch support patches modify the synopsys designware PCIe
driver (pcie-designware.c), it should be confirmed by other related people.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 3:40 ` Jingoo Han
0 siblings, 0 replies; 59+ messages in thread
From: Jingoo Han @ 2013-09-27 3:40 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, September 27, 2013 11:19 AM, Shawn Guo wrote:
> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
> > Hi Tim:
> > Thanks for your tests.
> > Yes, it is. There are some problems when the PCIe switch is used
> > on the 3.1x kernel at my side too,
> although the PCIe switch
> > is ok on FSL imx_3.0.35 kernels.
> > I'm debugging this issue now, and would summit the patches asap.
> >
>
> From what I read, it seems Sean's series does not support PCIe switch.
> At least, he hasn't got any device to test it. And there is some
> problem with PCIe switch running the latest kernel, which might not be
> related to the controller driver.
>
> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
> can have a same base to work on, and add PCIe switch support with
> incremental patches. Does that sound good to you, Tim?
>
Hi Shawn Guo,
I agree with your suggestion. :-)
The PCIe switch support patches can be added later, after the v7 patch for
i.MX6 PCIe controller driver is merged.
Also, if the PCIe switch support patches modify the synopsys designware PCIe
driver (pcie-designware.c), it should be confirmed by other related people.
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-27 3:40 ` Jingoo Han
(?)
@ 2013-09-27 3:54 ` Sean Cross
-1 siblings, 0 replies; 59+ messages in thread
From: Sean Cross @ 2013-09-27 3:54 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Shawn Guo', 'Zhu Richard-R65037',
'Tim Harvey', devicetree, linux-pci, linux-arm-kernel,
'Sascha Hauer', bhelgaas
On 27/9/13 11:40 AM, Jingoo Han wrote:
> On Friday, September 27, 2013 11:19 AM, Shawn Guo wrote:
>> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
>>> Hi Tim:
>>> Thanks for your tests.
>>> Yes, it is. There are some problems when the PCIe switch is used
>>> on the 3.1x kernel at my side too,
>> although the PCIe switch
>>> is ok on FSL imx_3.0.35 kernels.
>>> I'm debugging this issue now, and would summit the patches asap.
>>>
>> From what I read, it seems Sean's series does not support PCIe switch.
>> At least, he hasn't got any device to test it. And there is some
>> problem with PCIe switch running the latest kernel, which might not be
>> related to the controller driver.
>>
>> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
>> can have a same base to work on, and add PCIe switch support with
>> incremental patches. Does that sound good to you, Tim?
>>
> Hi Shawn Guo,
>
> I agree with your suggestion. :-)
> The PCIe switch support patches can be added later, after the v7 patch for
> i.MX6 PCIe controller driver is merged.
>
> Also, if the PCIe switch support patches modify the synopsys designware PCIe
> driver (pcie-designware.c), it should be confirmed by other related people.
>
Correct. My series doesn't support PCIe switches mostly because I don't
have one to test with. It would be interesting to see if PCIe switches
work with other Designware drivers.
---
Sean
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 3:54 ` Sean Cross
0 siblings, 0 replies; 59+ messages in thread
From: Sean Cross @ 2013-09-27 3:54 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Shawn Guo', 'Zhu Richard-R65037',
'Tim Harvey', devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
'Sascha Hauer', bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
On 27/9/13 11:40 AM, Jingoo Han wrote:
> On Friday, September 27, 2013 11:19 AM, Shawn Guo wrote:
>> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
>>> Hi Tim:
>>> Thanks for your tests.
>>> Yes, it is. There are some problems when the PCIe switch is used
>>> on the 3.1x kernel at my side too,
>> although the PCIe switch
>>> is ok on FSL imx_3.0.35 kernels.
>>> I'm debugging this issue now, and would summit the patches asap.
>>>
>> From what I read, it seems Sean's series does not support PCIe switch.
>> At least, he hasn't got any device to test it. And there is some
>> problem with PCIe switch running the latest kernel, which might not be
>> related to the controller driver.
>>
>> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
>> can have a same base to work on, and add PCIe switch support with
>> incremental patches. Does that sound good to you, Tim?
>>
> Hi Shawn Guo,
>
> I agree with your suggestion. :-)
> The PCIe switch support patches can be added later, after the v7 patch for
> i.MX6 PCIe controller driver is merged.
>
> Also, if the PCIe switch support patches modify the synopsys designware PCIe
> driver (pcie-designware.c), it should be confirmed by other related people.
>
Correct. My series doesn't support PCIe switches mostly because I don't
have one to test with. It would be interesting to see if PCIe switches
work with other Designware drivers.
---
Sean
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 3:54 ` Sean Cross
0 siblings, 0 replies; 59+ messages in thread
From: Sean Cross @ 2013-09-27 3:54 UTC (permalink / raw)
To: linux-arm-kernel
On 27/9/13 11:40 AM, Jingoo Han wrote:
> On Friday, September 27, 2013 11:19 AM, Shawn Guo wrote:
>> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
>>> Hi Tim:
>>> Thanks for your tests.
>>> Yes, it is. There are some problems when the PCIe switch is used
>>> on the 3.1x kernel at my side too,
>> although the PCIe switch
>>> is ok on FSL imx_3.0.35 kernels.
>>> I'm debugging this issue now, and would summit the patches asap.
>>>
>> From what I read, it seems Sean's series does not support PCIe switch.
>> At least, he hasn't got any device to test it. And there is some
>> problem with PCIe switch running the latest kernel, which might not be
>> related to the controller driver.
>>
>> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
>> can have a same base to work on, and add PCIe switch support with
>> incremental patches. Does that sound good to you, Tim?
>>
> Hi Shawn Guo,
>
> I agree with your suggestion. :-)
> The PCIe switch support patches can be added later, after the v7 patch for
> i.MX6 PCIe controller driver is merged.
>
> Also, if the PCIe switch support patches modify the synopsys designware PCIe
> driver (pcie-designware.c), it should be confirmed by other related people.
>
Correct. My series doesn't support PCIe switches mostly because I don't
have one to test with. It would be interesting to see if PCIe switches
work with other Designware drivers.
---
Sean
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-27 2:19 ` Shawn Guo
(?)
@ 2013-09-27 3:52 ` Tim Harvey
-1 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-09-27 3:52 UTC (permalink / raw)
To: Shawn Guo
Cc: Zhu Richard-R65037, Sean Cross, devicetree@vger.kernel.org,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Sascha Hauer, bhelgaas@google.com
On Thu, Sep 26, 2013 at 7:19 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
>> Hi Tim:
>> Thanks for your tests.
>> Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
>> is ok on FSL imx_3.0.35 kernels.
>> I'm debugging this issue now, and would summit the patches asap.
>>
>
> From what I read, it seems Sean's series does not support PCIe switch.
> At least, he hasn't got any device to test it. And there is some
> problem with PCIe switch running the latest kernel, which might not be
> related to the controller driver.
>
> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
> can have a same base to work on, and add PCIe switch support with
> incremental patches. Does that sound good to you, Tim?
>
> Shawn
>
Agreed - I would like to get this out there to a broader audience as well.
Thanks,
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 3:52 ` Tim Harvey
0 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-09-27 3:52 UTC (permalink / raw)
To: Shawn Guo
Cc: Zhu Richard-R65037, Sean Cross,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
On Thu, Sep 26, 2013 at 7:19 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
>> Hi Tim:
>> Thanks for your tests.
>> Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
>> is ok on FSL imx_3.0.35 kernels.
>> I'm debugging this issue now, and would summit the patches asap.
>>
>
> From what I read, it seems Sean's series does not support PCIe switch.
> At least, he hasn't got any device to test it. And there is some
> problem with PCIe switch running the latest kernel, which might not be
> related to the controller driver.
>
> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
> can have a same base to work on, and add PCIe switch support with
> incremental patches. Does that sound good to you, Tim?
>
> Shawn
>
Agreed - I would like to get this out there to a broader audience as well.
Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-09-27 3:52 ` Tim Harvey
0 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-09-27 3:52 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 26, 2013 at 7:19 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Fri, Sep 27, 2013 at 01:38:39AM +0000, Zhu Richard-R65037 wrote:
>> Hi Tim:
>> Thanks for your tests.
>> Yes, it is. There are some problems when the PCIe switch is used on the 3.1x kernel at my side too, although the PCIe switch
>> is ok on FSL imx_3.0.35 kernels.
>> I'm debugging this issue now, and would summit the patches asap.
>>
>
> From what I read, it seems Sean's series does not support PCIe switch.
> At least, he hasn't got any device to test it. And there is some
> problem with PCIe switch running the latest kernel, which might not be
> related to the controller driver.
>
> I suggest we ask Bjorn to merge the v7 I sent yesterday, so that people
> can have a same base to work on, and add PCIe switch support with
> incremental patches. Does that sound good to you, Tim?
>
> Shawn
>
Agreed - I would like to get this out there to a broader audience as well.
Thanks,
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-09-16 8:20 ` Sean Cross
@ 2013-10-18 5:32 ` Tim Harvey
-1 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-10-18 5:32 UTC (permalink / raw)
To: Sean Cross
Cc: devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Sascha Hauer,
Zhu Richard-R65037, Shawn Guo, Bjorn Helgaas, Marek Vašut,
Jingoo Han, Pratyush Anand, Troy Kisky
On Mon, Sep 16, 2013 at 1:20 AM, Sean Cross <xobs@kosagi.com> wrote:
> Add support for the PCIe port present on the i.MX6 family of controllers.
> These use the Synopsis Designware core tied to their own PHY.
>
> Signed-off-by: Sean Cross <xobs@kosagi.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> .../devicetree/bindings/pci/designware-pcie.txt | 7 +-
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index ccd55c2..125202e 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -116,6 +116,22 @@
> arm,data-latency = <4 2 3>;
> };
>
> + pcie: pcie@0x01000000 {
> + compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
> + reg = <0x01ffc000 0x4000>; /* DBI */
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
> + 0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
> + 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
> + num-lanes = <1>;
> + interrupts = <0 123 0x04>;
> + clocks = <&clks 189>, <&clks 187>, <&clks 205>, <&clks 144>;
> + clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
> + status = "disabled";
> + };
> +
Sean,
The devicetree portion above is now here
https://gitorious.org/thierryreding/linux-next/commit/3a57291fa4ca7f7647d826f5b47082ef306d839f
(which I'm told gets pulled into linux-next) and I wanted to see if
you or any of the other IMX/PCI gurus here can answer a question about
region mapping.
The above ranges look to me to allocate 15MB for mem resources, 64K
for io resources, and 256K for cfg space.
Table 2.1 of the IMX6DQRM.pdf
(http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf)
shows:
01FF_C000 01FF_FFFF 16 KB PCIe registers
0100_0000 01FF_BFFF 16368 KB PCIe
The driver in the fsl 3.0.35_4.1.0 BSP maps the following (see
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/pcie.c?h=imx_3.0.35_4.1.0#n331):
0x0100_0000 --- 0x01DF_FFFF 14MB IORESOURCE_MEM
0x01E0_0000 --- 0x01EF_FFFF 1MB IORESOURCE_IO
0x01F0_0000 --- 0x01FF_FFFF 1MB Cfg + MSI + Registers
and, in a discussion on the IMX Community forum
(https://community.freescale.com/message/334959#334959) points out
that you have more flexibility if you map the MEM resource first
because of its more limited alignment. So, if you were going to stick
with the fsl mapping I would think we would want something like this
in the dt node:
ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* 512K
configuration space */
0x81000000 0 0 0x01e00000 0 0x00100000 /* 1MB
downstream I/O */
0x82000000 0 0x01000000 0x01000000 0 0x00e00000>; /*
14MB non-prefetchable memory */
Can these regions be moved around however you want depending on what
kind of mem vs io resource configurations you desire? How about the
cfg space - is 512K really needed?
Are we sure the committed values to linux-next 'wrong' in any way? I
still am seeing bus-hangs with devices behind a bridge that use
io-space resources and am trying to figure out where the issue is. I
don't get these bus-hangs when using the fsl driver which is
structured very different so its been difficult for me to determine
the difference. The mappings and the way iATU mappings are done are
very different.
Thanks,
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-10-18 5:32 ` Tim Harvey
0 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-10-18 5:32 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 16, 2013 at 1:20 AM, Sean Cross <xobs@kosagi.com> wrote:
> Add support for the PCIe port present on the i.MX6 family of controllers.
> These use the Synopsis Designware core tied to their own PHY.
>
> Signed-off-by: Sean Cross <xobs@kosagi.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> .../devicetree/bindings/pci/designware-pcie.txt | 7 +-
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index ccd55c2..125202e 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -116,6 +116,22 @@
> arm,data-latency = <4 2 3>;
> };
>
> + pcie: pcie at 0x01000000 {
> + compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
> + reg = <0x01ffc000 0x4000>; /* DBI */
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
> + 0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
> + 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
> + num-lanes = <1>;
> + interrupts = <0 123 0x04>;
> + clocks = <&clks 189>, <&clks 187>, <&clks 205>, <&clks 144>;
> + clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
> + status = "disabled";
> + };
> +
Sean,
The devicetree portion above is now here
https://gitorious.org/thierryreding/linux-next/commit/3a57291fa4ca7f7647d826f5b47082ef306d839f
(which I'm told gets pulled into linux-next) and I wanted to see if
you or any of the other IMX/PCI gurus here can answer a question about
region mapping.
The above ranges look to me to allocate 15MB for mem resources, 64K
for io resources, and 256K for cfg space.
Table 2.1 of the IMX6DQRM.pdf
(http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf)
shows:
01FF_C000 01FF_FFFF 16 KB PCIe registers
0100_0000 01FF_BFFF 16368 KB PCIe
The driver in the fsl 3.0.35_4.1.0 BSP maps the following (see
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/pcie.c?h=imx_3.0.35_4.1.0#n331):
0x0100_0000 --- 0x01DF_FFFF 14MB IORESOURCE_MEM
0x01E0_0000 --- 0x01EF_FFFF 1MB IORESOURCE_IO
0x01F0_0000 --- 0x01FF_FFFF 1MB Cfg + MSI + Registers
and, in a discussion on the IMX Community forum
(https://community.freescale.com/message/334959#334959) points out
that you have more flexibility if you map the MEM resource first
because of its more limited alignment. So, if you were going to stick
with the fsl mapping I would think we would want something like this
in the dt node:
ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* 512K
configuration space */
0x81000000 0 0 0x01e00000 0 0x00100000 /* 1MB
downstream I/O */
0x82000000 0 0x01000000 0x01000000 0 0x00e00000>; /*
14MB non-prefetchable memory */
Can these regions be moved around however you want depending on what
kind of mem vs io resource configurations you desire? How about the
cfg space - is 512K really needed?
Are we sure the committed values to linux-next 'wrong' in any way? I
still am seeing bus-hangs with devices behind a bridge that use
io-space resources and am trying to figure out where the issue is. I
don't get these bus-hangs when using the fsl driver which is
structured very different so its been difficult for me to determine
the difference. The mappings and the way iATU mappings are done are
very different.
Thanks,
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread* RE: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-10-18 5:32 ` Tim Harvey
@ 2013-10-18 6:34 ` Zhu Richard-R65037
-1 siblings, 0 replies; 59+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-18 6:34 UTC (permalink / raw)
To: Tim Harvey, Sean Cross
Cc: devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Sascha Hauer, Shawn Guo,
Bjorn Helgaas, Marek Vašut, Jingoo Han, Pratyush Anand,
Troy Kisky
> -----Original Message-----
> From: Tim Harvey [mailto:tharvey@gateworks.com]
> Sent: Friday, October 18, 2013 1:33 PM
> To: Sean Cross
> Cc: devicetree@vger.kernel.org; linux-pci@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; Sascha Hauer; Zhu Richard-R65037; Shawn Guo; Bjorn
> Helgaas; Marek Vašut; Jingoo Han; Pratyush Anand; Troy Kisky
> Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
>
> On Mon, Sep 16, 2013 at 1:20 AM, Sean Cross <xobs@kosagi.com> wrote:
> > Add support for the PCIe port present on the i.MX6 family of controllers.
> > These use the Synopsis Designware core tied to their own PHY.
> >
> > Signed-off-by: Sean Cross <xobs@kosagi.com>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > ---
> > .../devicetree/bindings/pci/designware-pcie.txt | 7 +-
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi
> > b/arch/arm/boot/dts/imx6qdl.dtsi index ccd55c2..125202e 100644
> > --- a/arch/arm/boot/dts/imx6qdl.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> > @@ -116,6 +116,22 @@
> > arm,data-latency = <4 2 3>;
> > };
> >
> > + pcie: pcie@0x01000000 {
> > + compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
> > + reg = <0x01ffc000 0x4000>; /* DBI */
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + device_type = "pci";
> > + ranges = <0x00000800 0 0x01f00000 0x01f00000 0
> 0x00080000 /* configuration space */
> > + 0x81000000 0 0 0x01f80000 0
> 0x00010000 /* downstream I/O */
> > + 0x82000000 0 0x01000000 0x01000000 0
> 0x00f00000>; /* non-prefetchable memory */
> > + num-lanes = <1>;
> > + interrupts = <0 123 0x04>;
> > + clocks = <&clks 189>, <&clks 187>, <&clks 205>,
> <&clks 144>;
> > + clock-names = "pcie_ref_125m", "sata_ref_100m",
> "lvds_gate", "pcie_axi";
> > + status = "disabled";
> > + };
> > +
>
> Sean,
>
> The devicetree portion above is now here
> https://gitorious.org/thierryreding/linux-
> next/commit/3a57291fa4ca7f7647d826f5b47082ef306d839f
> (which I'm told gets pulled into linux-next) and I wanted to see if you or any
> of the other IMX/PCI gurus here can answer a question about region mapping.
>
> The above ranges look to me to allocate 15MB for mem resources, 64K for io
> resources, and 256K for cfg space.
>
> Table 2.1 of the IMX6DQRM.pdf
> (http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf)
> shows:
> 01FF_C000 01FF_FFFF 16 KB PCIe registers
> 0100_0000 01FF_BFFF 16368 KB PCIe
>
> The driver in the fsl 3.0.35_4.1.0 BSP maps the following (see
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-
> imx.git/tree/arch/arm/mach-mx6/pcie.c?h=imx_3.0.35_4.1.0#n331):
>
> 0x0100_0000 --- 0x01DF_FFFF 14MB IORESOURCE_MEM
> 0x01E0_0000 --- 0x01EF_FFFF 1MB IORESOURCE_IO
> 0x01F0_0000 --- 0x01FF_FFFF 1MB Cfg + MSI + Registers
>
> and, in a discussion on the IMX Community forum
> (https://community.freescale.com/message/334959#334959) points out that you
> have more flexibility if you map the MEM resource first because of its more
> limited alignment. So, if you were going to stick with the fsl mapping I
> would think we would want something like this in the dt node:
>
> ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* 512K
> configuration space */
> 0x81000000 0 0 0x01e00000 0 0x00100000 /* 1MB
> downstream I/O */
> 0x82000000 0 0x01000000 0x01000000 0 0x00e00000>; /* 14MB non-
> prefetchable memory */
>
> Can these regions be moved around however you want depending on what kind of
> mem vs io resource configurations you desire? How about the cfg space - is
> 512K really needed?
>
> Are we sure the committed values to linux-next 'wrong' in any way? I still am
> seeing bus-hangs with devices behind a bridge that use io-space resources and
> am trying to figure out where the issue is. I don't get these bus-hangs when
> using the fsl driver which is structured very different so its been difficult
> for me to determine the difference. The mappings and the way iATU mappings
> are done are very different.
Hi Tim:
Regarding to my experience, the difference shouldn't be related with the bus hang.
Here are my DT region setup when I trying to bring up imx6 pcie on 3.1x kernel by my own driver.
clock-names = "pcie_axi", "pcie_ref", "pcie_bus_in", "pcie_bus_out";
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
num-lanes = <1>;
It works sometimes, although that there is random kernel panic and system hang(log is pasted below):(
LOGS, when pericom's PI7C9X2G303EL and Intel e1000e network card is used.
...
imx-pcie 1ffc000.pcie: legacy_irq 155
imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
IMX PCIe port: link up.
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers disabled
pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus2: Fast back to back transfers disabled
pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus3: Fast back to back transfers disabled
PCI: bus4: Fast back to back transfers enabled
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff 64bit]
pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x011fffff]
pci 0000:03:00.0: BAR 0: assigned [mem 0x01200000-0x0121ffff]
pci 0000:03:00.0: BAR 3: assigned [mem 0x01220000-0x01223fff]
pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
pci 0000:02:01.0: PCI bridge to [bus 03]
pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
pci 0000:02:01.0: bridge window [mem 0x01100000-0x012fffff]
pci 0000:02:02.0: PCI bridge to [bus 04]
pci 0000:01:00.0: PCI bridge to [bus 02-04]
pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:01:00.0: bridge window [mem 0x01100000-0x012fffff]
pci 0000:00:00.0: PCI bridge to [bus 01-04]
pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x012fffff]
PCI: enabling device 0000:01:00.0 (0140 -> 0143)
PCI: enabling device 0000:02:01.0 (0140 -> 0143)
PCI: enabling device 0000:02:02.0 (0140 -> 0143)
...
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
e1000e 0000:03:00.0: Disabling ASPM L0s L1
PCI: enabling device 0000:03:00.0 (0140 -> 0142)
e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:03:00.0 eth1: registered PHC clock
e1000e 0000:03:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b
e1000e 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:03:00.0 eth1: MAC: 3, PHY: 8, PBA No: E42641-005
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.3-k
igb: Copyright (c) 2007-2013 Intel Corporation.
...
ALSA device list:
#0: wm8962-audio
VFS: Mounted root (nfs filesystem) on device 0:11.
devtmpfs: mounted
Freeing unused kernel memory: 324K (8082d000 - 8087e000)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b <-- Kernel panic here randomly. Same phenomena when the root-fs is located in SD.
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3+ #13
Backtrace:
[<80011b58>] (dump_backtrace+0x0/0x10c) from [<80011cf8>] (show_stack+0x18/0x1c)
r6:bf896000 r5:8087dd84 r4:00000000 r3:00000000
[<80011ce0>] (show_stack+0x0/0x1c) from [<80642d8c>] (dump_stack+0x78/0x94)
[<80642d14>] (dump_stack+0x0/0x94) from [<80014a60>] (handle_IPI+0x138/0x174)
>
> Thanks,
>
> Tim
Thanks.
Best Regards
Richard Zhu
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-10-18 6:34 ` Zhu Richard-R65037
0 siblings, 0 replies; 59+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-18 6:34 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tim Harvey [mailto:tharvey at gateworks.com]
> Sent: Friday, October 18, 2013 1:33 PM
> To: Sean Cross
> Cc: devicetree at vger.kernel.org; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Sascha Hauer; Zhu Richard-R65037; Shawn Guo; Bjorn
> Helgaas; Marek Va?ut; Jingoo Han; Pratyush Anand; Troy Kisky
> Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
>
> On Mon, Sep 16, 2013 at 1:20 AM, Sean Cross <xobs@kosagi.com> wrote:
> > Add support for the PCIe port present on the i.MX6 family of controllers.
> > These use the Synopsis Designware core tied to their own PHY.
> >
> > Signed-off-by: Sean Cross <xobs@kosagi.com>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > ---
> > .../devicetree/bindings/pci/designware-pcie.txt | 7 +-
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi
> > b/arch/arm/boot/dts/imx6qdl.dtsi index ccd55c2..125202e 100644
> > --- a/arch/arm/boot/dts/imx6qdl.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> > @@ -116,6 +116,22 @@
> > arm,data-latency = <4 2 3>;
> > };
> >
> > + pcie: pcie at 0x01000000 {
> > + compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
> > + reg = <0x01ffc000 0x4000>; /* DBI */
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + device_type = "pci";
> > + ranges = <0x00000800 0 0x01f00000 0x01f00000 0
> 0x00080000 /* configuration space */
> > + 0x81000000 0 0 0x01f80000 0
> 0x00010000 /* downstream I/O */
> > + 0x82000000 0 0x01000000 0x01000000 0
> 0x00f00000>; /* non-prefetchable memory */
> > + num-lanes = <1>;
> > + interrupts = <0 123 0x04>;
> > + clocks = <&clks 189>, <&clks 187>, <&clks 205>,
> <&clks 144>;
> > + clock-names = "pcie_ref_125m", "sata_ref_100m",
> "lvds_gate", "pcie_axi";
> > + status = "disabled";
> > + };
> > +
>
> Sean,
>
> The devicetree portion above is now here
> https://gitorious.org/thierryreding/linux-
> next/commit/3a57291fa4ca7f7647d826f5b47082ef306d839f
> (which I'm told gets pulled into linux-next) and I wanted to see if you or any
> of the other IMX/PCI gurus here can answer a question about region mapping.
>
> The above ranges look to me to allocate 15MB for mem resources, 64K for io
> resources, and 256K for cfg space.
>
> Table 2.1 of the IMX6DQRM.pdf
> (http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf)
> shows:
> 01FF_C000 01FF_FFFF 16 KB PCIe registers
> 0100_0000 01FF_BFFF 16368 KB PCIe
>
> The driver in the fsl 3.0.35_4.1.0 BSP maps the following (see
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-
> imx.git/tree/arch/arm/mach-mx6/pcie.c?h=imx_3.0.35_4.1.0#n331):
>
> 0x0100_0000 --- 0x01DF_FFFF 14MB IORESOURCE_MEM
> 0x01E0_0000 --- 0x01EF_FFFF 1MB IORESOURCE_IO
> 0x01F0_0000 --- 0x01FF_FFFF 1MB Cfg + MSI + Registers
>
> and, in a discussion on the IMX Community forum
> (https://community.freescale.com/message/334959#334959) points out that you
> have more flexibility if you map the MEM resource first because of its more
> limited alignment. So, if you were going to stick with the fsl mapping I
> would think we would want something like this in the dt node:
>
> ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* 512K
> configuration space */
> 0x81000000 0 0 0x01e00000 0 0x00100000 /* 1MB
> downstream I/O */
> 0x82000000 0 0x01000000 0x01000000 0 0x00e00000>; /* 14MB non-
> prefetchable memory */
>
> Can these regions be moved around however you want depending on what kind of
> mem vs io resource configurations you desire? How about the cfg space - is
> 512K really needed?
>
> Are we sure the committed values to linux-next 'wrong' in any way? I still am
> seeing bus-hangs with devices behind a bridge that use io-space resources and
> am trying to figure out where the issue is. I don't get these bus-hangs when
> using the fsl driver which is structured very different so its been difficult
> for me to determine the difference. The mappings and the way iATU mappings
> are done are very different.
Hi Tim:
Regarding to my experience, the difference shouldn't be related with the bus hang.
Here are my DT region setup when I trying to bring up imx6 pcie on 3.1x kernel by my own driver.
clock-names = "pcie_axi", "pcie_ref", "pcie_bus_in", "pcie_bus_out";
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
num-lanes = <1>;
It works sometimes, although that there is random kernel panic and system hang(log is pasted below):(
LOGS, when pericom's PI7C9X2G303EL and Intel e1000e network card is used.
...
imx-pcie 1ffc000.pcie: legacy_irq 155
imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
IMX PCIe port: link up.
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers disabled
pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus2: Fast back to back transfers disabled
pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus3: Fast back to back transfers disabled
PCI: bus4: Fast back to back transfers enabled
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff 64bit]
pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x011fffff]
pci 0000:03:00.0: BAR 0: assigned [mem 0x01200000-0x0121ffff]
pci 0000:03:00.0: BAR 3: assigned [mem 0x01220000-0x01223fff]
pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
pci 0000:02:01.0: PCI bridge to [bus 03]
pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
pci 0000:02:01.0: bridge window [mem 0x01100000-0x012fffff]
pci 0000:02:02.0: PCI bridge to [bus 04]
pci 0000:01:00.0: PCI bridge to [bus 02-04]
pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:01:00.0: bridge window [mem 0x01100000-0x012fffff]
pci 0000:00:00.0: PCI bridge to [bus 01-04]
pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x012fffff]
PCI: enabling device 0000:01:00.0 (0140 -> 0143)
PCI: enabling device 0000:02:01.0 (0140 -> 0143)
PCI: enabling device 0000:02:02.0 (0140 -> 0143)
...
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
e1000e 0000:03:00.0: Disabling ASPM L0s L1
PCI: enabling device 0000:03:00.0 (0140 -> 0142)
e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:03:00.0 eth1: registered PHC clock
e1000e 0000:03:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b
e1000e 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:03:00.0 eth1: MAC: 3, PHY: 8, PBA No: E42641-005
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.3-k
igb: Copyright (c) 2007-2013 Intel Corporation.
...
ALSA device list:
#0: wm8962-audio
VFS: Mounted root (nfs filesystem) on device 0:11.
devtmpfs: mounted
Freeing unused kernel memory: 324K (8082d000 - 8087e000)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b <-- Kernel panic here randomly. Same phenomena when the root-fs is located in SD.
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3+ #13
Backtrace:
[<80011b58>] (dump_backtrace+0x0/0x10c) from [<80011cf8>] (show_stack+0x18/0x1c)
r6:bf896000 r5:8087dd84 r4:00000000 r3:00000000
[<80011ce0>] (show_stack+0x0/0x1c) from [<80642d8c>] (dump_stack+0x78/0x94)
[<80642d14>] (dump_stack+0x0/0x94) from [<80014a60>] (handle_IPI+0x138/0x174)
>
> Thanks,
>
> Tim
Thanks.
Best Regards
Richard Zhu
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-10-18 6:34 ` Zhu Richard-R65037
@ 2013-10-18 7:27 ` Tim Harvey
-1 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-10-18 7:27 UTC (permalink / raw)
To: Zhu Richard-R65037
Cc: Sean Cross, devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Sascha Hauer, Shawn Guo,
Bjorn Helgaas, Marek Vašut, Jingoo Han, Pratyush Anand,
Troy Kisky
On Thu, Oct 17, 2013 at 11:34 PM, Zhu Richard-R65037
<r65037@freescale.com> wrote:
[...]
> Hi Tim:
> Regarding to my experience, the difference shouldn't be related with the bus hang.
> Here are my DT region setup when I trying to bring up imx6 pcie on 3.1x kernel by my own driver.
> clock-names = "pcie_axi", "pcie_ref", "pcie_bus_in", "pcie_bus_out";
> #address-cells = <3>;
> #size-cells = <2>;
> ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
> 0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
> 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
> num-lanes = <1>;
>
> It works sometimes, although that there is random kernel panic and system hang(log is pasted below):(
> LOGS, when pericom's PI7C9X2G303EL and Intel e1000e network card is used.
> ...
> imx-pcie 1ffc000.pcie: legacy_irq 155
> imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
> IMX PCIe port: link up.
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> PCI: bus1: Fast back to back transfers disabled
> pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus2: Fast back to back transfers disabled
> pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus3: Fast back to back transfers disabled
> PCI: bus4: Fast back to back transfers enabled
> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff 64bit]
> pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
> pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
> pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
> pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x011fffff]
> pci 0000:03:00.0: BAR 0: assigned [mem 0x01200000-0x0121ffff]
> pci 0000:03:00.0: BAR 3: assigned [mem 0x01220000-0x01223fff]
> pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
> pci 0000:02:01.0: PCI bridge to [bus 03]
> pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
> pci 0000:02:01.0: bridge window [mem 0x01100000-0x012fffff]
> pci 0000:02:02.0: PCI bridge to [bus 04]
> pci 0000:01:00.0: PCI bridge to [bus 02-04]
> pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:01:00.0: bridge window [mem 0x01100000-0x012fffff]
> pci 0000:00:00.0: PCI bridge to [bus 01-04]
> pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x012fffff]
> PCI: enabling device 0000:01:00.0 (0140 -> 0143)
> PCI: enabling device 0000:02:01.0 (0140 -> 0143)
> PCI: enabling device 0000:02:02.0 (0140 -> 0143)
> ...
> e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
> e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> e1000e 0000:03:00.0: Disabling ASPM L0s L1
> PCI: enabling device 0000:03:00.0 (0140 -> 0142)
> e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> e1000e 0000:03:00.0 eth1: registered PHC clock
> e1000e 0000:03:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b
> e1000e 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection
> e1000e 0000:03:00.0 eth1: MAC: 3, PHY: 8, PBA No: E42641-005
> igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.3-k
> igb: Copyright (c) 2007-2013 Intel Corporation.
> ...
>
> ALSA device list:
> #0: wm8962-audio
> VFS: Mounted root (nfs filesystem) on device 0:11.
> devtmpfs: mounted
> Freeing unused kernel memory: 324K (8082d000 - 8087e000)
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b <-- Kernel panic here randomly. Same phenomena when the root-fs is located in SD.
Richard,
I would suspect this is the imprecise abort issue. Please see my
patch (http://thread.gmane.org/gmane.linux.kernel.pci/26159) resolves
that for you and reply to that thread if so.
I believe that the imprecise abort's only occurs if you have a PCIe
switch on the bus - is this your topology and if so are you
experiencing any issues with devices behind the bus that use io
regions? If you do have a switch, perhaps you can provide me with an
'lspci -v' for comparison.
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-10-18 7:27 ` Tim Harvey
0 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-10-18 7:27 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 17, 2013 at 11:34 PM, Zhu Richard-R65037
<r65037@freescale.com> wrote:
[...]
> Hi Tim:
> Regarding to my experience, the difference shouldn't be related with the bus hang.
> Here are my DT region setup when I trying to bring up imx6 pcie on 3.1x kernel by my own driver.
> clock-names = "pcie_axi", "pcie_ref", "pcie_bus_in", "pcie_bus_out";
> #address-cells = <3>;
> #size-cells = <2>;
> ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 /* configuration space */
> 0x81000000 0 0 0x01f80000 0 0x00010000 /* downstream I/O */
> 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
> num-lanes = <1>;
>
> It works sometimes, although that there is random kernel panic and system hang(log is pasted below):(
> LOGS, when pericom's PI7C9X2G303EL and Intel e1000e network card is used.
> ...
> imx-pcie 1ffc000.pcie: legacy_irq 155
> imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
> IMX PCIe port: link up.
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> PCI: bus1: Fast back to back transfers disabled
> pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus2: Fast back to back transfers disabled
> pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus3: Fast back to back transfers disabled
> PCI: bus4: Fast back to back transfers enabled
> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff 64bit]
> pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
> pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
> pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
> pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x011fffff]
> pci 0000:03:00.0: BAR 0: assigned [mem 0x01200000-0x0121ffff]
> pci 0000:03:00.0: BAR 3: assigned [mem 0x01220000-0x01223fff]
> pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
> pci 0000:02:01.0: PCI bridge to [bus 03]
> pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
> pci 0000:02:01.0: bridge window [mem 0x01100000-0x012fffff]
> pci 0000:02:02.0: PCI bridge to [bus 04]
> pci 0000:01:00.0: PCI bridge to [bus 02-04]
> pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:01:00.0: bridge window [mem 0x01100000-0x012fffff]
> pci 0000:00:00.0: PCI bridge to [bus 01-04]
> pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x012fffff]
> PCI: enabling device 0000:01:00.0 (0140 -> 0143)
> PCI: enabling device 0000:02:01.0 (0140 -> 0143)
> PCI: enabling device 0000:02:02.0 (0140 -> 0143)
> ...
> e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
> e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> e1000e 0000:03:00.0: Disabling ASPM L0s L1
> PCI: enabling device 0000:03:00.0 (0140 -> 0142)
> e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> e1000e 0000:03:00.0 eth1: registered PHC clock
> e1000e 0000:03:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b
> e1000e 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection
> e1000e 0000:03:00.0 eth1: MAC: 3, PHY: 8, PBA No: E42641-005
> igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.3-k
> igb: Copyright (c) 2007-2013 Intel Corporation.
> ...
>
> ALSA device list:
> #0: wm8962-audio
> VFS: Mounted root (nfs filesystem) on device 0:11.
> devtmpfs: mounted
> Freeing unused kernel memory: 324K (8082d000 - 8087e000)
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b <-- Kernel panic here randomly. Same phenomena when the root-fs is located in SD.
Richard,
I would suspect this is the imprecise abort issue. Please see my
patch (http://thread.gmane.org/gmane.linux.kernel.pci/26159) resolves
that for you and reply to that thread if so.
I believe that the imprecise abort's only occurs if you have a PCIe
switch on the bus - is this your topology and if so are you
experiencing any issues with devices behind the bus that use io
regions? If you do have a switch, perhaps you can provide me with an
'lspci -v' for comparison.
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-10-18 7:27 ` Tim Harvey
@ 2013-10-18 7:45 ` Zhu Richard-R65037
-1 siblings, 0 replies; 59+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-18 7:45 UTC (permalink / raw)
To: Tim Harvey
Cc: Sean Cross, devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Sascha Hauer, Shawn Guo,
Bjorn Helgaas, Marek Vašut, Jingoo Han, Pratyush Anand,
Troy Kisky
Hi
> -----Original Message-----
> From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-owner@vger.kernel.org]
> On Behalf Of Tim Harvey
> Sent: Friday, October 18, 2013 3:28 PM
> To: Zhu Richard-R65037
> Cc: Sean Cross; devicetree@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org; Sascha Hauer; Shawn Guo; Bjorn Helgaas; Marek
> Vašut; Jingoo Han; Pratyush Anand; Troy Kisky
> Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
>
> On Thu, Oct 17, 2013 at 11:34 PM, Zhu Richard-R65037 <r65037@freescale.com>
> wrote:
>
> [...]
>
> > Hi Tim:
> > Regarding to my experience, the difference shouldn't be related with the bus
> hang.
> > Here are my DT region setup when I trying to bring up imx6 pcie on 3.1x
> kernel by my own driver.
> > clock-names = "pcie_axi", "pcie_ref", "pcie_bus_in",
> "pcie_bus_out";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > ranges = <0x00000800 0 0x01f00000 0x01f00000 0
> 0x00080000 /* configuration space */
> > 0x81000000 0 0 0x01f80000 0
> 0x00010000 /* downstream I/O */
> > 0x82000000 0 0x01000000 0x01000000 0
> 0x00f00000>; /* non-prefetchable memory */
> > num-lanes = <1>;
> >
> > It works sometimes, although that there is random kernel panic and
> > system hang(log is pasted below):( LOGS, when pericom's PI7C9X2G303EL and
> Intel e1000e network card is used.
> > ...
> > imx-pcie 1ffc000.pcie: legacy_irq 155
> > imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff] IMX PCIe port:
> > link up.
> > PCI host bridge to bus 0000:00
> > pci_bus 0000:00: root bus resource [io 0x1000-0x10000] pci_bus
> > 0000:00: root bus resource [mem 0x01000000-0x01efffff] pci_bus
> > 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> > PCI: bus0: Fast back to back transfers disabled
> > PCI: bus1: Fast back to back transfers disabled pci 0000:01:00.0:
> > bridge configuration invalid ([bus 00-00]), reconfiguring
> > PCI: bus2: Fast back to back transfers disabled pci 0000:02:01.0:
> > bridge configuration invalid ([bus 00-00]), reconfiguring pci
> > 0000:02:02.0: bridge configuration invalid ([bus 00-00]),
> > reconfiguring
> > PCI: bus3: Fast back to back transfers disabled
> > PCI: bus4: Fast back to back transfers enabled pci 0000:00:00.0: BAR
> > 0: assigned [mem 0x01000000-0x010fffff 64bit] pci 0000:00:00.0: BAR 8:
> > assigned [mem 0x01100000-0x012fffff] pci 0000:00:00.0: BAR 6: assigned
> > [mem 0x01300000-0x0130ffff pref] pci 0000:00:00.0: BAR 7: assigned [io
> > 0x1000-0x1fff] pci 0000:01:00.0: BAR 8: assigned [mem
> > 0x01100000-0x012fffff] pci 0000:01:00.0: BAR 7: assigned [io
> > 0x1000-0x1fff] pci 0000:02:01.0: BAR 8: assigned [mem
> > 0x01100000-0x012fffff] pci 0000:02:01.0: BAR 7: assigned [io
> > 0x1000-0x1fff] pci 0000:03:00.0: BAR 1: assigned [mem
> > 0x01100000-0x011fffff] pci 0000:03:00.0: BAR 0: assigned [mem
> > 0x01200000-0x0121ffff] pci 0000:03:00.0: BAR 3: assigned [mem
> > 0x01220000-0x01223fff] pci 0000:03:00.0: BAR 2: assigned [io
> > 0x1000-0x101f] pci 0000:02:01.0: PCI bridge to [bus 03]
> > pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
> > pci 0000:02:01.0: bridge window [mem 0x01100000-0x012fffff]
> > pci 0000:02:02.0: PCI bridge to [bus 04] pci 0000:01:00.0: PCI bridge
> > to [bus 02-04]
> > pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> > pci 0000:01:00.0: bridge window [mem 0x01100000-0x012fffff]
> > pci 0000:00:00.0: PCI bridge to [bus 01-04]
> > pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
> > pci 0000:00:00.0: bridge window [mem 0x01100000-0x012fffff]
> > PCI: enabling device 0000:01:00.0 (0140 -> 0143)
> > PCI: enabling device 0000:02:01.0 (0140 -> 0143)
> > PCI: enabling device 0000:02:02.0 (0140 -> 0143) ...
> > e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
> > e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> > e1000e 0000:03:00.0: Disabling ASPM L0s L1
> > PCI: enabling device 0000:03:00.0 (0140 -> 0142) e1000e 0000:03:00.0:
> > Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> > e1000e 0000:03:00.0 eth1: registered PHC clock e1000e 0000:03:00.0
> > eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b e1000e
> > 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection e1000e
> > 0000:03:00.0 eth1: MAC: 3, PHY: 8, PBA No: E42641-005
> > igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.3-k
> > igb: Copyright (c) 2007-2013 Intel Corporation.
> > ...
> >
> > ALSA device list:
> > #0: wm8962-audio
> > VFS: Mounted root (nfs filesystem) on device 0:11.
> > devtmpfs: mounted
> > Freeing unused kernel memory: 324K (8082d000 - 8087e000) Kernel panic
> > - not syncing: Attempted to kill init! exitcode=0x0000000b <-- Kernel panic
> here randomly. Same phenomena when the root-fs is located in SD.
>
> Richard,
>
> I would suspect this is the imprecise abort issue. Please see my patch
> (http://thread.gmane.org/gmane.linux.kernel.pci/26159) resolves that for you
> and reply to that thread if so.
>
> I believe that the imprecise abort's only occurs if you have a PCIe switch on
> the bus - is this your topology and if so are you experiencing any issues with
> devices behind the bus that use io regions? If you do have a switch, perhaps
> you can provide me with an 'lspci -v' for comparison.
>
Hi Tim:
Oh, It's great. Your patch can fix my problem.
My own patch-set of pcie driver works well when my Pericom's switch is used.
Thanks a lot.
Yes, it is.
E1000e network card request about 32 bytes IO regions during the bus enumeration procedure,
and it works well behind the my Pericom's switch.
Based on my own pcie driver(not the one up-streamed by Sean),
Here are the log and the lspci -v results I got just now:
imx-pcie 1ffc000.pcie: legacy_irq 155
imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
imx-pcie 1ffc000.pcie: starting to link pcie port.
imx-pcie 1ffc000.pcie: Link up
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers disabled
pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus2: Fast back to back transfers disabled
pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus3: Fast back to back transfers disabled
PCI: bus4: Fast back to back transfers enabled
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:00:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:01:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:02:01.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x0117ffff]
pci 0000:03:00.0: BAR 6: assigned [mem 0x01200000-0x0123ffff pref]
pci 0000:03:00.0: BAR 0: assigned [mem 0x01180000-0x0119ffff]
pci 0000:03:00.0: BAR 3: assigned [mem 0x011a0000-0x011a3fff]
pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
pci 0000:02:01.0: PCI bridge to [bus 03]
pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
pci 0000:02:01.0: bridge window [mem 0x01100000-0x011fffff]
pci 0000:02:01.0: bridge window [mem 0x01200000-0x012fffff pref]
pci 0000:02:02.0: PCI bridge to [bus 04]
pci 0000:01:00.0: PCI bridge to [bus 02-04]
pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:01:00.0: bridge window [mem 0x01100000-0x011fffff]
pci 0000:01:00.0: bridge window [mem 0x01200000-0x012fffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01-04]
pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
pci 0000:00:00.0: bridge window [mem 0x01200000-0x012fffff pref]
PCI: enabling device 0000:01:00.0 (0140 -> 0143)
PCI: enabling device 0000:02:01.0 (0140 -> 0143)
PCI: enabling device 0000:02:02.0 (0140 -> 0143)
...
root@freescale ~$ lspci -v
00:00.0 PCI bridge: Unknown device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
Bus: primary=00, secondary=01, subordinate=04, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 01100000-011fffff
Prefetchable memory behind bridge: 01200000-012fffff
[virtual] Expansion ROM at 01300000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
Capabilities: [70] Express Root Port (Slot-) IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
01:00.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=01, secondary=02, subordinate=04, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 01100000-011fffff
Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
Capabilities: [40] Power Management version 3
Capabilities: [5c] Vital Product Data
Capabilities: [64] Vendor Specific Information
Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
Capabilities: [c0] Express Upstream Port IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [20c] Power Budgeting
Capabilities: [230] Unknown (24)
02:01.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 01100000-011fffff
Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
Capabilities: [40] Power Management version 3
Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [64] Vendor Specific Information
Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [20c] Power Budgeting
Capabilities: [220] Unknown (13)
02:02.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
Capabilities: [40] Power Management version 3
Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [64] Vendor Specific Information
Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [20c] Power Budgeting
Capabilities: [220] Unknown (13)
03:00.0 Ethernet controller: Intel Corporation Unknown device 10d3
Subsystem: Intel Corporation Unknown device a01f
Flags: bus master, fast devsel, latency 0, IRQ 154
Memory at 01180000 (32-bit, non-prefetchable) [size=128K]
Memory at 01100000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1000 [disabled] [size=32]
Memory at 011a0000 (32-bit, non-prefetchable) [size=16K]
[virtual] Expansion ROM at 01200000 [disabled] [size=256K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [e0] Express Endpoint IRQ 0
Capabilities: [a0] MSI-X: Enable- Mask- TabSize=5
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 8b-18-3a-ff-ff-21-1b-00
> Tim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Best Regards
Richard
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-10-18 7:45 ` Zhu Richard-R65037
0 siblings, 0 replies; 59+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi
> -----Original Message-----
> From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org]
> On Behalf Of Tim Harvey
> Sent: Friday, October 18, 2013 3:28 PM
> To: Zhu Richard-R65037
> Cc: Sean Cross; devicetree at vger.kernel.org; linux-pci at vger.kernel.org; linux-
> arm-kernel at lists.infradead.org; Sascha Hauer; Shawn Guo; Bjorn Helgaas; Marek
> Va?ut; Jingoo Han; Pratyush Anand; Troy Kisky
> Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
>
> On Thu, Oct 17, 2013 at 11:34 PM, Zhu Richard-R65037 <r65037@freescale.com>
> wrote:
>
> [...]
>
> > Hi Tim:
> > Regarding to my experience, the difference shouldn't be related with the bus
> hang.
> > Here are my DT region setup when I trying to bring up imx6 pcie on 3.1x
> kernel by my own driver.
> > clock-names = "pcie_axi", "pcie_ref", "pcie_bus_in",
> "pcie_bus_out";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > ranges = <0x00000800 0 0x01f00000 0x01f00000 0
> 0x00080000 /* configuration space */
> > 0x81000000 0 0 0x01f80000 0
> 0x00010000 /* downstream I/O */
> > 0x82000000 0 0x01000000 0x01000000 0
> 0x00f00000>; /* non-prefetchable memory */
> > num-lanes = <1>;
> >
> > It works sometimes, although that there is random kernel panic and
> > system hang(log is pasted below):( LOGS, when pericom's PI7C9X2G303EL and
> Intel e1000e network card is used.
> > ...
> > imx-pcie 1ffc000.pcie: legacy_irq 155
> > imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff] IMX PCIe port:
> > link up.
> > PCI host bridge to bus 0000:00
> > pci_bus 0000:00: root bus resource [io 0x1000-0x10000] pci_bus
> > 0000:00: root bus resource [mem 0x01000000-0x01efffff] pci_bus
> > 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> > PCI: bus0: Fast back to back transfers disabled
> > PCI: bus1: Fast back to back transfers disabled pci 0000:01:00.0:
> > bridge configuration invalid ([bus 00-00]), reconfiguring
> > PCI: bus2: Fast back to back transfers disabled pci 0000:02:01.0:
> > bridge configuration invalid ([bus 00-00]), reconfiguring pci
> > 0000:02:02.0: bridge configuration invalid ([bus 00-00]),
> > reconfiguring
> > PCI: bus3: Fast back to back transfers disabled
> > PCI: bus4: Fast back to back transfers enabled pci 0000:00:00.0: BAR
> > 0: assigned [mem 0x01000000-0x010fffff 64bit] pci 0000:00:00.0: BAR 8:
> > assigned [mem 0x01100000-0x012fffff] pci 0000:00:00.0: BAR 6: assigned
> > [mem 0x01300000-0x0130ffff pref] pci 0000:00:00.0: BAR 7: assigned [io
> > 0x1000-0x1fff] pci 0000:01:00.0: BAR 8: assigned [mem
> > 0x01100000-0x012fffff] pci 0000:01:00.0: BAR 7: assigned [io
> > 0x1000-0x1fff] pci 0000:02:01.0: BAR 8: assigned [mem
> > 0x01100000-0x012fffff] pci 0000:02:01.0: BAR 7: assigned [io
> > 0x1000-0x1fff] pci 0000:03:00.0: BAR 1: assigned [mem
> > 0x01100000-0x011fffff] pci 0000:03:00.0: BAR 0: assigned [mem
> > 0x01200000-0x0121ffff] pci 0000:03:00.0: BAR 3: assigned [mem
> > 0x01220000-0x01223fff] pci 0000:03:00.0: BAR 2: assigned [io
> > 0x1000-0x101f] pci 0000:02:01.0: PCI bridge to [bus 03]
> > pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
> > pci 0000:02:01.0: bridge window [mem 0x01100000-0x012fffff]
> > pci 0000:02:02.0: PCI bridge to [bus 04] pci 0000:01:00.0: PCI bridge
> > to [bus 02-04]
> > pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> > pci 0000:01:00.0: bridge window [mem 0x01100000-0x012fffff]
> > pci 0000:00:00.0: PCI bridge to [bus 01-04]
> > pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
> > pci 0000:00:00.0: bridge window [mem 0x01100000-0x012fffff]
> > PCI: enabling device 0000:01:00.0 (0140 -> 0143)
> > PCI: enabling device 0000:02:01.0 (0140 -> 0143)
> > PCI: enabling device 0000:02:02.0 (0140 -> 0143) ...
> > e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
> > e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
> > e1000e 0000:03:00.0: Disabling ASPM L0s L1
> > PCI: enabling device 0000:03:00.0 (0140 -> 0142) e1000e 0000:03:00.0:
> > Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> > e1000e 0000:03:00.0 eth1: registered PHC clock e1000e 0000:03:00.0
> > eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b e1000e
> > 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection e1000e
> > 0000:03:00.0 eth1: MAC: 3, PHY: 8, PBA No: E42641-005
> > igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.3-k
> > igb: Copyright (c) 2007-2013 Intel Corporation.
> > ...
> >
> > ALSA device list:
> > #0: wm8962-audio
> > VFS: Mounted root (nfs filesystem) on device 0:11.
> > devtmpfs: mounted
> > Freeing unused kernel memory: 324K (8082d000 - 8087e000) Kernel panic
> > - not syncing: Attempted to kill init! exitcode=0x0000000b <-- Kernel panic
> here randomly. Same phenomena when the root-fs is located in SD.
>
> Richard,
>
> I would suspect this is the imprecise abort issue. Please see my patch
> (http://thread.gmane.org/gmane.linux.kernel.pci/26159) resolves that for you
> and reply to that thread if so.
>
> I believe that the imprecise abort's only occurs if you have a PCIe switch on
> the bus - is this your topology and if so are you experiencing any issues with
> devices behind the bus that use io regions? If you do have a switch, perhaps
> you can provide me with an 'lspci -v' for comparison.
>
Hi Tim:
Oh, It's great. Your patch can fix my problem.
My own patch-set of pcie driver works well when my Pericom's switch is used.
Thanks a lot.
Yes, it is.
E1000e network card request about 32 bytes IO regions during the bus enumeration procedure,
and it works well behind the my Pericom's switch.
Based on my own pcie driver(not the one up-streamed by Sean),
Here are the log and the lspci -v results I got just now:
imx-pcie 1ffc000.pcie: legacy_irq 155
imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
imx-pcie 1ffc000.pcie: starting to link pcie port.
imx-pcie 1ffc000.pcie: Link up
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers disabled
pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus2: Fast back to back transfers disabled
pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus3: Fast back to back transfers disabled
PCI: bus4: Fast back to back transfers enabled
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:00:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:01:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:02:01.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x0117ffff]
pci 0000:03:00.0: BAR 6: assigned [mem 0x01200000-0x0123ffff pref]
pci 0000:03:00.0: BAR 0: assigned [mem 0x01180000-0x0119ffff]
pci 0000:03:00.0: BAR 3: assigned [mem 0x011a0000-0x011a3fff]
pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
pci 0000:02:01.0: PCI bridge to [bus 03]
pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
pci 0000:02:01.0: bridge window [mem 0x01100000-0x011fffff]
pci 0000:02:01.0: bridge window [mem 0x01200000-0x012fffff pref]
pci 0000:02:02.0: PCI bridge to [bus 04]
pci 0000:01:00.0: PCI bridge to [bus 02-04]
pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:01:00.0: bridge window [mem 0x01100000-0x011fffff]
pci 0000:01:00.0: bridge window [mem 0x01200000-0x012fffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01-04]
pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
pci 0000:00:00.0: bridge window [mem 0x01200000-0x012fffff pref]
PCI: enabling device 0000:01:00.0 (0140 -> 0143)
PCI: enabling device 0000:02:01.0 (0140 -> 0143)
PCI: enabling device 0000:02:02.0 (0140 -> 0143)
...
root at freescale ~$ lspci -v
00:00.0 PCI bridge: Unknown device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
Bus: primary=00, secondary=01, subordinate=04, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 01100000-011fffff
Prefetchable memory behind bridge: 01200000-012fffff
[virtual] Expansion ROM at 01300000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
Capabilities: [70] Express Root Port (Slot-) IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
01:00.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=01, secondary=02, subordinate=04, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 01100000-011fffff
Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
Capabilities: [40] Power Management version 3
Capabilities: [5c] Vital Product Data
Capabilities: [64] Vendor Specific Information
Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
Capabilities: [c0] Express Upstream Port IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [20c] Power Budgeting
Capabilities: [230] Unknown (24)
02:01.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 01100000-011fffff
Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
Capabilities: [40] Power Management version 3
Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [64] Vendor Specific Information
Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [20c] Power Budgeting
Capabilities: [220] Unknown (13)
02:02.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
Capabilities: [40] Power Management version 3
Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [64] Vendor Specific Information
Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [20c] Power Budgeting
Capabilities: [220] Unknown (13)
03:00.0 Ethernet controller: Intel Corporation Unknown device 10d3
Subsystem: Intel Corporation Unknown device a01f
Flags: bus master, fast devsel, latency 0, IRQ 154
Memory at 01180000 (32-bit, non-prefetchable) [size=128K]
Memory at 01100000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1000 [disabled] [size=32]
Memory at 011a0000 (32-bit, non-prefetchable) [size=16K]
[virtual] Expansion ROM at 01200000 [disabled] [size=256K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [e0] Express Endpoint IRQ 0
Capabilities: [a0] MSI-X: Enable- Mask- TabSize=5
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 8b-18-3a-ff-ff-21-1b-00
> Tim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Best Regards
Richard
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-10-18 7:45 ` Zhu Richard-R65037
@ 2013-10-18 15:34 ` Tim Harvey
-1 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-10-18 15:34 UTC (permalink / raw)
To: Zhu Richard-R65037
Cc: Sean Cross, devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Sascha Hauer, Shawn Guo,
Bjorn Helgaas, Marek Vašut, Jingoo Han, Pratyush Anand,
Troy Kisky
On Fri, Oct 18, 2013 at 12:45 AM, Zhu Richard-R65037
<r65037@freescale.com> wrote:
[...]
>
> >
> > Richard,
> >
> > I would suspect this is the imprecise abort issue. Please see my patch
> > (http://thread.gmane.org/gmane.linux.kernel.pci/26159) resolves that for you
> > and reply to that thread if so.
> >
> > I believe that the imprecise abort's only occurs if you have a PCIe switch on
> > the bus - is this your topology and if so are you experiencing any issues with
> > devices behind the bus that use io regions? If you do have a switch, perhaps
> > you can provide me with an 'lspci -v' for comparison.
> >
> Hi Tim:
> Oh, It's great. Your patch can fix my problem.
> My own patch-set of pcie driver works well when my Pericom's switch is used.
> Thanks a lot.
Good to hear! Please reply to that thread and provide an Acked-by and
Tested-by so we can get that patch upstream.
>
> Yes, it is.
> E1000e network card request about 32 bytes IO regions during the bus enumeration procedure,
> and it works well behind the my Pericom's switch.
>
> Based on my own pcie driver(not the one up-streamed by Sean),
How about with the upstream driver? I have 'my own driver' as well
(based on Freescale's BSP) which works, but I'm very interested in
getting this upstream driver to work so we don't have to keep
maintaining our own drivers. Can you please test with this upstream
driver?
> Here are the log and the lspci -v results I got just now:
>
> imx-pcie 1ffc000.pcie: legacy_irq 155
> imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
> imx-pcie 1ffc000.pcie: starting to link pcie port.
> imx-pcie 1ffc000.pcie: Link up
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> PCI: bus1: Fast back to back transfers disabled
> pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus2: Fast back to back transfers disabled
> pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus3: Fast back to back transfers disabled
> PCI: bus4: Fast back to back transfers enabled
> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> pci 0000:00:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
> pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> pci 0000:01:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
> pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> pci 0000:02:01.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
> pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x0117ffff]
> pci 0000:03:00.0: BAR 6: assigned [mem 0x01200000-0x0123ffff pref]
> pci 0000:03:00.0: BAR 0: assigned [mem 0x01180000-0x0119ffff]
> pci 0000:03:00.0: BAR 3: assigned [mem 0x011a0000-0x011a3fff]
> pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
> pci 0000:02:01.0: PCI bridge to [bus 03]
> pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
> pci 0000:02:01.0: bridge window [mem 0x01100000-0x011fffff]
> pci 0000:02:01.0: bridge window [mem 0x01200000-0x012fffff pref]
> pci 0000:02:02.0: PCI bridge to [bus 04]
> pci 0000:01:00.0: PCI bridge to [bus 02-04]
> pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:01:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci 0000:01:00.0: bridge window [mem 0x01200000-0x012fffff pref]
> pci 0000:00:00.0: PCI bridge to [bus 01-04]
> pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci 0000:00:00.0: bridge window [mem 0x01200000-0x012fffff pref]
> PCI: enabling device 0000:01:00.0 (0140 -> 0143)
> PCI: enabling device 0000:02:01.0 (0140 -> 0143)
> PCI: enabling device 0000:02:02.0 (0140 -> 0143)
> ...
> root@freescale ~$ lspci -v
> 00:00.0 PCI bridge: Unknown device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> Bus: primary=00, secondary=01, subordinate=04, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: 01100000-011fffff
> Prefetchable memory behind bridge: 01200000-012fffff
> [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
> Capabilities: [70] Express Root Port (Slot-) IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
>
> 01:00.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=01, secondary=02, subordinate=04, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: 01100000-011fffff
> Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
> Capabilities: [40] Power Management version 3
> Capabilities: [5c] Vital Product Data
> Capabilities: [64] Vendor Specific Information
> Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [c0] Express Upstream Port IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [20c] Power Budgeting
> Capabilities: [230] Unknown (24)
>
> 02:01.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: 01100000-011fffff
> Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
> Capabilities: [40] Power Management version 3
> Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Capabilities: [64] Vendor Specific Information
> Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [20c] Power Budgeting
> Capabilities: [220] Unknown (13)
>
> 02:02.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
> Capabilities: [40] Power Management version 3
> Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Capabilities: [64] Vendor Specific Information
> Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [20c] Power Budgeting
> Capabilities: [220] Unknown (13)
>
> 03:00.0 Ethernet controller: Intel Corporation Unknown device 10d3
> Subsystem: Intel Corporation Unknown device a01f
> Flags: bus master, fast devsel, latency 0, IRQ 154
> Memory at 01180000 (32-bit, non-prefetchable) [size=128K]
> Memory at 01100000 (32-bit, non-prefetchable) [size=512K]
> I/O ports at 1000 [disabled] [size=32]
> Memory at 011a0000 (32-bit, non-prefetchable) [size=16K]
> [virtual] Expansion ROM at 01200000 [disabled] [size=256K]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Capabilities: [e0] Express Endpoint IRQ 0
> Capabilities: [a0] MSI-X: Enable- Mask- TabSize=5
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 8b-18-3a-ff-ff-21-1b-00
>
The above device does show an io resource but it says its disabled?
I'm not sure what that means, but I'm not convinced you would see the
same issue as I do if the io resource isn't being used.
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-10-18 15:34 ` Tim Harvey
0 siblings, 0 replies; 59+ messages in thread
From: Tim Harvey @ 2013-10-18 15:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 18, 2013 at 12:45 AM, Zhu Richard-R65037
<r65037@freescale.com> wrote:
[...]
>
> >
> > Richard,
> >
> > I would suspect this is the imprecise abort issue. Please see my patch
> > (http://thread.gmane.org/gmane.linux.kernel.pci/26159) resolves that for you
> > and reply to that thread if so.
> >
> > I believe that the imprecise abort's only occurs if you have a PCIe switch on
> > the bus - is this your topology and if so are you experiencing any issues with
> > devices behind the bus that use io regions? If you do have a switch, perhaps
> > you can provide me with an 'lspci -v' for comparison.
> >
> Hi Tim:
> Oh, It's great. Your patch can fix my problem.
> My own patch-set of pcie driver works well when my Pericom's switch is used.
> Thanks a lot.
Good to hear! Please reply to that thread and provide an Acked-by and
Tested-by so we can get that patch upstream.
>
> Yes, it is.
> E1000e network card request about 32 bytes IO regions during the bus enumeration procedure,
> and it works well behind the my Pericom's switch.
>
> Based on my own pcie driver(not the one up-streamed by Sean),
How about with the upstream driver? I have 'my own driver' as well
(based on Freescale's BSP) which works, but I'm very interested in
getting this upstream driver to work so we don't have to keep
maintaining our own drivers. Can you please test with this upstream
driver?
> Here are the log and the lspci -v results I got just now:
>
> imx-pcie 1ffc000.pcie: legacy_irq 155
> imx-pcie 1ffc000.pcie: map [mem 0x01ffc000-0x01ffffff]
> imx-pcie 1ffc000.pcie: starting to link pcie port.
> imx-pcie 1ffc000.pcie: Link up
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> PCI: bus1: Fast back to back transfers disabled
> pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus2: Fast back to back transfers disabled
> pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus3: Fast back to back transfers disabled
> PCI: bus4: Fast back to back transfers enabled
> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> pci 0000:00:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01300000-0x0130ffff pref]
> pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> pci 0000:01:00.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
> pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:02:01.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> pci 0000:02:01.0: BAR 9: assigned [mem 0x01200000-0x012fffff pref]
> pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
> pci 0000:03:00.0: BAR 1: assigned [mem 0x01100000-0x0117ffff]
> pci 0000:03:00.0: BAR 6: assigned [mem 0x01200000-0x0123ffff pref]
> pci 0000:03:00.0: BAR 0: assigned [mem 0x01180000-0x0119ffff]
> pci 0000:03:00.0: BAR 3: assigned [mem 0x011a0000-0x011a3fff]
> pci 0000:03:00.0: BAR 2: assigned [io 0x1000-0x101f]
> pci 0000:02:01.0: PCI bridge to [bus 03]
> pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
> pci 0000:02:01.0: bridge window [mem 0x01100000-0x011fffff]
> pci 0000:02:01.0: bridge window [mem 0x01200000-0x012fffff pref]
> pci 0000:02:02.0: PCI bridge to [bus 04]
> pci 0000:01:00.0: PCI bridge to [bus 02-04]
> pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:01:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci 0000:01:00.0: bridge window [mem 0x01200000-0x012fffff pref]
> pci 0000:00:00.0: PCI bridge to [bus 01-04]
> pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci 0000:00:00.0: bridge window [mem 0x01200000-0x012fffff pref]
> PCI: enabling device 0000:01:00.0 (0140 -> 0143)
> PCI: enabling device 0000:02:01.0 (0140 -> 0143)
> PCI: enabling device 0000:02:02.0 (0140 -> 0143)
> ...
> root at freescale ~$ lspci -v
> 00:00.0 PCI bridge: Unknown device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> Bus: primary=00, secondary=01, subordinate=04, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: 01100000-011fffff
> Prefetchable memory behind bridge: 01200000-012fffff
> [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
> Capabilities: [70] Express Root Port (Slot-) IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
>
> 01:00.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=01, secondary=02, subordinate=04, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: 01100000-011fffff
> Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
> Capabilities: [40] Power Management version 3
> Capabilities: [5c] Vital Product Data
> Capabilities: [64] Vendor Specific Information
> Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [c0] Express Upstream Port IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [20c] Power Budgeting
> Capabilities: [230] Unknown (24)
>
> 02:01.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: 01100000-011fffff
> Prefetchable memory behind bridge: 0000000001200000-00000000012fffff
> Capabilities: [40] Power Management version 3
> Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Capabilities: [64] Vendor Specific Information
> Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [20c] Power Budgeting
> Capabilities: [220] Unknown (13)
>
> 02:02.0 PCI bridge: Pericom Semiconductor Unknown device 2303 (rev 05) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
> Capabilities: [40] Power Management version 3
> Capabilities: [4c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Capabilities: [64] Vendor Specific Information
> Capabilities: [b0] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [c0] Express Downstream Port (Slot+) IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [20c] Power Budgeting
> Capabilities: [220] Unknown (13)
>
> 03:00.0 Ethernet controller: Intel Corporation Unknown device 10d3
> Subsystem: Intel Corporation Unknown device a01f
> Flags: bus master, fast devsel, latency 0, IRQ 154
> Memory at 01180000 (32-bit, non-prefetchable) [size=128K]
> Memory at 01100000 (32-bit, non-prefetchable) [size=512K]
> I/O ports at 1000 [disabled] [size=32]
> Memory at 011a0000 (32-bit, non-prefetchable) [size=16K]
> [virtual] Expansion ROM at 01200000 [disabled] [size=256K]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Capabilities: [e0] Express Endpoint IRQ 0
> Capabilities: [a0] MSI-X: Enable- Mask- TabSize=5
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 8b-18-3a-ff-ff-21-1b-00
>
The above device does show an io resource but it says its disabled?
I'm not sure what that means, but I'm not convinced you would see the
same issue as I do if the io resource isn't being used.
Tim
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-10-18 15:34 ` Tim Harvey
(?)
@ 2013-11-05 17:35 ` Sinan Akman
2013-11-05 20:28 ` Bjorn Helgaas
-1 siblings, 1 reply; 59+ messages in thread
From: Sinan Akman @ 2013-11-05 17:35 UTC (permalink / raw)
To: Tim Harvey
Cc: Zhu Richard-R65037, Marek Vašut, devicetree@vger.kernel.org,
Pratyush Anand, linux-pci@vger.kernel.org, Sascha Hauer,
Jingoo Han, Troy Kisky, Bjorn Helgaas, Sean Cross, Shawn Guo,
linux-arm-kernel@lists.infradead.org
On 10/18/2013 11:34 AM, Tim Harvey wrote:
> On Fri, Oct 18, 2013 at 12:45 AM, Zhu Richard-R65037
> [...]
> How about with the upstream driver? I have 'my own driver' as well
> (based on Freescale's BSP) which works, but I'm very interested in
> getting this upstream driver to work so we don't have to keep
> maintaining our own drivers. Can you please test with this upstream
> driver?
Tim, Sean what is the status of this patch ? Is it part of any tree
already ? I'd like to test few things.
Thanks
Sinan Akman
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-05 17:35 ` Sinan Akman
@ 2013-11-05 20:28 ` Bjorn Helgaas
0 siblings, 0 replies; 59+ messages in thread
From: Bjorn Helgaas @ 2013-11-05 20:28 UTC (permalink / raw)
To: Sinan Akman
Cc: Tim Harvey, Zhu Richard-R65037, Marek Vašut,
devicetree@vger.kernel.org, Pratyush Anand,
linux-pci@vger.kernel.org, Sascha Hauer, Jingoo Han, Troy Kisky,
Sean Cross, Shawn Guo, linux-arm-kernel@lists.infradead.org
On Tue, Nov 5, 2013 at 10:35 AM, Sinan Akman <sinan@writeme.com> wrote:
> Tim, Sean what is the status of this patch ? Is it part of any tree
> already ? I'd like to test few things.
This patch is in my "next" branch and will be merged into Linus' tree
during the v3.13 merge window (probably next week). It's also in the
linux-next tree.
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=bb38919ec56e0758c3ae56dfc091dcde1391353e
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
@ 2013-11-05 20:28 ` Bjorn Helgaas
0 siblings, 0 replies; 59+ messages in thread
From: Bjorn Helgaas @ 2013-11-05 20:28 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 5, 2013 at 10:35 AM, Sinan Akman <sinan@writeme.com> wrote:
> Tim, Sean what is the status of this patch ? Is it part of any tree
> already ? I'd like to test few things.
This patch is in my "next" branch and will be merged into Linus' tree
during the v3.13 merge window (probably next week). It's also in the
linux-next tree.
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=bb38919ec56e0758c3ae56dfc091dcde1391353e
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-05 20:28 ` Bjorn Helgaas
(?)
@ 2013-11-23 17:27 ` Harro Haan
2013-11-26 2:20 ` Richard Zhu
-1 siblings, 1 reply; 59+ messages in thread
From: Harro Haan @ 2013-11-23 17:27 UTC (permalink / raw)
To: linux-arm-kernel
On 5 November 2013 21:28, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Tue, Nov 5, 2013 at 10:35 AM, Sinan Akman <sinan@writeme.com> wrote:
>> Tim, Sean what is the status of this patch ? Is it part of any tree
>> already ? I'd like to test few things.
>
> This patch is in my "next" branch and will be merged into Linus' tree
> during the v3.13 merge window (probably next week). It's also in the
> linux-next tree.
>
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=bb38919ec56e0758c3ae56dfc091dcde1391353e
Does anybody know how to test this on a SabreSD board?
I have added the following to imx6qdl-sabresd.dtsi:
---------------------
@@ -166,10 +166,21 @@
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog>;
+ pcie {
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x80000000
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000
+ MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20 0x80000000
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x80000000
+ >;
+ };
+ };
+
hog {
pinctrl_hog: hoggrp {
fsl,pins = <
MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x80000000
MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x80000000
@@ -185,10 +196,20 @@
>;
};
};
};
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio7 12 0>;
+ power-on-gpio = <&gpio3 19 0>;
+ wake-up-gpio = <&gpio5 20 0>;
+ disable-gpio = <&gpio4 14 0>;
+ status = "okay";
+};
+
&ldb {
status = "okay";
lvds-channel at 1 {
fsl,data-mapping = "spwg";
---------------------
But during booting it says:
imx6q-pcie 1ffc000.pcie: phy link never came up
Thanks in advance,
Harro
Note: the e1000e network card does work with the FSL imx_3.0.35 kernel
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-23 17:27 ` Harro Haan
@ 2013-11-26 2:20 ` Richard Zhu
2013-11-26 4:31 ` Shawn Guo
0 siblings, 1 reply; 59+ messages in thread
From: Richard Zhu @ 2013-11-26 2:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Harro:
> -----Original Message-----
> From: Harro Haan [mailto:hrhaan at gmail.com]
> Sent: Sunday, November 24, 2013 1:28 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Sinan Akman; Zhu Richard-R65037; Marek Va?ut; Pratyush Anand; Tim Harvey;
> Jingoo Han; Troy Kisky; Sean Cross; Shawn Guo; Sascha Hauer; Bjorn Helgaas
> Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
>
> On 5 November 2013 21:28, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Tue, Nov 5, 2013 at 10:35 AM, Sinan Akman <sinan@writeme.com> wrote:
> >> Tim, Sean what is the status of this patch ? Is it part of any tree
> >> already ? I'd like to test few things.
> >
> > This patch is in my "next" branch and will be merged into Linus' tree
> > during the v3.13 merge window (probably next week). It's also in the
> > linux-next tree.
> >
> > http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=
> > next&id=bb38919ec56e0758c3ae56dfc091dcde1391353e
>
> Does anybody know how to test this on a SabreSD board?
>
> I have added the following to imx6qdl-sabresd.dtsi:
> ---------------------
> @@ -166,10 +166,21 @@
>
> &iomuxc {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_hog>;
>
> + pcie {
> + pinctrl_pcie: pciegrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x80000000
> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000
> + MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20 0x80000000
> + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x80000000
> + >;
> + };
> + };
> +
> hog {
> pinctrl_hog: hoggrp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x80000000
> MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x80000000
> @@ -185,10 +196,20 @@
> >;
> };
> };
> };
>
> +&pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie>;
> + reset-gpio = <&gpio7 12 0>;
> + power-on-gpio = <&gpio3 19 0>;
> + wake-up-gpio = <&gpio5 20 0>;
> + disable-gpio = <&gpio4 14 0>;
> + status = "okay";
> +};
> +
> &ldb {
> status = "okay";
>
> lvds-channel at 1 {
> fsl,data-mapping = "spwg";
> ---------------------
>
> But during booting it says:
> imx6q-pcie 1ffc000.pcie: phy link never came up
>
> Thanks in advance,
>
> Harro
[Richard] Regarding to my experience, based on Shawn's(http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git)
for-next branch, cherry-pick the imx6-pcie patch set merged on host-imx6 branch on PCIe git-repos.
Re-setup the clock configurations refer to your kernel baseline.
Here is one example at my local git-repos site, hope it is helpful.
-------------------------------------------------
pcie: switch to upstreamed pcie driver
Based on community patch-set, re-setup pcie driver on
imx6 platforms.
* re-fine the pcie clks.
* add the pcie support in dts files.
Signed-off-by: Richard Zhu <r65037@freescale.com>
---
.../devicetree/bindings/clock/imx6q-clock.txt | 6 +++---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4 ++++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 7 +++++++
arch/arm/boot/dts/imx6qdl.dtsi | 4 ++--
arch/arm/mach-imx/Kconfig | 2 ++
arch/arm/mach-imx/clk-imx6q.c | 17 ++++++++++++++++-
6 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 02ad157..b289100 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -220,9 +220,9 @@ clocks and IDs.
ldb_di0_div_sel 207
ldb_di1_div_sel 208
pll4_audio_div 209
- pcie_dummy1 210
- pcie_dummy2 211
- pcie_dummy3 212
+ lvds1_sel 210
+ lvds1_in 211
+ lvds1_out 212
caam_mem 213
caam_aclk 214
caam_ipg 215
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index bbd4bfb..e011ba7 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -590,6 +590,10 @@
status = "okay";
};
+&pcie {
+ status = "okay";
+};
+
&pwm3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm3_1>;
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 4de08aa..5236ff6 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -611,6 +611,13 @@
status = "okay";
};
+&pcie {
+ power-on-gpio = <&gpio3 19 0>;
+ reset-gpio = <&gpio7 12 0>;
+ status = "okay";
+};
+
+
&pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1_1>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index c2f7fd5..1e40164 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -128,8 +128,8 @@
0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
num-lanes = <1>;
interrupts = <0 123 0x04>;
- clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>;
- clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
+ clocks = <&clks 189>, <&clks 187>, <&clks 144>, <&clks 212>;
+ clock-names = "pcie_ref_125m", "sata_ref_100m", "pcie_axi", "lvds_gate";
status = "disabled";
};
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 0633cf9..c26aac0 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -809,6 +809,8 @@ config SOC_IMX6Q
select HAVE_IMX_SRC
select HAVE_SMP
select MFD_SYSCON
+ select MIGHT_HAVE_PCI
+ select PCI_DOMAINS if PCI
select PINCTRL
select PINCTRL_IMX6Q
select PL310_ERRATA_588369 if CACHE_PL310
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 0923ff8..96e3198 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -71,6 +71,8 @@ static const char *cko2_sels[] = {
"uart_serial", "spdif", "asrc", "hsi_tx",
};
static const char *cko_sels[] = { "cko1", "cko2", };
+static const char *lvds_sels[] = { "arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy", "pll5_video_div",
+ "dummy", "dummy", "pcie_ref", "sata_ref", "usbphy1", "usbphy2", };
enum mx6q_clks {
dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
@@ -107,7 +109,7 @@ enum mx6q_clks {
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, gpt_3m, video_27m,
ldb_di0_div_7, ldb_di1_div_7, ldb_di0_div_sel, ldb_di1_div_sel,
- pll4_audio_div, pcie_dummy1, pcie_dummy2, pcie_dummy3, caam_mem, caam_aclk,
+ pll4_audio_div, lvds1_sel, lvds1_in, lvds1_out, caam_mem, caam_aclk,
caam_ipg, epit1, epit2, tzasc2, clk_max
};
@@ -173,6 +175,9 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[pll6_enet] = imx_clk_pllv3(IMX_PLLV3_ENET, "pll6_enet", "osc", base + 0xe0, 0x3, false);
clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7_usb_host", "osc", base + 0x20, 0x3, false);
+ /* name reg shift width parent_names num_parents */
+ clk[lvds1_sel] = imx_clk_mux("lvds1_sel", base + 0x160, 0, 5, lvds_sels, ARRAY_SIZE(lvds_sels));
+
/*
* Bit 20 is the reserved and read-only bit, we do this only for:
* - Do nothing for usbphy clk_enable/disable
@@ -191,6 +196,9 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[sata_ref] = imx_clk_fixed_factor("sata_ref", "pll6_enet", 1, 5);
clk[pcie_ref] = imx_clk_fixed_factor("pcie_ref", "pll6_enet", 1, 4);
+ /* NOTICE: The gate of the lvds1 in/out is used to select the clk direction */
+ clk[lvds1_in] = imx_clk_gate("lvds1_in", NULL, base + 0x160, 12);
+ clk[lvds1_out] = imx_clk_gate("lvds1_out", "lvds1_sel", base + 0x160, 10);
clk[sata_ref_100m] = imx_clk_gate("sata_ref_100m", "sata_ref", base + 0xe0, 20);
clk[pcie_ref_125m] = imx_clk_gate("pcie_ref_125m", "pcie_ref", base + 0xe0, 19);
@@ -482,6 +490,13 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
*/
clk_set_parent(clk[enfc_sel], clk[pll2_pfd2_396m]);
+ /* Set the parent clks of PCIe lvds1 and pcie_axi to be sata ref, axi */
+ if (clk_set_parent(clk[lvds1_sel], clk[sata_ref]))
+ pr_err("Failed to set PCIe bus parent clk.\n");
+ if (clk_set_parent(clk[pcie_axi_sel], clk[axi]))
+ pr_err("Failed to set PCIe parent clk.\n");
+
+
/* gpu clock initilazation */
clk_set_parent(clk[gpu3d_shader_sel], clk[pll2_pfd1_594m]);
clk_set_rate(clk[gpu3d_shader], 594000000);
>
> Note: the e1000e network card does work with the FSL imx_3.0.35 kernel
Best Regards
Richard Zhu
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-26 2:20 ` Richard Zhu
@ 2013-11-26 4:31 ` Shawn Guo
2013-11-26 4:40 ` Richard Zhu
2013-11-26 6:04 ` Richard Zhu
0 siblings, 2 replies; 59+ messages in thread
From: Shawn Guo @ 2013-11-26 4:31 UTC (permalink / raw)
To: linux-arm-kernel
Richard,
On Tue, Nov 26, 2013 at 02:20:15AM +0000, Richard Zhu wrote:
> [Richard] Regarding to my experience, based on Shawn's(http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git)
> for-next branch, cherry-pick the imx6-pcie patch set merged on host-imx6 branch on PCIe git-repos.
Since v3.13-rc1 is out there with pci-imx6 driver merged, can you please
give it a test to see what's missing there at platform level to get PCIe
support on imx6q-sabresd? That will be easy for Harro to follow.
Shawn
> Re-setup the clock configurations refer to your kernel baseline.
> Here is one example at my local git-repos site, hope it is helpful.
> -------------------------------------------------
> pcie: switch to upstreamed pcie driver
>
> Based on community patch-set, re-setup pcie driver on
> imx6 platforms.
> * re-fine the pcie clks.
> * add the pcie support in dts files.
>
> Signed-off-by: Richard Zhu <r65037@freescale.com>
> ---
> .../devicetree/bindings/clock/imx6q-clock.txt | 6 +++---
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4 ++++
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 7 +++++++
> arch/arm/boot/dts/imx6qdl.dtsi | 4 ++--
> arch/arm/mach-imx/Kconfig | 2 ++
> arch/arm/mach-imx/clk-imx6q.c | 17 ++++++++++++++++-
> 6 files changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> index 02ad157..b289100 100644
> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> @@ -220,9 +220,9 @@ clocks and IDs.
> ldb_di0_div_sel 207
> ldb_di1_div_sel 208
> pll4_audio_div 209
> - pcie_dummy1 210
> - pcie_dummy2 211
> - pcie_dummy3 212
> + lvds1_sel 210
> + lvds1_in 211
> + lvds1_out 212
> caam_mem 213
> caam_aclk 214
> caam_ipg 215
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index bbd4bfb..e011ba7 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -590,6 +590,10 @@
> status = "okay";
> };
>
> +&pcie {
> + status = "okay";
> +};
> +
> &pwm3 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pwm3_1>;
> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> index 4de08aa..5236ff6 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -611,6 +611,13 @@
> status = "okay";
> };
>
> +&pcie {
> + power-on-gpio = <&gpio3 19 0>;
> + reset-gpio = <&gpio7 12 0>;
> + status = "okay";
> +};
> +
> +
> &pwm1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pwm1_1>;
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index c2f7fd5..1e40164 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -128,8 +128,8 @@
> 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
> num-lanes = <1>;
> interrupts = <0 123 0x04>;
> - clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>;
> - clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
> + clocks = <&clks 189>, <&clks 187>, <&clks 144>, <&clks 212>;
> + clock-names = "pcie_ref_125m", "sata_ref_100m", "pcie_axi", "lvds_gate";
> status = "disabled";
> };
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 0633cf9..c26aac0 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -809,6 +809,8 @@ config SOC_IMX6Q
> select HAVE_IMX_SRC
> select HAVE_SMP
> select MFD_SYSCON
> + select MIGHT_HAVE_PCI
> + select PCI_DOMAINS if PCI
> select PINCTRL
> select PINCTRL_IMX6Q
> select PL310_ERRATA_588369 if CACHE_PL310
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index 0923ff8..96e3198 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -71,6 +71,8 @@ static const char *cko2_sels[] = {
> "uart_serial", "spdif", "asrc", "hsi_tx",
> };
> static const char *cko_sels[] = { "cko1", "cko2", };
> +static const char *lvds_sels[] = { "arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy", "pll5_video_div",
> + "dummy", "dummy", "pcie_ref", "sata_ref", "usbphy1", "usbphy2", };
>
> enum mx6q_clks {
> dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
> @@ -107,7 +109,7 @@ enum mx6q_clks {
> usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
> spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, gpt_3m, video_27m,
> ldb_di0_div_7, ldb_di1_div_7, ldb_di0_div_sel, ldb_di1_div_sel,
> - pll4_audio_div, pcie_dummy1, pcie_dummy2, pcie_dummy3, caam_mem, caam_aclk,
> + pll4_audio_div, lvds1_sel, lvds1_in, lvds1_out, caam_mem, caam_aclk,
> caam_ipg, epit1, epit2, tzasc2, clk_max
> };
>
> @@ -173,6 +175,9 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> clk[pll6_enet] = imx_clk_pllv3(IMX_PLLV3_ENET, "pll6_enet", "osc", base + 0xe0, 0x3, false);
> clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7_usb_host", "osc", base + 0x20, 0x3, false);
>
> + /* name reg shift width parent_names num_parents */
> + clk[lvds1_sel] = imx_clk_mux("lvds1_sel", base + 0x160, 0, 5, lvds_sels, ARRAY_SIZE(lvds_sels));
> +
> /*
> * Bit 20 is the reserved and read-only bit, we do this only for:
> * - Do nothing for usbphy clk_enable/disable
> @@ -191,6 +196,9 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
>
> clk[sata_ref] = imx_clk_fixed_factor("sata_ref", "pll6_enet", 1, 5);
> clk[pcie_ref] = imx_clk_fixed_factor("pcie_ref", "pll6_enet", 1, 4);
> + /* NOTICE: The gate of the lvds1 in/out is used to select the clk direction */
> + clk[lvds1_in] = imx_clk_gate("lvds1_in", NULL, base + 0x160, 12);
> + clk[lvds1_out] = imx_clk_gate("lvds1_out", "lvds1_sel", base + 0x160, 10);
>
> clk[sata_ref_100m] = imx_clk_gate("sata_ref_100m", "sata_ref", base + 0xe0, 20);
> clk[pcie_ref_125m] = imx_clk_gate("pcie_ref_125m", "pcie_ref", base + 0xe0, 19);
> @@ -482,6 +490,13 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> */
> clk_set_parent(clk[enfc_sel], clk[pll2_pfd2_396m]);
>
> + /* Set the parent clks of PCIe lvds1 and pcie_axi to be sata ref, axi */
> + if (clk_set_parent(clk[lvds1_sel], clk[sata_ref]))
> + pr_err("Failed to set PCIe bus parent clk.\n");
> + if (clk_set_parent(clk[pcie_axi_sel], clk[axi]))
> + pr_err("Failed to set PCIe parent clk.\n");
> +
> +
> /* gpu clock initilazation */
> clk_set_parent(clk[gpu3d_shader_sel], clk[pll2_pfd1_594m]);
> clk_set_rate(clk[gpu3d_shader], 594000000);
>
>
> >
> > Note: the e1000e network card does work with the FSL imx_3.0.35 kernel
>
> Best Regards
> Richard Zhu
>
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-26 4:31 ` Shawn Guo
@ 2013-11-26 4:40 ` Richard Zhu
2013-11-26 6:04 ` Richard Zhu
1 sibling, 0 replies; 59+ messages in thread
From: Richard Zhu @ 2013-11-26 4:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shawn:
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo at linaro.org]
> Sent: Tuesday, November 26, 2013 12:32 PM
> To: Zhu Richard-R65037
> Cc: Harro Haan; linux-arm-kernel at lists.infradead.org; Sinan Akman; Marek Va?ut;
> Pratyush Anand; Tim Harvey; Jingoo Han; Troy Kisky; Sean Cross; Sascha Hauer;
> Bjorn Helgaas
> Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
>
> Richard,
>
> On Tue, Nov 26, 2013 at 02:20:15AM +0000, Richard Zhu wrote:
> > [Richard] Regarding to my experience, based on
> > Shawn's(http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git)
> > for-next branch, cherry-pick the imx6-pcie patch set merged on host-imx6
> branch on PCIe git-repos.
>
> Since v3.13-rc1 is out there with pci-imx6 driver merged, can you please give
> it a test to see what's missing there at platform level to get PCIe support on
> imx6q-sabresd? That will be easy for Harro to follow.
>
> Shawn
[Richard] Ok, no problem, I'm preparing the test, would post the status later.
>
> > Re-setup the clock configurations refer to your kernel baseline.
> > Here is one example at my local git-repos site, hope it is helpful.
> > -------------------------------------------------
> > pcie: switch to upstreamed pcie driver
> >
> > Based on community patch-set, re-setup pcie driver on
> > imx6 platforms.
> > * re-fine the pcie clks.
> > * add the pcie support in dts files.
> >
> > Signed-off-by: Richard Zhu <r65037@freescale.com>
> > ---
> > .../devicetree/bindings/clock/imx6q-clock.txt | 6 +++---
> > arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4 ++++
> > arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 7 +++++++
> > arch/arm/boot/dts/imx6qdl.dtsi | 4 ++--
> > arch/arm/mach-imx/Kconfig | 2 ++
> > arch/arm/mach-imx/clk-imx6q.c | 17 ++++++++++++++++-
> > 6 files changed, 34 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > index 02ad157..b289100 100644
> > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > @@ -220,9 +220,9 @@ clocks and IDs.
> > ldb_di0_div_sel 207
> > ldb_di1_div_sel 208
> > pll4_audio_div 209
> > - pcie_dummy1 210
> > - pcie_dummy2 211
> > - pcie_dummy3 212
> > + lvds1_sel 210
> > + lvds1_in 211
> > + lvds1_out 212
> > caam_mem 213
> > caam_aclk 214
> > caam_ipg 215
> > diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> > b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> > index bbd4bfb..e011ba7 100644
> > --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> > @@ -590,6 +590,10 @@
> > status = "okay";
> > };
> >
> > +&pcie {
> > + status = "okay";
> > +};
> > +
> > &pwm3 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_pwm3_1>;
> > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > index 4de08aa..5236ff6 100644
> > --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > @@ -611,6 +611,13 @@
> > status = "okay";
> > };
> >
> > +&pcie {
> > + power-on-gpio = <&gpio3 19 0>;
> > + reset-gpio = <&gpio7 12 0>;
> > + status = "okay";
> > +};
> > +
> > +
> > &pwm1 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_pwm1_1>;
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi
> > b/arch/arm/boot/dts/imx6qdl.dtsi index c2f7fd5..1e40164 100644
> > --- a/arch/arm/boot/dts/imx6qdl.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> > @@ -128,8 +128,8 @@
> > 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /*
> non-prefetchable memory */
> > num-lanes = <1>;
> > interrupts = <0 123 0x04>;
> > - clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>;
> > - clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate",
> "pcie_axi";
> > + clocks = <&clks 189>, <&clks 187>, <&clks 144>, <&clks 212>;
> > + clock-names = "pcie_ref_125m", "sata_ref_100m", "pcie_axi",
> > +"lvds_gate";
> > status = "disabled";
> > };
> >
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index 0633cf9..c26aac0 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -809,6 +809,8 @@ config SOC_IMX6Q
> > select HAVE_IMX_SRC
> > select HAVE_SMP
> > select MFD_SYSCON
> > + select MIGHT_HAVE_PCI
> > + select PCI_DOMAINS if PCI
> > select PINCTRL
> > select PINCTRL_IMX6Q
> > select PL310_ERRATA_588369 if CACHE_PL310 diff --git
> > a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c index
> > 0923ff8..96e3198 100644
> > --- a/arch/arm/mach-imx/clk-imx6q.c
> > +++ b/arch/arm/mach-imx/clk-imx6q.c
> > @@ -71,6 +71,8 @@ static const char *cko2_sels[] = {
> > "uart_serial", "spdif", "asrc", "hsi_tx", }; static const char
> > *cko_sels[] = { "cko1", "cko2", };
> > +static const char *lvds_sels[] = { "arm", "pll1_sys", "dummy", "dummy",
> "dummy", "dummy", "dummy", "pll5_video_div",
> > + "dummy", "dummy", "pcie_ref", "sata_ref", "usbphy1",
> > +"usbphy2", };
> >
> > enum mx6q_clks {
> > dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m,
> > pll2_pfd2_396m, @@ -107,7 +109,7 @@ enum mx6q_clks {
> > usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
> > spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, gpt_3m, video_27m,
> > ldb_di0_div_7, ldb_di1_div_7, ldb_di0_div_sel, ldb_di1_div_sel,
> > - pll4_audio_div, pcie_dummy1, pcie_dummy2, pcie_dummy3, caam_mem,
> caam_aclk,
> > + pll4_audio_div, lvds1_sel, lvds1_in, lvds1_out, caam_mem, caam_aclk,
> > caam_ipg, epit1, epit2, tzasc2, clk_max };
> >
> > @@ -173,6 +175,9 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
> > clk[pll6_enet] = imx_clk_pllv3(IMX_PLLV3_ENET, "pll6_enet", "osc",
> base + 0xe0, 0x3, false);
> > clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7_usb_host",
> "osc", base + 0x20, 0x3, false);
> >
> > + /* name reg shift width
> parent_names num_parents */
> > + clk[lvds1_sel] = imx_clk_mux("lvds1_sel", base + 0x160, 0, 5,
> lvds_sels, ARRAY_SIZE(lvds_sels));
> > +
> > /*
> > * Bit 20 is the reserved and read-only bit, we do this only for:
> > * - Do nothing for usbphy clk_enable/disable @@ -191,6 +196,9 @@
> > static void __init imx6q_clocks_init(struct device_node *ccm_node)
> >
> > clk[sata_ref] = imx_clk_fixed_factor("sata_ref", "pll6_enet", 1, 5);
> > clk[pcie_ref] = imx_clk_fixed_factor("pcie_ref", "pll6_enet", 1, 4);
> > + /* NOTICE: The gate of the lvds1 in/out is used to select the clk
> direction */
> > + clk[lvds1_in] = imx_clk_gate("lvds1_in", NULL, base + 0x160, 12);
> > + clk[lvds1_out] = imx_clk_gate("lvds1_out", "lvds1_sel", base +
> > +0x160, 10);
> >
> > clk[sata_ref_100m] = imx_clk_gate("sata_ref_100m", "sata_ref", base +
> 0xe0, 20);
> > clk[pcie_ref_125m] = imx_clk_gate("pcie_ref_125m", "pcie_ref", base
> > + 0xe0, 19); @@ -482,6 +490,13 @@ static void __init
> imx6q_clocks_init(struct device_node *ccm_node)
> > */
> > clk_set_parent(clk[enfc_sel], clk[pll2_pfd2_396m]);
> >
> > + /* Set the parent clks of PCIe lvds1 and pcie_axi to be sata ref, axi */
> > + if (clk_set_parent(clk[lvds1_sel], clk[sata_ref]))
> > + pr_err("Failed to set PCIe bus parent clk.\n");
> > + if (clk_set_parent(clk[pcie_axi_sel], clk[axi]))
> > + pr_err("Failed to set PCIe parent clk.\n");
> > +
> > +
> > /* gpu clock initilazation */
> > clk_set_parent(clk[gpu3d_shader_sel], clk[pll2_pfd1_594m]);
> > clk_set_rate(clk[gpu3d_shader], 594000000);
> >
> >
> > >
> > > Note: the e1000e network card does work with the FSL imx_3.0.35
> > > kernel
> >
> > Best Regards
> > Richard Zhu
> >
Best Regards
Richard Zhu
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-26 4:31 ` Shawn Guo
2013-11-26 4:40 ` Richard Zhu
@ 2013-11-26 6:04 ` Richard Zhu
2013-11-26 7:26 ` Shawn Guo
1 sibling, 1 reply; 59+ messages in thread
From: Richard Zhu @ 2013-11-26 6:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shawn & Harro:
> -----Original Message-----
> From: Zhu Richard-R65037
> Sent: Tuesday, November 26, 2013 12:36 PM
> To: 'Shawn Guo'
> Cc: Harro Haan; linux-arm-kernel at lists.infradead.org; Sinan Akman; Marek Va?ut;
> Pratyush Anand; Tim Harvey; Jingoo Han; Troy Kisky; Sean Cross; Sascha Hauer;
> Bjorn Helgaas
> Subject: RE: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
>
> Hi Shawn:
>
>
> > -----Original Message-----
> > From: Shawn Guo [mailto:shawn.guo at linaro.org]
> > Sent: Tuesday, November 26, 2013 12:32 PM
> > To: Zhu Richard-R65037
> > Cc: Harro Haan; linux-arm-kernel at lists.infradead.org; Sinan Akman;
> > Marek Va?ut; Pratyush Anand; Tim Harvey; Jingoo Han; Troy Kisky; Sean
> > Cross; Sascha Hauer; Bjorn Helgaas
> > Subject: Re: [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe
> > controller
> >
> > Richard,
> >
> > On Tue, Nov 26, 2013 at 02:20:15AM +0000, Richard Zhu wrote:
<...>
> >
> > Since v3.13-rc1 is out there with pci-imx6 driver merged, can you
> > please give it a test to see what's missing there at platform level to
> > get PCIe support on imx6q-sabresd? That will be easy for Harro to follow.
> >
> > Shawn
> [Richard] Ok, no problem, I'm preparing the test, would post the status later.
>
[Richard] Based on the tag " pci-v3.13-fixes-1" on pci git-repos, imx6 pcie had been tested on imx6 sabresd board.
The pcie works after enable pcie support in imx6qdl-sabresd.dtsi file.
Patch:
Author: Richard Zhu <r65037@freescale.com>
Date: Tue Nov 26 13:29:24 2013 +0800
pcie: imx6: enable pcie on imx6qdl sabresd board
Add pcie device tree node into imx6qdl dts file,
enable pcie on imx6qdl sabresd board
Signed-off-by: Richard Zhu <r65037@freescale.com>
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index e75e11b..b821f87 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -212,6 +212,12 @@
};
};
+&pcie {
+ power-on-gpio = <&gpio3 19 0>;
+ reset-gpio = <&gpio7 12 0>;
+ status = "okay";
+};
+
&pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0_1>;
LOGs when e1000e nic is used:
uname -a
Linux freescale 3.12.0+ #49 SMP Tue Nov 26 13:26:03 CST 2013 armv7l GNU/Linux
root at freescale ~$ lspci -v
00:00.0 PCI bridge: Unknown device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 01100000-011fffff
Prefetchable memory behind bridge: 01200000-012fffff
[virtual] Expansion ROM at 01300000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
Capabilities: [70] Express Root Port (Slot-) IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
01:00.0 Ethernet controller: Intel Corporation Unknown device 10d3
Subsystem: Intel Corporation Unknown device a01f
Flags: bus master, fast devsel, latency 0, IRQ 155
Memory at 01180000 (32-bit, non-prefetchable) [size=128K]
Memory at 01100000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1000 [disabled] [size=32]
Memory at 011a0000 (32-bit, non-prefetchable) [size=16K]
[virtual] Expansion ROM at 01200000 [disabled] [size=256K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [e0] Express Endpoint IRQ 0
Capabilities: [a0] MSI-X: Enable- Mask- TabSize=5
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 8b-18-3a-ff-ff-21-1b-00
> >
<...>
>
> Best Regards
> Richard Zhu
[Richard]
Best Regards
Richard Zhu
^ permalink raw reply related [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-26 6:04 ` Richard Zhu
@ 2013-11-26 7:26 ` Shawn Guo
2013-11-27 16:11 ` Harro Haan
0 siblings, 1 reply; 59+ messages in thread
From: Shawn Guo @ 2013-11-26 7:26 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 26, 2013 at 06:04:16AM +0000, Richard Zhu wrote:
> [Richard] Based on the tag " pci-v3.13-fixes-1" on pci git-repos, imx6 pcie had been tested on imx6 sabresd board.
>
> The pcie works after enable pcie support in imx6qdl-sabresd.dtsi file.
Great, thanks, Richard.
Shawn
>
> Patch:
> Author: Richard Zhu <r65037@freescale.com>
> Date: Tue Nov 26 13:29:24 2013 +0800
>
> pcie: imx6: enable pcie on imx6qdl sabresd board
>
> Add pcie device tree node into imx6qdl dts file,
> enable pcie on imx6qdl sabresd board
>
> Signed-off-by: Richard Zhu <r65037@freescale.com>
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> index e75e11b..b821f87 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -212,6 +212,12 @@
> };
> };
>
> +&pcie {
> + power-on-gpio = <&gpio3 19 0>;
> + reset-gpio = <&gpio7 12 0>;
> + status = "okay";
> +};
> +
> &pwm1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pwm0_1>;
>
> LOGs when e1000e nic is used:
> uname -a
> Linux freescale 3.12.0+ #49 SMP Tue Nov 26 13:26:03 CST 2013 armv7l GNU/Linux
> root at freescale ~$ lspci -v
> 00:00.0 PCI bridge: Unknown device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: 01100000-011fffff
> Prefetchable memory behind bridge: 01200000-012fffff
> [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
> Capabilities: [70] Express Root Port (Slot-) IRQ 0
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
>
> 01:00.0 Ethernet controller: Intel Corporation Unknown device 10d3
> Subsystem: Intel Corporation Unknown device a01f
> Flags: bus master, fast devsel, latency 0, IRQ 155
> Memory at 01180000 (32-bit, non-prefetchable) [size=128K]
> Memory at 01100000 (32-bit, non-prefetchable) [size=512K]
> I/O ports at 1000 [disabled] [size=32]
> Memory at 011a0000 (32-bit, non-prefetchable) [size=16K]
> [virtual] Expansion ROM at 01200000 [disabled] [size=256K]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Capabilities: [e0] Express Endpoint IRQ 0
> Capabilities: [a0] MSI-X: Enable- Mask- TabSize=5
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 8b-18-3a-ff-ff-21-1b-00
> > >
> <...>
> >
> > Best Regards
> > Richard Zhu
>
> [Richard]
> Best Regards
> Richard Zhu
>
>
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-26 7:26 ` Shawn Guo
@ 2013-11-27 16:11 ` Harro Haan
2013-11-27 19:06 ` Marek Vasut
0 siblings, 1 reply; 59+ messages in thread
From: Harro Haan @ 2013-11-27 16:11 UTC (permalink / raw)
To: linux-arm-kernel
On 26 November 2013 08:26, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Tue, Nov 26, 2013 at 06:04:16AM +0000, Richard Zhu wrote:
>> [Richard] Based on the tag " pci-v3.13-fixes-1" on pci git-repos, imx6 pcie had been tested on imx6 sabresd board.
>>
>> The pcie works after enable pcie support in imx6qdl-sabresd.dtsi file.
>
> Great, thanks, Richard.
>
> Shawn
>
Thanks Richard,
TC1: The following does NOT work with the mainline Linux tree on my
SabreSD with PCIe e1000e network card:
$ git reset --hard v3.13-rc1
$ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
supplied by Richard Zhu
result: "phy link never came up"
TC2: But the following does work with the mainline Linux tree:
$ git reset --hard d95d3d53c7ef85ec0dc87db63aece18212c337b0 # HEAD is
now at d95d3d5 Merge branch 'pci/host-imx6' into next (just a few
commits after v3.12-rc2)
$ git cherry-pick 1c4bfb9bd842f09318bc2fa37c1ee0d68bb4e8cb # [master
f283273] PCI: imx6: Remove redundant dev_err() in imx6_pcie_probe()
$ git cherry-pick 01ee0c70b5b935135dbe7fbf48115d9f16348474 # [master
5c93c84] PCI: imx6: Fix imprecise abort handler
$ git cherry-pick 5dcb7c402409f4b1ecb279d5e846bdb1dff9bbe0 # [master
c3cc5c5] PCI: imx6: Increase link startup timeout
$ git cherry-pick 832f3ca20743911508e0cc1909415080a3128532 # [master
b4a81be] PCI: imx6: Remove redundant of_match_ptr
$ git cherry-pick ca6457dc1fbcc1f5ed1f8311e7fcf7ff129cda55 # [master
45aa4ab] PCI: imx6: Probe the PCIe in fs_initcall()
$ git cherry-pick 212555bde33eeae0bec16d41bd4045fbebc0cfab # [master
4db342b] ARM: dts: imx6qdl: add pcie device node
$ git cherry-pick 64990a431469a58b2949aca5be9d69e220d53892 # [master
7c29353] ARM: imx6q: Add pll4_audio_div to clock tree
$ git cherry-pick bf22172158cd6dcc5be6dc286ff5c33794dd0ae8 # [master
5e5852f] ARM: imx: Add LVDS general-purpose clocks to i.MX6Q
$ git cherry-pick 74b8031307c5d33d36742c26dd0921991bd5a255 # [master
05ae48c] ARM: imx6q: clock and Kconfig update for PCIe support
$ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
supplied by Richard Zhu
result: lspci detects network card
I have also tested both test cases (TC1 + TC2) with the patches
supplied by Marek Vasut on 26-11-2013:
$ git apply 17_pci_imx6_make_reset-gpio_optional.patch
$ git apply 37_pci_imx6_fix_waiting_for_link_up.patch
$ git apply 47_pci_imx6_split_away_the_phy_reset.patch
$ git apply 57_pci_imx6_split_away_the_link_up_wait_loop.patch
$ git apply 67_pci_imx6_fix_link_start_operation.patch
same results:
TC1: "phy link never came up"
TC2: lspci detects network card
Best regards,
Harro
>>
>> Patch:
>> Author: Richard Zhu <r65037@freescale.com>
>> Date: Tue Nov 26 13:29:24 2013 +0800
>>
>> pcie: imx6: enable pcie on imx6qdl sabresd board
>>
>> Add pcie device tree node into imx6qdl dts file,
>> enable pcie on imx6qdl sabresd board
>>
>> Signed-off-by: Richard Zhu <r65037@freescale.com>
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
>> index e75e11b..b821f87 100644
>> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
>> @@ -212,6 +212,12 @@
>> };
>> };
>>
>> +&pcie {
>> + power-on-gpio = <&gpio3 19 0>;
>> + reset-gpio = <&gpio7 12 0>;
>> + status = "okay";
>> +};
>> +
>> &pwm1 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_pwm0_1>;
>>
>> LOGs when e1000e nic is used:
>> uname -a
>> Linux freescale 3.12.0+ #49 SMP Tue Nov 26 13:26:03 CST 2013 armv7l GNU/Linux
>> root at freescale ~$ lspci -v
>> 00:00.0 PCI bridge: Unknown device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>> I/O behind bridge: 00001000-00001fff
>> Memory behind bridge: 01100000-011fffff
>> Prefetchable memory behind bridge: 01200000-012fffff
>> [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
>> Capabilities: [40] Power Management version 3
>> Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
>> Capabilities: [70] Express Root Port (Slot-) IRQ 0
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [140] Virtual Channel
>>
>> 01:00.0 Ethernet controller: Intel Corporation Unknown device 10d3
>> Subsystem: Intel Corporation Unknown device a01f
>> Flags: bus master, fast devsel, latency 0, IRQ 155
>> Memory at 01180000 (32-bit, non-prefetchable) [size=128K]
>> Memory at 01100000 (32-bit, non-prefetchable) [size=512K]
>> I/O ports at 1000 [disabled] [size=32]
>> Memory at 011a0000 (32-bit, non-prefetchable) [size=16K]
>> [virtual] Expansion ROM at 01200000 [disabled] [size=256K]
>> Capabilities: [c8] Power Management version 2
>> Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
>> Capabilities: [e0] Express Endpoint IRQ 0
>> Capabilities: [a0] MSI-X: Enable- Mask- TabSize=5
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [140] Device Serial Number 8b-18-3a-ff-ff-21-1b-00
>> > >
>> <...>
>> >
>> > Best Regards
>> > Richard Zhu
>>
>> [Richard]
>> Best Regards
>> Richard Zhu
>>
>>
>
^ permalink raw reply [flat|nested] 59+ messages in thread* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-27 16:11 ` Harro Haan
@ 2013-11-27 19:06 ` Marek Vasut
2013-11-28 17:20 ` Harro Haan
0 siblings, 1 reply; 59+ messages in thread
From: Marek Vasut @ 2013-11-27 19:06 UTC (permalink / raw)
To: linux-arm-kernel
Hey Harro,
> On 26 November 2013 08:26, Shawn Guo <shawn.guo@linaro.org> wrote:
> > On Tue, Nov 26, 2013 at 06:04:16AM +0000, Richard Zhu wrote:
> >> [Richard] Based on the tag " pci-v3.13-fixes-1" on pci git-repos, imx6
> >> pcie had been tested on imx6 sabresd board.
> >>
> >> The pcie works after enable pcie support in imx6qdl-sabresd.dtsi file.
> >
> > Great, thanks, Richard.
> >
> > Shawn
>
> Thanks Richard,
>
> TC1: The following does NOT work with the mainline Linux tree on my
> SabreSD with PCIe e1000e network card:
> $ git reset --hard v3.13-rc1
> $ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
> supplied by Richard Zhu
> result: "phy link never came up"
>
> TC2: But the following does work with the mainline Linux tree:
> $ git reset --hard d95d3d53c7ef85ec0dc87db63aece18212c337b0 # HEAD is
> now at d95d3d5 Merge branch 'pci/host-imx6' into next (just a few
> commits after v3.12-rc2)
> $ git cherry-pick 1c4bfb9bd842f09318bc2fa37c1ee0d68bb4e8cb # [master
> f283273] PCI: imx6: Remove redundant dev_err() in imx6_pcie_probe()
> $ git cherry-pick 01ee0c70b5b935135dbe7fbf48115d9f16348474 # [master
> 5c93c84] PCI: imx6: Fix imprecise abort handler
> $ git cherry-pick 5dcb7c402409f4b1ecb279d5e846bdb1dff9bbe0 # [master
> c3cc5c5] PCI: imx6: Increase link startup timeout
> $ git cherry-pick 832f3ca20743911508e0cc1909415080a3128532 # [master
> b4a81be] PCI: imx6: Remove redundant of_match_ptr
> $ git cherry-pick ca6457dc1fbcc1f5ed1f8311e7fcf7ff129cda55 # [master
> 45aa4ab] PCI: imx6: Probe the PCIe in fs_initcall()
> $ git cherry-pick 212555bde33eeae0bec16d41bd4045fbebc0cfab # [master
> 4db342b] ARM: dts: imx6qdl: add pcie device node
> $ git cherry-pick 64990a431469a58b2949aca5be9d69e220d53892 # [master
> 7c29353] ARM: imx6q: Add pll4_audio_div to clock tree
> $ git cherry-pick bf22172158cd6dcc5be6dc286ff5c33794dd0ae8 # [master
> 5e5852f] ARM: imx: Add LVDS general-purpose clocks to i.MX6Q
> $ git cherry-pick 74b8031307c5d33d36742c26dd0921991bd5a255 # [master
> 05ae48c] ARM: imx6q: clock and Kconfig update for PCIe support
> $ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
> supplied by Richard Zhu
> result: lspci detects network card
>
> I have also tested both test cases (TC1 + TC2) with the patches
> supplied by Marek Vasut on 26-11-2013:
> $ git apply 17_pci_imx6_make_reset-gpio_optional.patch
> $ git apply 37_pci_imx6_fix_waiting_for_link_up.patch
> $ git apply 47_pci_imx6_split_away_the_phy_reset.patch
> $ git apply 57_pci_imx6_split_away_the_link_up_wait_loop.patch
> $ git apply 67_pci_imx6_fix_link_start_operation.patch
> same results:
> TC1: "phy link never came up"
> TC2: lspci detects network card
A quick remark: try not to top-post replies in the ML, it's frowned upon.
btw. with my latest patches, do you see the link in Gen=1 or Gen=2 mode ? You
will see a line in dmesg, eventually you can try 'dmesg | grep Gen' to find it.
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-27 19:06 ` Marek Vasut
@ 2013-11-28 17:20 ` Harro Haan
2013-11-28 23:38 ` Marek Vasut
0 siblings, 1 reply; 59+ messages in thread
From: Harro Haan @ 2013-11-28 17:20 UTC (permalink / raw)
To: linux-arm-kernel
On 27 November 2013 20:06, Marek Vasut <marex@denx.de> wrote:
> Hey Harro,
>
>> On 26 November 2013 08:26, Shawn Guo <shawn.guo@linaro.org> wrote:
>> > On Tue, Nov 26, 2013 at 06:04:16AM +0000, Richard Zhu wrote:
>> >> [Richard] Based on the tag " pci-v3.13-fixes-1" on pci git-repos, imx6
>> >> pcie had been tested on imx6 sabresd board.
>> >>
>> >> The pcie works after enable pcie support in imx6qdl-sabresd.dtsi file.
>> >
>> > Great, thanks, Richard.
>> >
>> > Shawn
>>
>> Thanks Richard,
>>
>> TC1: The following does NOT work with the mainline Linux tree on my
>> SabreSD with PCIe e1000e network card:
>> $ git reset --hard v3.13-rc1
>> $ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
>> supplied by Richard Zhu
>> result: "phy link never came up"
>>
>> TC2: But the following does work with the mainline Linux tree:
>> $ git reset --hard d95d3d53c7ef85ec0dc87db63aece18212c337b0 # HEAD is
>> now at d95d3d5 Merge branch 'pci/host-imx6' into next (just a few
>> commits after v3.12-rc2)
>> $ git cherry-pick 1c4bfb9bd842f09318bc2fa37c1ee0d68bb4e8cb # [master
>> f283273] PCI: imx6: Remove redundant dev_err() in imx6_pcie_probe()
>> $ git cherry-pick 01ee0c70b5b935135dbe7fbf48115d9f16348474 # [master
>> 5c93c84] PCI: imx6: Fix imprecise abort handler
>> $ git cherry-pick 5dcb7c402409f4b1ecb279d5e846bdb1dff9bbe0 # [master
>> c3cc5c5] PCI: imx6: Increase link startup timeout
>> $ git cherry-pick 832f3ca20743911508e0cc1909415080a3128532 # [master
>> b4a81be] PCI: imx6: Remove redundant of_match_ptr
>> $ git cherry-pick ca6457dc1fbcc1f5ed1f8311e7fcf7ff129cda55 # [master
>> 45aa4ab] PCI: imx6: Probe the PCIe in fs_initcall()
>> $ git cherry-pick 212555bde33eeae0bec16d41bd4045fbebc0cfab # [master
>> 4db342b] ARM: dts: imx6qdl: add pcie device node
>> $ git cherry-pick 64990a431469a58b2949aca5be9d69e220d53892 # [master
>> 7c29353] ARM: imx6q: Add pll4_audio_div to clock tree
>> $ git cherry-pick bf22172158cd6dcc5be6dc286ff5c33794dd0ae8 # [master
>> 5e5852f] ARM: imx: Add LVDS general-purpose clocks to i.MX6Q
>> $ git cherry-pick 74b8031307c5d33d36742c26dd0921991bd5a255 # [master
>> 05ae48c] ARM: imx6q: clock and Kconfig update for PCIe support
>> $ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
>> supplied by Richard Zhu
>> result: lspci detects network card
>>
>> I have also tested both test cases (TC1 + TC2) with the patches
>> supplied by Marek Vasut on 26-11-2013:
>> $ git apply 17_pci_imx6_make_reset-gpio_optional.patch
>> $ git apply 37_pci_imx6_fix_waiting_for_link_up.patch
>> $ git apply 47_pci_imx6_split_away_the_phy_reset.patch
>> $ git apply 57_pci_imx6_split_away_the_link_up_wait_loop.patch
>> $ git apply 67_pci_imx6_fix_link_start_operation.patch
>> same results:
>> TC1: "phy link never came up"
>> TC2: lspci detects network card
>
> A quick remark: try not to top-post replies in the ML, it's frowned upon.
>
> btw. with my latest patches, do you see the link in Gen=1 or Gen=2 mode ? You
> will see a line in dmesg, eventually you can try 'dmesg | grep Gen' to find it.
For the network card:
$ dmesg | grep Gen
imx6q-pcie 1ffc000.pcie: Link up, Gen=1
$ lspci -vvv | grep "LnkSta:"
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
For the Xilinx AC701 board configured with a Gen1 design:
$ dmesg | grep Gen
imx6q-pcie 1ffc000.pcie: Link up, Gen=1
$ lspci -vvv | grep "LnkSta:"
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
For the Xilinx AC701 board configured with a Gen2 design:
$ dmesg | grep Gen
imx6q-pcie 1ffc000.pcie: Link up, Gen=2
$ lspci -vvv | grep "LnkSta:"
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
Regards,
Harro
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v6 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
2013-11-28 17:20 ` Harro Haan
@ 2013-11-28 23:38 ` Marek Vasut
0 siblings, 0 replies; 59+ messages in thread
From: Marek Vasut @ 2013-11-28 23:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
> On 27 November 2013 20:06, Marek Vasut <marex@denx.de> wrote:
> > Hey Harro,
> >
> >> On 26 November 2013 08:26, Shawn Guo <shawn.guo@linaro.org> wrote:
> >> > On Tue, Nov 26, 2013 at 06:04:16AM +0000, Richard Zhu wrote:
> >> >> [Richard] Based on the tag " pci-v3.13-fixes-1" on pci git-repos,
> >> >> imx6 pcie had been tested on imx6 sabresd board.
> >> >>
> >> >> The pcie works after enable pcie support in imx6qdl-sabresd.dtsi
> >> >> file.
> >> >
> >> > Great, thanks, Richard.
> >> >
> >> > Shawn
> >>
> >> Thanks Richard,
> >>
> >> TC1: The following does NOT work with the mainline Linux tree on my
> >> SabreSD with PCIe e1000e network card:
> >> $ git reset --hard v3.13-rc1
> >> $ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
> >> supplied by Richard Zhu
> >> result: "phy link never came up"
> >>
> >> TC2: But the following does work with the mainline Linux tree:
> >> $ git reset --hard d95d3d53c7ef85ec0dc87db63aece18212c337b0 # HEAD is
> >> now at d95d3d5 Merge branch 'pci/host-imx6' into next (just a few
> >> commits after v3.12-rc2)
> >> $ git cherry-pick 1c4bfb9bd842f09318bc2fa37c1ee0d68bb4e8cb # [master
> >> f283273] PCI: imx6: Remove redundant dev_err() in imx6_pcie_probe()
> >> $ git cherry-pick 01ee0c70b5b935135dbe7fbf48115d9f16348474 # [master
> >> 5c93c84] PCI: imx6: Fix imprecise abort handler
> >> $ git cherry-pick 5dcb7c402409f4b1ecb279d5e846bdb1dff9bbe0 # [master
> >> c3cc5c5] PCI: imx6: Increase link startup timeout
> >> $ git cherry-pick 832f3ca20743911508e0cc1909415080a3128532 # [master
> >> b4a81be] PCI: imx6: Remove redundant of_match_ptr
> >> $ git cherry-pick ca6457dc1fbcc1f5ed1f8311e7fcf7ff129cda55 # [master
> >> 45aa4ab] PCI: imx6: Probe the PCIe in fs_initcall()
> >> $ git cherry-pick 212555bde33eeae0bec16d41bd4045fbebc0cfab # [master
> >> 4db342b] ARM: dts: imx6qdl: add pcie device node
> >> $ git cherry-pick 64990a431469a58b2949aca5be9d69e220d53892 # [master
> >> 7c29353] ARM: imx6q: Add pll4_audio_div to clock tree
> >> $ git cherry-pick bf22172158cd6dcc5be6dc286ff5c33794dd0ae8 # [master
> >> 5e5852f] ARM: imx: Add LVDS general-purpose clocks to i.MX6Q
> >> $ git cherry-pick 74b8031307c5d33d36742c26dd0921991bd5a255 # [master
> >> 05ae48c] ARM: imx6q: clock and Kconfig update for PCIe support
> >> $ git apply enable_pcie_on_imx6qdl_sabresd_board.patch # patch
> >> supplied by Richard Zhu
> >> result: lspci detects network card
> >>
> >> I have also tested both test cases (TC1 + TC2) with the patches
> >> supplied by Marek Vasut on 26-11-2013:
> >> $ git apply 17_pci_imx6_make_reset-gpio_optional.patch
> >> $ git apply 37_pci_imx6_fix_waiting_for_link_up.patch
> >> $ git apply 47_pci_imx6_split_away_the_phy_reset.patch
> >> $ git apply 57_pci_imx6_split_away_the_link_up_wait_loop.patch
> >> $ git apply 67_pci_imx6_fix_link_start_operation.patch
> >> same results:
> >> TC1: "phy link never came up"
> >> TC2: lspci detects network card
> >
> > A quick remark: try not to top-post replies in the ML, it's frowned upon.
> >
> > btw. with my latest patches, do you see the link in Gen=1 or Gen=2 mode ?
> > You will see a line in dmesg, eventually you can try 'dmesg | grep Gen'
> > to find it.
>
> For the network card:
> $ dmesg | grep Gen
> imx6q-pcie 1ffc000.pcie: Link up, Gen=1
> $ lspci -vvv | grep "LnkSta:"
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
> BWMgmt- ABWMgmt-
>
> For the Xilinx AC701 board configured with a Gen1 design:
> $ dmesg | grep Gen
> imx6q-pcie 1ffc000.pcie: Link up, Gen=1
> $ lspci -vvv | grep "LnkSta:"
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
> BWMgmt- ABWMgmt-
>
> For the Xilinx AC701 board configured with a Gen2 design:
> $ dmesg | grep Gen
> imx6q-pcie 1ffc000.pcie: Link up, Gen=2
> $ lspci -vvv | grep "LnkSta:"
> LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt-
> ABWMgmt-
This makes sense, looks like the Gen2 mode works for you now, thanks! Now I need
Richard to verify if my patches make sense too ;-)
^ permalink raw reply [flat|nested] 59+ messages in thread