[PATCH v7 0/2] Add PCIe support for i.MX6q

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Shawn Guo]

Hi Bjorn,

This is basically a resend of imx6 pcie driver patch for inclusion into
PCI tree.  Since we expect you apply the patch with your SoB, I dropped 
your ACK tag there.

I have to ask you to carry the first patch which adds some macros to be
used by pcie driver patch.  Since imx6q-iomuxc-gpr.h gets rare updates
recently, it should be less likely we will run into merge conflict on it.

Changes since v6:

* Drop arch bits from driver patch, and will handle arch bits through
  arm-soc separately.
* Use devm_clk_get() instead of clk_get().
* Drop unnecessary (val != exp_val) check in pcie_phy_poll_ack() loop.
* Rename function imx6_init() to imx6_pcie_init().

Shawn

Sean Cross (2):
  ARM: imx6q: Add PCIe bits to GPR syscon definition
  PCI: imx6: Add support for i.MX6 PCIe controller

 .../devicetree/bindings/pci/designware-pcie.txt    |    7 +-
 drivers/pci/host/Kconfig                           |    6 +
 drivers/pci/host/Makefile                          |    1 +
 drivers/pci/host/pci-imx6.c                        |  576 ++++++++++++++++++++
 include/linux/mfd/syscon/imx6q-iomuxc-gpr.h        |    8 +
 5 files changed, 597 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/host/pci-imx6.c

-- 
1.7.9.5

[PATCH v7 1/2] ARM: imx6q: Add PCIe bits to GPR syscon definition

[Shawn Guo]

From: Sean Cross <xobs@kosagi.com>

PCIe requires additional bits be defined for GPR8 and GPR12.

Signed-off-by: Sean Cross <xobs@kosagi.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
index 7086b22..b6d36b3 100644
--- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
+++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
@@ -241,6 +241,12 @@
 
 #define IMX6Q_GPR5_L2_CLK_STOP			BIT(8)
 
+#define IMX6Q_GPR8_TX_SWING_LOW			(0x7f << 25)
+#define IMX6Q_GPR8_TX_SWING_FULL		(0x7f << 18)
+#define IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB		(0x3f << 12)
+#define IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB		(0x3f << 6)
+#define IMX6Q_GPR8_TX_DEEMPH_GEN1		(0x3f << 0)
+
 #define IMX6Q_GPR9_TZASC2_BYP			BIT(1)
 #define IMX6Q_GPR9_TZASC1_BYP			BIT(0)
 
@@ -273,7 +279,9 @@
 #define IMX6Q_GPR12_ARMP_AHB_CLK_EN		BIT(26)
 #define IMX6Q_GPR12_ARMP_ATB_CLK_EN		BIT(25)
 #define IMX6Q_GPR12_ARMP_APB_CLK_EN		BIT(24)
+#define IMX6Q_GPR12_DEVICE_TYPE			(0xf << 12)
 #define IMX6Q_GPR12_PCIE_CTL_2			BIT(10)
+#define IMX6Q_GPR12_LOS_LEVEL			(0x1f << 4)
 
 #define IMX6Q_GPR13_SDMA_STOP_REQ		BIT(30)
 #define IMX6Q_GPR13_CAN2_STOP_REQ		BIT(29)
-- 
1.7.9.5

[PATCH v7 2/2] PCI: imx6: Add support for i.MX6 PCIe controller

[Shawn Guo]

From: Sean Cross <xobs@kosagi.com>

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: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 .../devicetree/bindings/pci/designware-pcie.txt    |    7 +-
 drivers/pci/host/Kconfig                           |    6 +
 drivers/pci/host/Makefile                          |    1 +
 drivers/pci/host/pci-imx6.c                        |  576 ++++++++++++++++++++
 4 files changed, 589 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/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..d3639aa
--- /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);
+
+	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 = devm_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 = devm_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 = devm_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 = devm_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_pcie_init(void)
+{
+	return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
+}
+module_init(imx6_pcie_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

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Bjorn Helgaas]

On Wed, Sep 25, 2013 at 9:24 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Hi Bjorn,
>
> This is basically a resend of imx6 pcie driver patch for inclusion into
> PCI tree.  Since we expect you apply the patch with your SoB, I dropped
> your ACK tag there.
>
> I have to ask you to carry the first patch which adds some macros to be
> used by pcie driver patch.  Since imx6q-iomuxc-gpr.h gets rare updates
> recently, it should be less likely we will run into merge conflict on it.
>
> Changes since v6:
>
> * Drop arch bits from driver patch, and will handle arch bits through
>   arm-soc separately.
> * Use devm_clk_get() instead of clk_get().
> * Drop unnecessary (val != exp_val) check in pcie_phy_poll_ack() loop.
> * Rename function imx6_init() to imx6_pcie_init().
>
> Shawn
>
> Sean Cross (2):
>   ARM: imx6q: Add PCIe bits to GPR syscon definition
>   PCI: imx6: Add support for i.MX6 PCIe controller
>
>  .../devicetree/bindings/pci/designware-pcie.txt    |    7 +-
>  drivers/pci/host/Kconfig                           |    6 +
>  drivers/pci/host/Makefile                          |    1 +
>  drivers/pci/host/pci-imx6.c                        |  576 ++++++++++++++++++++
>  include/linux/mfd/syscon/imx6q-iomuxc-gpr.h        |    8 +
>  5 files changed, 597 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/pci/host/pci-imx6.c

I merged both of these to my pci/host-imx6 branch for v3.13.

I made a couple minor spelling and whitespace corrections.

Bjorn

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Shawn Guo]

On Fri, Sep 27, 2013 at 01:24:26PM -0600, Bjorn Helgaas wrote:
> I merged both of these to my pci/host-imx6 branch for v3.13.
> 
> I made a couple minor spelling and whitespace corrections.

Thanks Bjorn.

Shawn

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi,

> On Wed, Sep 25, 2013 at 9:24 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > Hi Bjorn,
> > 
> > This is basically a resend of imx6 pcie driver patch for inclusion into
> > PCI tree.  Since we expect you apply the patch with your SoB, I dropped
> > your ACK tag there.
> > 
> > I have to ask you to carry the first patch which adds some macros to be
> > used by pcie driver patch.  Since imx6q-iomuxc-gpr.h gets rare updates
> > recently, it should be less likely we will run into merge conflict on it.
> > 
> > Changes since v6:
> > 
> > * Drop arch bits from driver patch, and will handle arch bits through
> > 
> >   arm-soc separately.
> > 
> > * Use devm_clk_get() instead of clk_get().
> > * Drop unnecessary (val != exp_val) check in pcie_phy_poll_ack() loop.
> > * Rename function imx6_init() to imx6_pcie_init().
> > 
> > Shawn
> > 
> > Sean Cross (2):
> >   ARM: imx6q: Add PCIe bits to GPR syscon definition
> >   PCI: imx6: Add support for i.MX6 PCIe controller
> >  
> >  .../devicetree/bindings/pci/designware-pcie.txt    |    7 +-
> >  drivers/pci/host/Kconfig                           |    6 +
> >  drivers/pci/host/Makefile                          |    1 +
> >  drivers/pci/host/pci-imx6.c                        |  576
> >  ++++++++++++++++++++ include/linux/mfd/syscon/imx6q-iomuxc-gpr.h       
> >  |    8 +
> >  5 files changed, 597 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/pci/host/pci-imx6.c
> 
> I merged both of these to my pci/host-imx6 branch for v3.13.
> 
> I made a couple minor spelling and whitespace corrections.

I have MX6 hardware with a PCIe switch, so I can test that stuff. Thus far, of 
course, the switch doesn't work. Is getting the switch to work only a matter of 
programming the RdWr0 vs. RdWr1 mode into the iATU or is there something more ?

Thanks!

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Zhu Richard-R65037]

Hi Marek:
Thanks for your kindly tests.

Regarding to my experience on 3.0.35 kernel, besides the programming the RdWr0 vs. RdWr1 mode into the iATU.
The INTx should be configured properly, for example, like the following one:

static int __init imx_pcie_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
{
       switch (pin) {
       case 1: return MXC_INT_PCIE_3;
       case 2: return MXC_INT_PCIE_2;
       case 3: return MXC_INT_PCIE_1;
       case 4: return MXC_INT_PCIE_0;
       default: return -1;
       }
}

static struct hw_pci imx_pci __initdata = {
        .nr_controllers = 1,
        .swizzle        = pci_std_swizzle,
        .setup          = imx_pcie_setup,
        .scan           = imx_pcie_scan_bus,
        .map_irq        = imx_pcie_map_irq,
};
Best Regards
Richard Zhu


-----Original Message-----
From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] On Behalf Of Marek Vasut
Sent: Wednesday, October 09, 2013 4:56 AM
To: linux-arm-kernel at lists.infradead.org
Cc: Bjorn Helgaas; Shawn Guo; Zhu Richard-R65037; linux-pci at vger.kernel.org; tharvey at gateworks.com; Frank Li; Sean Cross; Sascha Hauer
Subject: Re: [PATCH v7 0/2] Add PCIe support for i.MX6q

Hi,

> On Wed, Sep 25, 2013 at 9:24 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > Hi Bjorn,
> > 
> > This is basically a resend of imx6 pcie driver patch for inclusion 
> > into PCI tree.  Since we expect you apply the patch with your SoB, I 
> > dropped your ACK tag there.
> > 
> > I have to ask you to carry the first patch which adds some macros to 
> > be used by pcie driver patch.  Since imx6q-iomuxc-gpr.h gets rare 
> > updates recently, it should be less likely we will run into merge conflict on it.
> > 
> > Changes since v6:
> > 
> > * Drop arch bits from driver patch, and will handle arch bits 
> > through
> > 
> >   arm-soc separately.
> > 
> > * Use devm_clk_get() instead of clk_get().
> > * Drop unnecessary (val != exp_val) check in pcie_phy_poll_ack() loop.
> > * Rename function imx6_init() to imx6_pcie_init().
> > 
> > Shawn
> > 
> > Sean Cross (2):
> >   ARM: imx6q: Add PCIe bits to GPR syscon definition
> >   PCI: imx6: Add support for i.MX6 PCIe controller
> >  
> >  .../devicetree/bindings/pci/designware-pcie.txt    |    7 +-
> >  drivers/pci/host/Kconfig                           |    6 +
> >  drivers/pci/host/Makefile                          |    1 +
> >  drivers/pci/host/pci-imx6.c                        |  576
> >  ++++++++++++++++++++ include/linux/mfd/syscon/imx6q-iomuxc-gpr.h       
> >  |    8 +
> >  5 files changed, 597 insertions(+), 1 deletion(-)  create mode 
> > 100644 drivers/pci/host/pci-imx6.c
> 
> I merged both of these to my pci/host-imx6 branch for v3.13.
> 
> I made a couple minor spelling and whitespace corrections.

I have MX6 hardware with a PCIe switch, so I can test that stuff. Thus far, of course, the switch doesn't work. Is getting the switch to work only a matter of programming the RdWr0 vs. RdWr1 mode into the iATU or is there something more ?

Thanks!

Best regards,
Marek Vasut
--
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

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Richard,

> Hi Marek:
> Thanks for your kindly tests.
> 
> Regarding to my experience on 3.0.35 kernel, besides the programming the
> RdWr0 vs. RdWr1 mode into the iATU. The INTx should be configured
> properly, for example, like the following one:
> 
> static int __init imx_pcie_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
> {
>        switch (pin) {
>        case 1: return MXC_INT_PCIE_3;
>        case 2: return MXC_INT_PCIE_2;
>        case 3: return MXC_INT_PCIE_1;
>        case 4: return MXC_INT_PCIE_0;
>        default: return -1;
>        }
> }
> 
> static struct hw_pci imx_pci __initdata = {
>         .nr_controllers = 1,
>         .swizzle        = pci_std_swizzle,
>         .setup          = imx_pcie_setup,
>         .scan           = imx_pcie_scan_bus,
>         .map_irq        = imx_pcie_map_irq,
> };
> Best Regards
> Richard Zhu

Thanks for pointing this out, I'll check this. Are there plans to implement the 
PCIe switch support already so I won't step into someone else's work?

In the meantime, this is what I see upon probe with V6 of the patches:

Linux version 3.12.0-rc2-next-20130927+
[...]
imx6q-pcie 1ffc000.pcie: phy link never came 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 enabled
PCI: Device 0000:00:00.0 not available because of resource collisions
pcieport: probe of 0000:00:00.0 failed with error -22
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: PCI bridge to [bus 01]

Is this line normal/expected? Is this related to the PCIe switch I have there?
pcieport: probe of 0000:00:00.0 failed with error -22

Thank you for your help!

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Zhu Richard-R65037]

Hi Marek
Thanks for your kindly help on the i.MX6 PCIe switch debug.

I encountered random panic although I add the irq_map codes pasted before.
Sometimes the switch + ep device can work well, but system maybe panic sometimes. :(

Here are the logs when system is panic.
----------------------------------------
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)  ? <--PCIe bus enumeration  is finished.
...

------------------------[device driver is loaded here]---------------------------
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
...
e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx  ? PCIe device is ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
...
----------------------------------------
...
IP-Config: Got DHCP answer from 10.192.242.252, my address is 10.192.242.95
IP-Config: Complete:
     device=eth0, hwaddr=00:04:9f:02:18:df, ipaddr=10.192.242.95, mask=255.255.255.0, gw=10.192.242.254
     host=10.192.242.95, domain=ap.freescale.net, nis-domain=(none)
     bootserver=0.0.0.0, rootserver=10.192.225.216, rootpath=
     nameserver0=10.192.130.201, nameserver1=10.211.0.3, nameserver2=10.196.51.200
ALSA device list:
  #0: wm8962-audio
  #1: imx-hdmi-soc
VFS: Mounted root (nfs filesystem) on device 0:11.
devtmpfs: mounted
Freeing unused kernel memory: 300K (80c29000 - 80c74000)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b  ? <--System panic here sometimes. :(

CPU2: stopping
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.10.9-15963-ge0eed42-dirty #133
[<80014764>] (unwind_backtrace+0x0/0xf4) from [<8001159c>] (show_stack+0x10/0x14)
[<8001159c>] (show_stack+0x10/0x14) from [<80013968>] (handle_IPI+0x108/0x130)
[<80013968>] (handle_IPI+0x108/0x130) from [<800085dc>] (gic_handle_irq+0x58/0x5c)
[<800085dc>] (gic_handle_irq+0x58/0x5c) from [<8000dc00>] (__irq_svc+0x40/0x50)
Exception stack(0x9c09bf50 to 0x9c09bf98)
bf40:                                     9c09bf98 00000008 3a3491de 00000002
bf60: 39d2f97e 00000002 8134f080 80c83f90 00000000 00000000 9c09a000 80c7e4d8
bf80: 00000017 9c09bf98 8005a4b4 80470c90 60000013 ffffffff
[<8000dc00>] (__irq_svc+0x40/0x50) from [<80470c90>] (cpuidle_enter_state+0x50/0xe0)
[<80470c90>] (cpuidle_enter_state+0x50/0xe0) from [<80470dd0>] (cpuidle_idle_call+0xb0/0x148)
[<80470dd0>] (cpuidle_idle_call+0xb0/0x148) from [<8000ebbc>] (arch_cpu_idle+0x10/0x54)
[<8000ebbc>] (arch_cpu_idle+0x10/0x54) from [<80059d48>] (cpu_startup_entry+0xfc/0x140)
[<80059d48>] (cpu_startup_entry+0xfc/0x140) from [<10646ca4>] (0x10646ca4)
CPU3: stopping
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.10.9-15963-ge0eed42-dirty #133
[<80014764>] (unwind_backtrace+0x0/0xf4) from [<8001159c>] (show_stack+0x10/0x14)
[<8001159c>] (show_stack+0x10/0x14) from [<80013968>] (handle_IPI+0x108/0x130)
[<80013968>] (handle_IPI+0x108/0x130) from [<800085dc>] (gic_handle_irq+0x58/0x5c)
[<800085dc>] (gic_handle_irq+0x58/0x5c) from [<8000dc00>] (__irq_svc+0x40/0x50)
Exception stack(0x9c09df50 to 0x9c09df98)
df40:                                     9c09df98 00000008 3a3491de 00000002
df60: 39cdfad9 00000002 81357080 80c83f90 00000000 00000000 9c09c000 80c7e4d8
df80: 00000017 9c09df98 8005a4b4 80470c90 60000113 ffffffff
[<8000dc00>] (__irq_svc+0x40/0x50) from [<80470c90>] (cpuidle_enter_state+0x50/0xe0)
[<80470c90>] (cpuidle_enter_state+0x50/0xe0) from [<80470dd0>] (cpuidle_idle_call+0xb0/0x148)
[<80470dd0>] (cpuidle_idle_call+0xb0/0x148) from [<8000ebbc>] (arch_cpu_idle+0x10/0x54)
[<8000ebbc>] (arch_cpu_idle+0x10/0x54) from [<80059d48>] (cpu_startup_entry+0xfc/0x140)
[<80059d48>] (cpu_startup_entry+0xfc/0x140) from [<10646ca4>] (0x10646ca4)
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.9-15963-ge0eed42-dirty #133
[<80014764>] (unwind_backtrace+0x0/0xf4) from [<8001159c>] (show_stack+0x10/0x14)
[<8001159c>] (show_stack+0x10/0x14) from [<80013968>] (handle_IPI+0x108/0x130)
[<80013968>] (handle_IPI+0x108/0x130) from [<800085dc>] (gic_handle_irq+0x58/0x5c)
[<800085dc>] (gic_handle_irq+0x58/0x5c) from [<8000dc00>] (__irq_svc+0x40/0x50)
Exception stack(0x9c099f50 to 0x9c099f98)
9f40:                                     9c099f98 00000008 3a3491de 00000002
9f60: 39cdf83e 00000002 81347080 80c83f90 00000000 00000000 9c098000 80c7e4d8
9f80: 00000017 9c099f98 8005a4b4 80470c90 60000013 ffffffff
[<8000dc00>] (__irq_svc+0x40/0x50) from [<80470c90>] (cpuidle_enter_state+0x50/0xe0)
[<80470c90>] (cpuidle_enter_state+0x50/0xe0) from [<80470dd0>] (cpuidle_idle_call+0xb0/0x148)
[<80470dd0>] (cpuidle_idle_call+0xb0/0x148) from [<8000ebbc>] (arch_cpu_idle+0x10/0x54)
[<8000ebbc>] (arch_cpu_idle+0x10/0x54) from [<80059d48>] (cpu_startup_entry+0xfc/0x140)
[<80059d48>] (cpu_startup_entry+0xfc/0x140) from [<10646ca4>] (0x10646ca4)

Any ideas? 
Thanks in advance.

Best Regards
Richard Zhu


-----Original Message-----
From: Marek Vasut [mailto:marex at denx.de] 
Sent: Thursday, October 10, 2013 6:25 PM
To: Zhu Richard-R65037
Cc: linux-arm-kernel at lists.infradead.org; Bjorn Helgaas; Shawn Guo; linux-pci at vger.kernel.org; tharvey at gateworks.com; Frank Li; Sean Cross; Sascha Hauer
Subject: Re: [PATCH v7 0/2] Add PCIe support for i.MX6q

Hi Richard,

> Hi Marek:
> Thanks for your kindly tests.
> 
> Regarding to my experience on 3.0.35 kernel, besides the programming 
> the
> RdWr0 vs. RdWr1 mode into the iATU. The INTx should be configured 
> properly, for example, like the following one:
> 
> static int __init imx_pcie_map_irq(struct pci_dev *dev, u8 slot, u8 
> pin) {
>        switch (pin) {
>        case 1: return MXC_INT_PCIE_3;
>        case 2: return MXC_INT_PCIE_2;
>        case 3: return MXC_INT_PCIE_1;
>        case 4: return MXC_INT_PCIE_0;
>        default: return -1;
>        }
> }
> 
> static struct hw_pci imx_pci __initdata = {
>         .nr_controllers = 1,
>         .swizzle        = pci_std_swizzle,
>         .setup          = imx_pcie_setup,
>         .scan           = imx_pcie_scan_bus,
>         .map_irq        = imx_pcie_map_irq,
> };
> Best Regards
> Richard Zhu

Thanks for pointing this out, I'll check this. Are there plans to implement the PCIe switch support already so I won't step into someone else's work?

In the meantime, this is what I see upon probe with V6 of the patches:

Linux version 3.12.0-rc2-next-20130927+
[...]
imx6q-pcie 1ffc000.pcie: phy link never came 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 enabled
PCI: Device 0000:00:00.0 not available because of resource collisions
pcieport: probe of 0000:00:00.0 failed with error -22 pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref] pci 0000:00:00.0: PCI bridge to [bus 01] pci 0000:00:00.0: PCI bridge to [bus 01]

Is this line normal/expected? Is this related to the PCIe switch I have there?
pcieport: probe of 0000:00:00.0 failed with error -22

Thank you for your help!

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Richard,

> Hi Marek
> Thanks for your kindly help on the i.MX6 PCIe switch debug.
> 
> I encountered random panic although I add the irq_map codes pasted before.
> Sometimes the switch + ep device can work well, but system maybe panic
> sometimes. :(

[...]

> VFS: Mounted root (nfs filesystem) on device 0:11.
> devtmpfs: mounted
> Freeing unused kernel memory: 300K (80c29000 - 80c74000)
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b  ?
> <--System panic here sometimes. :(

Looks like your init (program) exited in some way. Does this happen when you use 
the built-in ethernet controller too? Try booting with a ramdisk and generate 
large amounts of ethernet traffic (try with iperf), see if you observe a crash 
or corruption.

What kind of patch did you apply , can you share that patch ?

[...]

> Thanks for pointing this out, I'll check this. Are there plans to implement
> the PCIe switch support already so I won't step into someone else's work?
> 
> In the meantime, this is what I see upon probe with V6 of the patches:
> 
> Linux version 3.12.0-rc2-next-20130927+
> [...]
> imx6q-pcie 1ffc000.pcie: phy link never came 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 enabled
> PCI: Device 0000:00:00.0 not available because of resource collisions
> pcieport: probe of 0000:00:00.0 failed with error -22 pci 0000:00:00.0: BAR
> 0: assigned [mem 0x01000000-0x010fffff] pci 0000:00:00.0: BAR 6: assigned
> [mem 0x01100000-0x0110ffff pref] pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0: PCI bridge to [bus 01]
> 
> Is this line normal/expected? Is this related to the PCIe switch I have
> there? pcieport: probe of 0000:00:00.0 failed with error -22

Any ideas on this stuff above please?

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Bjorn Helgaas]

On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:

> In the meantime, this is what I see upon probe with V6 of the patches:
>
> Linux version 3.12.0-rc2-next-20130927+
> [...]
> imx6q-pcie 1ffc000.pcie: phy link never came 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]

This indicates a bug in your host bridge driver.  You must supply the
bus number range claimed by the host bridge.  There's no way the PCI
core can figure that out itself.  We do assume [bus 00-ff], but that's
only a fallback and will prevent multi-host bridge configurations from
working.

> PCI: bus0: Fast back to back transfers disabled
> PCI: bus1: Fast back to back transfers enabled
> PCI: Device 0000:00:00.0 not available because of resource collisions
> pcieport: probe of 0000:00:00.0 failed with error -22

If you boot with "ignore_loglevel", you should see more details about
this device, including the BAR values we read from it.  Based on
pcibios_enable_device() in arch/arm/kernel/bios32.c, my guess is that
00:00.0 has an uninitialized BAR (maybe it is in power-on state), and
you didn't do anything to assign the BAR before trying to bind the
pcieport driver to it.  You might be missing a call to
pci_bus_assign_resources() or pci_assign_unassigned_resources().

> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0: PCI bridge to [bus 01]
>
> Is this line normal/expected? Is this related to the PCIe switch I have there?
> pcieport: probe of 0000:00:00.0 failed with error -22
>
> Thank you for your help!
>
> Best regards,
> Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Bjorn,

> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
> > In the meantime, this is what I see upon probe with V6 of the patches:
> > 
> > Linux version 3.12.0-rc2-next-20130927+
> > [...]
> > imx6q-pcie 1ffc000.pcie: phy link never came 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]
> 
> This indicates a bug in your host bridge driver.  You must supply the
> bus number range claimed by the host bridge.  There's no way the PCI
> core can figure that out itself.  We do assume [bus 00-ff], but that's
> only a fallback and will prevent multi-host bridge configurations from
> working.

Ah, thanks for this information, this is very helpful! I implemented mx6 PCIe 
driver for U-Boot and this is my topology (detected by U-Boot)

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 12d8:2303 - Bridge device
    02:01.0   - 12d8:2303 - Bridge device
     03:00.0  - 8086:1531 - Network controller
    02:02.0   - 12d8:2303 - Bridge device

(The mnenomic is BUS:DEV.FN)

So I shouldn't even touch 0000:00:00.0 in Linux, but use 0000:00:01.0 as that's 
the root hub (16c3:abcd), no?

> > PCI: bus0: Fast back to back transfers disabled
> > PCI: bus1: Fast back to back transfers enabled
> > PCI: Device 0000:00:00.0 not available because of resource collisions
> > pcieport: probe of 0000:00:00.0 failed with error -22
> 
> If you boot with "ignore_loglevel", you should see more details about
> this device, including the BAR values we read from it.  Based on
> pcibios_enable_device() in arch/arm/kernel/bios32.c, my guess is that
> 00:00.0 has an uninitialized BAR (maybe it is in power-on state), and
> you didn't do anything to assign the BAR before trying to bind the
> pcieport driver to it.  You might be missing a call to
> pci_bus_assign_resources() or pci_assign_unassigned_resources().

Will check this, thank you!

> > pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> > pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
> > pci 0000:00:00.0: PCI bridge to [bus 01]
> > pci 0000:00:00.0: PCI bridge to [bus 01]
> > 
> > Is this line normal/expected? Is this related to the PCIe switch I have
> > there? pcieport: probe of 0000:00:00.0 failed with error -22
> > 
> > Thank you for your help!
> > 
> > Best regards,
> > Marek Vasut

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Bjorn,

> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
> > In the meantime, this is what I see upon probe with V6 of the patches:
> > 
> > Linux version 3.12.0-rc2-next-20130927+
> > [...]
> > imx6q-pcie 1ffc000.pcie: phy link never came 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]
> 
> This indicates a bug in your host bridge driver.  You must supply the
> bus number range claimed by the host bridge.  There's no way the PCI
> core can figure that out itself.  We do assume [bus 00-ff], but that's
> only a fallback and will prevent multi-host bridge configurations from
> working.
> 
> > PCI: bus0: Fast back to back transfers disabled
> > PCI: bus1: Fast back to back transfers enabled
> > PCI: Device 0000:00:00.0 not available because of resource collisions
> > pcieport: probe of 0000:00:00.0 failed with error -22
> 
> If you boot with "ignore_loglevel", you should see more details about
> this device, including the BAR values we read from it.  Based on
> pcibios_enable_device() in arch/arm/kernel/bios32.c, my guess is that
> 00:00.0 has an uninitialized BAR (maybe it is in power-on state), and
> you didn't do anything to assign the BAR before trying to bind the
> pcieport driver to it.  You might be missing a call to
> pci_bus_assign_resources() or pci_assign_unassigned_resources().

I tried you suggestion, this is what I got now (and with V7 of the patches):

Note that my topology is: rootport->2_port_switch->ethernet_chip , the other 
port of the switch is not used .

imx6q-pcie 1ffc000.pcie: phy link never came 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_bus 0000:00: scanning bus
pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x5c
pci 0000:00:00.0: supports D1
pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci_bus 0000:00: fixups for bus
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:01: scanning bus
pci_bus 0000:01: fixups for bus
PCI: bus1: Fast back to back transfers enabled
pci_bus 0000:01: bus scan returning with max=01
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: bus scan returning with max=01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
PCI: Device 0000:00:00.0 not available because of resource collisions
pcieport: probe of 0000:00:00.0 failed with error -22
pci 0000:00:00.0: fixup irq: got 155
pci 0000:00:00.0: assigning IRQ 155                                                                                                                                         
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]                                                                                                               
pci 0000:00:00.0: BAR 0: set to [mem 0x01000000-0x010fffff] (PCI address 
[0x1000000-0x10                                                                                    
fffff])                                                                                                                                                                     
pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]                                                                                                          
pci 0000:00:00.0: PCI bridge to [bus 01]                                                                                                                                    
pci 0000:00:00.0: PCI bridge to [bus 01]                                                                                                                                    
pci_bus 0000:00: resource 4 [io  0x1000-0x10000]                                                                                                                            
pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]

What is this conflicting device 0000:00:01 I observe here? Does it have to do 
with the switch ?

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Bjorn Helgaas]

[+cc Yinghai]

On Thu, Oct 10, 2013 at 9:58 AM, Marek Vasut <marex@denx.de> wrote:
>> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
> I tried you suggestion, this is what I got now (and with V7 of the patches):
>
> Note that my topology is: rootport->2_port_switch->ethernet_chip , the other
> port of the switch is not used .
>
> imx6q-pcie 1ffc000.pcie: phy link never came 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_bus 0000:00: scanning bus
> pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]

This is probably your Root Port, and it looks like its BARs haven't
been programmed.

> pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x5c
> pci 0000:00:00.0: supports D1
> pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> pci 0000:00:00.0: PME# disabled
> pci_bus 0000:00: fixups for bus
> PCI: bus0: Fast back to back transfers disabled
> pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
> pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
> pci_bus 0000:01: scanning bus
> pci_bus 0000:01: fixups for bus
> PCI: bus1: Fast back to back transfers enabled
> pci_bus 0000:01: bus scan returning with max=01
> pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> pci_bus 0000:00: bus scan returning with max=01
> pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01

We should have found the switch (an Upstream Port and two Downstream
Ports) and the ethernet device here.  Have you ever seen this work,
i.e., have we ever found those devices, with any kernel?

It's possible that your host bridge is configured to only generate
config cycles for bus 00, i.e., the host bridge resource is actually
"[bus 00]".  If that were the case, we'd never see anything on bus 01.
 This would be i.MX6q-specific configuration, so I can't help here.

I suppose it's conceivable this is related to 928bea96 "PCI: Delay
enabling bridges until they're needed".  Per spec (PCI-to-PCI Bridge
Spec, r1.2, sec 3.2.4.3), I don't think the bridge enable bits affect
config transaction forwarding, but if your Root Port were defective
and only forwarded config transactions when enabled, you'd also see
this.  You could try forcibly setting the enable bits in
pci_scan_bridge() just as an experiment.

> PCI: Device 0000:00:00.0 not available because of resource collisions
> pcieport: probe of 0000:00:00.0 failed with error -22
> pci 0000:00:00.0: fixup irq: got 155
> pci 0000:00:00.0: assigning IRQ 155
> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> pci 0000:00:00.0: BAR 0: set to [mem 0x01000000-0x010fffff] (PCI address
> [0x1000000-0x10
> fffff])
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]

You *are* assigning resources here; I'm not sure why we're trying to
bind the pcieport driver before resource assignment.  That seems out
of order.

> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci_bus 0000:00: resource 4 [io  0x1000-0x10000]
> pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
>
> What is this conflicting device 0000:00:01 I observe here? Does it have to do
> with the switch ?

I don't see a 0000:00:01.  That's not a complete PCI ID anyway; it
means domain 0000, bus 00, device 01, but there's no function number.

Bjorn

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Bjorn,

> [+cc Yinghai]
> 
> On Thu, Oct 10, 2013 at 9:58 AM, Marek Vasut <marex@denx.de> wrote:
> >> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
> > I tried you suggestion, this is what I got now (and with V7 of the
> > patches):
> > 
> > Note that my topology is: rootport->2_port_switch->ethernet_chip , the
> > other port of the switch is not used .
> > 
> > imx6q-pcie 1ffc000.pcie: phy link never came 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_bus 0000:00: scanning bus
> > pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> > pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> > pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
> 
> This is probably your Root Port, and it looks like its BARs haven't
> been programmed.

The BAR programming should be happening in:

drivers/pci/host/pcie-designware.c

494 void dw_pcie_setup_rc(struct pcie_port *pp)
495 {
[...]
532 
533         /* setup RC BARs */
534         dw_pcie_writel_rc(pp, 0x00000004, PCI_BASE_ADDRESS_0);
535         dw_pcie_writel_rc(pp, 0x00000004, PCI_BASE_ADDRESS_1);

Or am I mistaken?

> > pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x5c
> > pci 0000:00:00.0: supports D1
> > pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> > pci 0000:00:00.0: PME# disabled
> > pci_bus 0000:00: fixups for bus
> > PCI: bus0: Fast back to back transfers disabled
> > pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
> > pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
> > pci_bus 0000:01: scanning bus
> > pci_bus 0000:01: fixups for bus
> > PCI: bus1: Fast back to back transfers enabled
> > pci_bus 0000:01: bus scan returning with max=01
> > pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> > pci_bus 0000:00: bus scan returning with max=01
> > pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
> 
> We should have found the switch (an Upstream Port and two Downstream
> Ports) and the ethernet device here.  Have you ever seen this work,
> i.e., have we ever found those devices, with any kernel?

I got it working in U-Boot, but the PCI stack there is ported from older kernel 
version and the MX6 PCIe driver is entirely custom (even though it's copying the 
behavior of the MX6 PCIe driver in kernel).

I managed to detect the whole topology in U-Boot:

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 12d8:2303 - Bridge device
    02:01.0   - 12d8:2303 - Bridge device
     03:00.0  - 8086:1531 - Network controller
    02:02.0   - 12d8:2303 - Bridge device

The 00:01.0 is the MX6 root bridge , the 01:00.0 is the switch's upstream port, 
02:01.0 and 02:02.0 are the downstream ports and the 03:00.0 is the ethernet 
controller.

I suspect the PCIe works without issues here.

> It's possible that your host bridge is configured to only generate
> config cycles for bus 00, i.e., the host bridge resource is actually
> "[bus 00]".  If that were the case, we'd never see anything on bus 01.
>  This would be i.MX6q-specific configuration, so I can't help here.

I checked the pcie-designware.c code and maybe this is where this is set up?

543         /* setup bus numbers */
544         dw_pcie_readl_rc(pp, PCI_PRIMARY_BUS, &val);
545         val &= 0xff000000;
546         val |= 0x00010100;
547         dw_pcie_writel_rc(pp, val, PCI_PRIMARY_BUS);

> I suppose it's conceivable this is related to 928bea96 "PCI: Delay
> enabling bridges until they're needed".  Per spec (PCI-to-PCI Bridge
> Spec, r1.2, sec 3.2.4.3), I don't think the bridge enable bits affect
> config transaction forwarding, but if your Root Port were defective
> and only forwarded config transactions when enabled, you'd also see
> this.  You could try forcibly setting the enable bits in
> pci_scan_bridge() just as an experiment.

Will try. I can also try reverting this or the whole set:

    * pci/yinghai-assign-unassigned-v6:
      PCI: Assign resources for hot-added host bridge more aggressively
      PCI: Move resource reallocation code to non-__init
      PCI: Delay enabling bridges until they're needed
      PCI: Assign resources on a per-bus basis
      PCI: Enable unassigned resource reallocation on per-bus basis
      PCI: Turn on reallocation for unassigned resources with host bridge offset
      PCI: Look for unassigned resources on per-bus basis
      PCI: Drop temporary variable in pci_assign_unassigned_resources()

Would that help maybe?

> > PCI: Device 0000:00:00.0 not available because of resource collisions
> > pcieport: probe of 0000:00:00.0 failed with error -22
> > pci 0000:00:00.0: fixup irq: got 155
> > pci 0000:00:00.0: assigning IRQ 155
> > pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> > pci 0000:00:00.0: BAR 0: set to [mem 0x01000000-0x010fffff] (PCI address
> > [0x1000000-0x10
> > fffff])
> > pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
> 
> You *are* assigning resources here; I'm not sure why we're trying to
> bind the pcieport driver before resource assignment.  That seems out
> of order.

Could it be a bug in the PCIe subsystem then ?

> > pci 0000:00:00.0: PCI bridge to [bus 01]
> > pci 0000:00:00.0: PCI bridge to [bus 01]
> > pci_bus 0000:00: resource 4 [io  0x1000-0x10000]
> > pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
> > 
> > What is this conflicting device 0000:00:01 I observe here? Does it have
> > to do with the switch ?
> 
> I don't see a 0000:00:01.  That's not a complete PCI ID anyway; it
> means domain 0000, bus 00, device 01, but there's no function number.

It is there somewhere around the middle of the log I pasted, see:

-->8--
pci_bus 0000:01: scanning bus
pci_bus 0000:01: fixups for bus
PCI: bus1: Fast back to back transfers enabled
pci_bus 0000:01: bus scan returning with max=01
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci_bus 0000:00: bus scan returning with max=01
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
--8<--

Thank you for the help!

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Bjorn Helgaas]

On Thu, Oct 10, 2013 at 11:39 AM, Marek Vasut <marex@denx.de> wrote:
> Hi Bjorn,
>
>> [+cc Yinghai]
>>
>> On Thu, Oct 10, 2013 at 9:58 AM, Marek Vasut <marex@denx.de> wrote:
>> >> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
>> > I tried you suggestion, this is what I got now (and with V7 of the
>> > patches):
>> >
>> > Note that my topology is: rootport->2_port_switch->ethernet_chip , the
>> > other port of the switch is not used .
>> >
>> > imx6q-pcie 1ffc000.pcie: phy link never came 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_bus 0000:00: scanning bus
>> > pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
>> > pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
>> > pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
>>
>> This is probably your Root Port, and it looks like its BARs haven't
>> been programmed.
>
> The BAR programming should be happening in:
>
> drivers/pci/host/pcie-designware.c
>
> 494 void dw_pcie_setup_rc(struct pcie_port *pp)
> 495 {
> [...]
> 532
> 533         /* setup RC BARs */
> 534         dw_pcie_writel_rc(pp, 0x00000004, PCI_BASE_ADDRESS_0);
> 535         dw_pcie_writel_rc(pp, 0x00000004, PCI_BASE_ADDRESS_1);

0x00000004 in a BAR would indicate a 64-bit non-prefetchable memory
BAR.  Bits 0-3 are normally read-only, but maybe there's a way for
setup code to write them.  In any case, this doesn't assign an address
to the BAR.

>> > pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x5c
>> > pci 0000:00:00.0: supports D1
>> > pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
>> > pci 0000:00:00.0: PME# disabled
>> > pci_bus 0000:00: fixups for bus
>> > PCI: bus0: Fast back to back transfers disabled
>> > pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
>> > pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
>> > pci_bus 0000:01: scanning bus
>> > pci_bus 0000:01: fixups for bus
>> > PCI: bus1: Fast back to back transfers enabled
>> > pci_bus 0000:01: bus scan returning with max=01
>> > pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
>> > pci_bus 0000:00: bus scan returning with max=01
>> > pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01
>>
>> We should have found the switch (an Upstream Port and two Downstream
>> Ports) and the ethernet device here.  Have you ever seen this work,
>> i.e., have we ever found those devices, with any kernel?
>
> I got it working in U-Boot, but the PCI stack there is ported from older kernel
> version and the MX6 PCIe driver is entirely custom (even though it's copying the
> behavior of the MX6 PCIe driver in kernel).
>
> I managed to detect the whole topology in U-Boot:
>
>   00:01.0     - 16c3:abcd - Bridge device
>    01:00.0    - 12d8:2303 - Bridge device
>     02:01.0   - 12d8:2303 - Bridge device
>      03:00.0  - 8086:1531 - Network controller
>     02:02.0   - 12d8:2303 - Bridge device
>
> The 00:01.0 is the MX6 root bridge , the 01:00.0 is the switch's upstream port,
> 02:01.0 and 02:02.0 are the downstream ports and the 03:00.0 is the ethernet
> controller.
>
> I suspect the PCIe works without issues here.

Interesting that we found 00:00.0 above, and U-Boot didn't.

>> It's possible that your host bridge is configured to only generate
>> config cycles for bus 00, i.e., the host bridge resource is actually
>> "[bus 00]".  If that were the case, we'd never see anything on bus 01.
>>  This would be i.MX6q-specific configuration, so I can't help here.
>
> I checked the pcie-designware.c code and maybe this is where this is set up?
>
> 543         /* setup bus numbers */
> 544         dw_pcie_readl_rc(pp, PCI_PRIMARY_BUS, &val);
> 545         val &= 0xff000000;
> 546         val |= 0x00010100;
> 547         dw_pcie_writel_rc(pp, val, PCI_PRIMARY_BUS);
>
>> I suppose it's conceivable this is related to 928bea96 "PCI: Delay
>> enabling bridges until they're needed".  Per spec (PCI-to-PCI Bridge
>> Spec, r1.2, sec 3.2.4.3), I don't think the bridge enable bits affect
>> config transaction forwarding, but if your Root Port were defective
>> and only forwarded config transactions when enabled, you'd also see
>> this.  You could try forcibly setting the enable bits in
>> pci_scan_bridge() just as an experiment.
>
> Will try. I can also try reverting this or the whole set:
>
>     * pci/yinghai-assign-unassigned-v6:
>       PCI: Assign resources for hot-added host bridge more aggressively
>       PCI: Move resource reallocation code to non-__init
>       PCI: Delay enabling bridges until they're needed
>       PCI: Assign resources on a per-bus basis
>       PCI: Enable unassigned resource reallocation on per-bus basis
>       PCI: Turn on reallocation for unassigned resources with host bridge offset
>       PCI: Look for unassigned resources on per-bus basis
>       PCI: Drop temporary variable in pci_assign_unassigned_resources()
>
> Would that help maybe?

I doubt it.  Maybe you could compare config space under U-Boot with
config space under Linux and look for differences?

>> > PCI: Device 0000:00:00.0 not available because of resource collisions
>> > pcieport: probe of 0000:00:00.0 failed with error -22
>> > pci 0000:00:00.0: fixup irq: got 155
>> > pci 0000:00:00.0: assigning IRQ 155
>> > pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
>> > pci 0000:00:00.0: BAR 0: set to [mem 0x01000000-0x010fffff] (PCI address
>> > [0x1000000-0x10
>> > fffff])
>> > pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
>>
>> You *are* assigning resources here; I'm not sure why we're trying to
>> bind the pcieport driver before resource assignment.  That seems out
>> of order.
>
> Could it be a bug in the PCIe subsystem then ?

More likely an arm issue, since other platforms aren't seeing this problem.

>> > pci 0000:00:00.0: PCI bridge to [bus 01]
>> > pci 0000:00:00.0: PCI bridge to [bus 01]
>> > pci_bus 0000:00: resource 4 [io  0x1000-0x10000]
>> > pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
>> >
>> > What is this conflicting device 0000:00:01 I observe here? Does it have
>> > to do with the switch ?
>>
>> I don't see a 0000:00:01.  That's not a complete PCI ID anyway; it
>> means domain 0000, bus 00, device 01, but there's no function number.
>
> It is there somewhere around the middle of the log I pasted, see:
>
> -->8--
> pci_bus 0000:01: scanning bus
> pci_bus 0000:01: fixups for bus
> PCI: bus1: Fast back to back transfers enabled
> pci_bus 0000:01: bus scan returning with max=01
> pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> pci_bus 0000:00: bus scan returning with max=01
> pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 01

Oh, you mean just "0000:01" (not "0000:00:01").  That refers to bus
01, not to any specific device.  And we aren't seeing a conflict
related to it.

Bjorn

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Tim Harvey]

On Thu, Oct 10, 2013 at 3:40 AM, Zhu Richard-R65037
<r65037@freescale.com> wrote:

>      host=10.192.242.95, domain=ap.freescale.net, nis-domain=(none)
>      bootserver=0.0.0.0, rootserver=10.192.225.216, rootpath=
>      nameserver0=10.192.130.201, nameserver1=10.211.0.3, nameserver2=10.196.51.200
> ALSA device list:
>   #0: wm8962-audio
>   #1: imx-hdmi-soc
> VFS: Mounted root (nfs filesystem) on device 0:11.
> devtmpfs: mounted
> Freeing unused kernel memory: 300K (80c29000 - 80c74000)
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b  ? <--System panic here sometimes. :(

Marek,

This is where an imprecise abort is triggered - refer to my comments
regarding the abort handler at
http://thread.gmane.org/gmane.linux.drivers.devicetree/44659/focus=46171
- you should disable the bumping of the PC and/or the handler.

Did this patch ever get applied and if so what git tree?  I would like
to continue testing it as well with the boards I have that have a
switch.

Tim

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Tim,

> On Thu, Oct 10, 2013 at 3:40 AM, Zhu Richard-R65037
> 
> <r65037@freescale.com> wrote:
> >      host=10.192.242.95, domain=ap.freescale.net, nis-domain=(none)
> >      bootserver=0.0.0.0, rootserver=10.192.225.216, rootpath=
> >      nameserver0=10.192.130.201, nameserver1=10.211.0.3,
> >      nameserver2=10.196.51.200
> > 
> > ALSA device list:
> >   #0: wm8962-audio
> >   #1: imx-hdmi-soc
> > 
> > VFS: Mounted root (nfs filesystem) on device 0:11.
> > devtmpfs: mounted
> > Freeing unused kernel memory: 300K (80c29000 - 80c74000)
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b 
> > ? <--System panic here sometimes. :(
> 
> Marek,
> 
> This is where an imprecise abort is triggered - refer to my comments
> regarding the abort handler at
> http://thread.gmane.org/gmane.linux.drivers.devicetree/44659/focus=46171
> - you should disable the bumping of the PC and/or the handler.

Good point.

> Did this patch ever get applied and if so what git tree?  I would like
> to continue testing it as well with the boards I have that have a
> switch.

V7 has the handler, yes.

http://patchwork.ozlabs.org/patch/278088/
http://patchwork.ozlabs.org/patch/278087/

You will also need to dig out the arm-specific portion from v6 3/3 so that the 
PCIe would probe:

http://patchwork.ozlabs.org/patch/275169/

And apply the clock patch:

http://patchwork.ozlabs.org/patch/275167/

Do you have any luck working with the bridge? I have this resource collision as 
seen in this thread.

Best regards,
Marek Vasut

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Marek Vasut]

Some boards do not have a PCIe reset GPIO. To avoid probe
failure on these boards, make the reset GPIO optional as
well.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Richard Zhu <r65037@freescale.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sean Cross <xobs@kosagi.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
 drivers/pci/host/pci-imx6.c | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index d3639aa..8e7adce 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -220,9 +220,12 @@ static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
 	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);
+	/* Some boards don't have PCIe reset GPIO. */
+	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
+		gpio_set_value(imx6_pcie->reset_gpio, 0);
+		msleep(100);
+		gpio_set_value(imx6_pcie->reset_gpio, 1);
+	}
 
 	return 0;
 }
@@ -447,17 +450,15 @@ static int __init imx6_pcie_probe(struct platform_device *pdev)
 
 	/* 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;
+	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
+		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);
-- 
1.8.4.rc3

[PATCH 2/2] PCI: imx6: Fix the clock for PCIe

[Marek Vasut]

The clk #205 are lvds_sel, not lvds_gate , so fix this. Moreover,
the PCIe needs lvds_gate for successful operation, so make the PCIe
driver enable (set as output) the lvds_gate .

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Richard Zhu <r65037@freescale.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sean Cross <xobs@kosagi.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
 arch/arm/boot/dts/imx6qdl.dtsi |  6 +++---
 drivers/pci/host/pci-imx6.c    | 19 ++++++++++++++++++-
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 3d8874a..b8601ea 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -127,9 +127,9 @@
 				  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";
+			clocks = <&clks 189>, <&clks 187>, <&clks 205>, <&clks 144>, <&clks 207>;
+			clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_sel", "pcie_axi", "lvds_gate";
+			status = "okay";
 		};
 
 		pmu {
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 8e7adce..32b30ca 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -35,6 +35,7 @@ struct imx6_pcie {
 	int			power_on_gpio;
 	int			wake_up_gpio;
 	int			disable_gpio;
+	struct clk		*lvds_sel;
 	struct clk		*lvds_gate;
 	struct clk		*sata_ref_100m;
 	struct clk		*pcie_ref_125m;
@@ -255,6 +256,12 @@ static int imx6_pcie_deassert_core_reset(struct pcie_port *pp)
 		goto err_pcie_ref;
 	}
 
+	ret = clk_prepare_enable(imx6_pcie->lvds_sel);
+	if (ret) {
+		dev_err(pp->dev, "unable to enable lvds_sel\n");
+		goto err_lvds_sel;
+	}
+
 	ret = clk_prepare_enable(imx6_pcie->lvds_gate);
 	if (ret) {
 		dev_err(pp->dev, "unable to enable lvds_gate\n");
@@ -273,8 +280,10 @@ static int imx6_pcie_deassert_core_reset(struct pcie_port *pp)
 	return 0;
 
 err_pcie_axi:
-	clk_disable_unprepare(imx6_pcie->lvds_gate);
+	clk_disable_unprepare(imx6_pcie->lvds_sel);
 err_lvds_gate:
+	clk_disable_unprepare(imx6_pcie->lvds_gate);
+err_lvds_sel:
 	clk_disable_unprepare(imx6_pcie->pcie_ref_125m);
 err_pcie_ref:
 	clk_disable_unprepare(imx6_pcie->sata_ref_100m);
@@ -498,6 +507,14 @@ static int __init imx6_pcie_probe(struct platform_device *pdev)
 	}
 
 	/* Fetch clocks */
+	imx6_pcie->lvds_sel = devm_clk_get(&pdev->dev, "lvds_sel");
+	if (IS_ERR(imx6_pcie->lvds_sel)) {
+		dev_err(&pdev->dev,
+			"lvds_sel clock select missing or invalid\n");
+		ret = PTR_ERR(imx6_pcie->lvds_sel);
+		goto err;
+	}
+
 	imx6_pcie->lvds_gate = devm_clk_get(&pdev->dev, "lvds_gate");
 	if (IS_ERR(imx6_pcie->lvds_gate)) {
 		dev_err(&pdev->dev,
-- 
1.8.4.rc3

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Bjorn,

> On Thu, Oct 10, 2013 at 11:39 AM, Marek Vasut <marex@denx.de> wrote:
> > Hi Bjorn,
> > 
> >> [+cc Yinghai]
> >> 
> >> On Thu, Oct 10, 2013 at 9:58 AM, Marek Vasut <marex@denx.de> wrote:
> >> >> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
> >> > I tried you suggestion, this is what I got now (and with V7 of the
> >> > patches):
> >> > 
> >> > Note that my topology is: rootport->2_port_switch->ethernet_chip , the
> >> > other port of the switch is not used .
> >> > 
> >> > imx6q-pcie 1ffc000.pcie: phy link never came up

After discussing with Tim a little, looks like a clock bit was missing. The 
above line was the cause of all the issues. Now I can probe the bus, but I still 
need more patches:

This dirty patch here limits the PCIe operation to GEN1 only. It's based on this 
Freescale patch [1]. Without this change, the PCIe switch is not detected. Any 
idea why? (I also had to increase the PHY startup delay to get GEN1 going).

[1] https://www.osadl.org/monitoring/patches/r8s7/1342-ENGR00180230-MX6-PCIE-
enlarge-the-eye-diagram-and-fo.patch

diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 32b30ca..df2838b 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -330,13 +330,16 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
 
        dw_pcie_setup_rc(pp);
 
+// Enable GEN1
+writel(((readl(pp->dbi_base + 0x7c) & 0xfffffff0) | 0x1), pp->dbi_base + 0x7c);
+
        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) {
+               if (count >= 200) {
                        dev_err(pp->dev, "phy link never came up\n");
                        dev_dbg(pp->dev,
                                "DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi,

> Hi Bjorn,
> 
> > On Thu, Oct 10, 2013 at 11:39 AM, Marek Vasut <marex@denx.de> wrote:
> > > Hi Bjorn,
> > > 
> > >> [+cc Yinghai]
> > >> 
> > >> On Thu, Oct 10, 2013 at 9:58 AM, Marek Vasut <marex@denx.de> wrote:
> > >> >> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
> > >> > I tried you suggestion, this is what I got now (and with V7 of the
> > >> > patches):
> > >> > 
> > >> > Note that my topology is: rootport->2_port_switch->ethernet_chip ,
> > >> > the other port of the switch is not used .
> > >> > 
> > >> > imx6q-pcie 1ffc000.pcie: phy link never came up
> 
> After discussing with Tim a little, looks like a clock bit was missing. The
> above line was the cause of all the issues. Now I can probe the bus, but I
> still need more patches:
> 
> This dirty patch here limits the PCIe operation to GEN1 only. It's based on
> this Freescale patch [1]. Without this change, the PCIe switch is not
> detected. Any idea why? (I also had to increase the PHY startup delay to
> get GEN1 going).
> 
> [1]
> https://www.osadl.org/monitoring/patches/r8s7/1342-ENGR00180230-MX6-PCIE-
> enlarge-the-eye-diagram-and-fo.patch
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 32b30ca..df2838b 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -330,13 +330,16 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
> 
>         dw_pcie_setup_rc(pp);
> 
> +// Enable GEN1
> +writel(((readl(pp->dbi_base + 0x7c) & 0xfffffff0) | 0x1), pp->dbi_base +
> 0x7c); +
>         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) {
> +               if (count >= 200) {
>                         dev_err(pp->dev, "phy link never came up\n");
>                         dev_dbg(pp->dev,
>                                 "DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
> 

The lspci now also looks much better.

~ # lspci 
00:00.0 Class 0604: 16c3:abcd
01:00.0 Class 0604: 12d8:2303
02:01.0 Class 0604: 12d8:2303
02:02.0 Class 0604: 12d8:2303
03:00.0 Class 0200: 8086:1531

And so does the probe log (but the pcieport failure still persists):

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_bus 0000:00: scanning bus
pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x5c
pci 0000:00:00.0: supports D1
pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci_bus 0000:00: fixups for bus
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: [12d8:2303] type 01 class 0x060400
pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x5c
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:00.0: PME# disabled
pci_bus 0000:01: fixups for bus
PCI: bus1: Fast back to back transfers disabled
pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0
pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:02: scanning bus
pci 0000:02:01.0: [12d8:2303] type 01 class 0x060400
pci 0000:02:01.0: calling pci_fixup_ide_bases+0x0/0x5c
pci 0000:02:01.0: supports D1 D2
pci 0000:02:01.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:02:01.0: PME# disabled
pci 0000:02:02.0: [12d8:2303] type 01 class 0x060400
pci 0000:02:02.0: calling pci_fixup_ide_bases+0x0/0x5c
pci 0000:02:02.0: supports D1 D2
pci 0000:02:02.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:02:02.0: PME# disabled
pci_bus 0000:02: fixups for bus
PCI: bus2: Fast back to back transfers disabled
pci 0000:02:01.0: scanning [bus 03-03] behind bridge, pass 0
pci 0000:02:02.0: scanning [bus 04-04] behind bridge, pass 0
pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:03: scanning bus
pci 0000:03:00.0: [8086:1531] type 00 class 0x020000
pci 0000:03:00.0: reg 0x10: [mem 0x01000000-0x017fffff]
pci 0000:03:00.0: reg 0x18: [io  0x1000-0x101f]
pci 0000:03:00.0: reg 0x1c: [mem 0x01800000-0x01803fff]
pci 0000:03:00.0: calling pci_fixup_ide_bases+0x0/0x5c
pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
pci 0000:03:00.0: PME# disabled
pci_bus 0000:03: fixups for bus
PCI: bus3: Fast back to back transfers disabled
pci_bus 0000:03: bus scan returning with max=03
pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
pci 0000:02:02.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:04: scanning bus
pci_bus 0000:04: fixups for bus
PCI: bus4: Fast back to back transfers enabled
pci_bus 0000:04: bus scan returning with max=04
pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
pci_bus 0000:02: bus scan returning with max=04
pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 04
pci_bus 0000:01: bus scan returning with max=04
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04
pci_bus 0000:00: bus scan returning with max=04
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 04
PCI: Device 0000:00:00.0 not available because of resource collisions
pcieport: probe of 0000:00:00.0 failed with error -22
PCI: Device 0000:00:00.0 not available because of resource collisions
pci 0000:00:00.0: Error enabling bridge (-22), continuing
PCI: enabling device 0000:01:00.0 (0140 -> 0143)
pcieport 0000:01:00.0: enabling bus mastering
PCI: Device 0000:00:00.0 not available because of resource collisions
pci 0000:00:00.0: Error enabling bridge (-22), continuing
PCI: Device 0000:00:00.0 not available because of resource collisions
pci 0000:00:00.0: Error enabling bridge (-22), continuing
pci 0000:03:00.0: calling quirk_e100_interrupt+0x0/0x20c
pci 0000:00:00.0: fixup irq: got 155
pci 0000:00:00.0: assigning IRQ 155
pcieport 0000:01:00.0: fixup irq: got 0
pcieport 0000:01:00.0: assigning IRQ 00
pcieport 0000:02:01.0: fixup irq: got 0
pcieport 0000:02:01.0: assigning IRQ 00
pcieport 0000:02:02.0: fixup irq: got 0
pcieport 0000:02:02.0: assigning IRQ 00
pci 0000:03:00.0: fixup irq: got 155
pci 0000:03:00.0: assigning IRQ 155
pci 0000:00:00.0: BAR 8: assigned [mem 0x01000000-0x01bfffff]
pci 0000:00:00.0: BAR 0: assigned [mem 0x01c00000-0x01cfffff]
pci 0000:00:00.0: BAR 0: set to [mem 0x01c00000-0x01cfffff] (PCI address 
[0x1c00000-0x1c
fffff])
pci 0000:00:00.0: BAR 6: assigned [mem 0x01d00000-0x01d0ffff pref]
pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
pcieport 0000:01:00.0: BAR 8: assigned [mem 0x01000000-0x01bfffff]
pcieport 0000:01:00.0: BAR 7: assigned [io  0x1000-0x1fff]
pcieport 0000:02:01.0: BAR 8: assigned [mem 0x01000000-0x01bfffff]
pcieport 0000:02:01.0: BAR 7: assigned [io  0x1000-0x1fff]
pci 0000:03:00.0: BAR 0: assigned [mem 0x01000000-0x017fffff]
pci 0000:03:00.0: BAR 0: set to [mem 0x01000000-0x017fffff] (PCI address 
[0x1000000-0x17
fffff])
pci 0000:03:00.0: BAR 3: assigned [mem 0x01800000-0x01803fff]
pci 0000:03:00.0: BAR 3: set to [mem 0x01800000-0x01803fff] (PCI address 
[0x1800000-0x18
03fff])
pci 0000:03:00.0: BAR 2: assigned [io  0x1000-0x101f]
pci 0000:03:00.0: BAR 2: set to [io  0x1000-0x101f] (PCI address 
[0x1000-0x101f])
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 0x01000000-0x01bfffff]
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 0x01000000-0x01bfffff]
pci_bus 0000:00: resource 4 [io  0x1000-0x10000]
pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
pci_bus 0000:01: resource 1 [mem 0x01000000-0x01bfffff]
pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
pci_bus 0000:02: resource 1 [mem 0x01000000-0x01bfffff]
pci_bus 0000:03: resource 0 [io  0x1000-0x1fff]
pci_bus 0000:03: resource 1 [mem 0x01000000-0x01bfffff]

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Zhu Richard-R65037]

Hi Marek:
In order to setup the irq properly when the PCIe switch is used.
Did you update the map_irq function in pcie_designware.c driver?
Here is the patch used by me when I trying to bring up the PCIe switch at my side.
Patch is attached.


Best Regards
Richard Zhu


-----Original Message-----
From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] On Behalf Of Marek Vasut
Sent: Friday, October 11, 2013 10:19 AM
To: Bjorn Helgaas
Cc: Zhu Richard-R65037; linux-arm-kernel at lists.infradead.org; Shawn Guo; linux-pci at vger.kernel.org; tharvey at gateworks.com; Frank Li; Sean Cross; Sascha Hauer; Yinghai Lu
Subject: Re: [PATCH v7 0/2] Add PCIe support for i.MX6q

Hi,

> Hi Bjorn,
> 
> > On Thu, Oct 10, 2013 at 11:39 AM, Marek Vasut <marex@denx.de> wrote:
> > > Hi Bjorn,
> > > 
> > >> [+cc Yinghai]
> > >> 
> > >> On Thu, Oct 10, 2013 at 9:58 AM, Marek Vasut <marex@denx.de> wrote:
> > >> >> On Thu, Oct 10, 2013 at 4:25 AM, Marek Vasut <marex@denx.de> wrote:
> > >> > I tried you suggestion, this is what I got now (and with V7 of 
> > >> > the
> > >> > patches):
> > >> > 
> > >> > Note that my topology is: 
> > >> > rootport->2_port_switch->ethernet_chip , the other port of the switch is not used .
> > >> > 
> > >> > imx6q-pcie 1ffc000.pcie: phy link never came up
> 
> After discussing with Tim a little, looks like a clock bit was 
> missing. The above line was the cause of all the issues. Now I can 
> probe the bus, but I still need more patches:
> 
> This dirty patch here limits the PCIe operation to GEN1 only. It's 
> based on this Freescale patch [1]. Without this change, the PCIe 
> switch is not detected. Any idea why? (I also had to increase the PHY 
> startup delay to get GEN1 going).
> 
> [1]
> https://www.osadl.org/monitoring/patches/r8s7/1342-ENGR00180230-MX6-PC
> IE-
> enlarge-the-eye-diagram-and-fo.patch
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c 
> index 32b30ca..df2838b 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -330,13 +330,16 @@ static void imx6_pcie_host_init(struct pcie_port 
> *pp)
> 
>         dw_pcie_setup_rc(pp);
> 
> +// Enable GEN1
> +writel(((readl(pp->dbi_base + 0x7c) & 0xfffffff0) | 0x1), 
> +pp->dbi_base +
> 0x7c); +
>         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) {
> +               if (count >= 200) {
>                         dev_err(pp->dev, "phy link never came up\n");
>                         dev_dbg(pp->dev,
>                                 "DEBUG_R0: 0x%08x, DEBUG_R1: 
> 0x%08x\n",
> 

The lspci now also looks much better.

~ # lspci
00:00.0 Class 0604: 16c3:abcd
01:00.0 Class 0604: 12d8:2303
02:01.0 Class 0604: 12d8:2303
02:02.0 Class 0604: 12d8:2303
03:00.0 Class 0200: 8086:1531

And so does the probe log (but the pcieport failure still persists):

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_bus 0000:00: scanning bus pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x5c pci 0000:00:00.0: supports D1 pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold pci 0000:00:00.0: PME# disabled pci_bus 0000:00: fixups for bus
PCI: bus0: Fast back to back transfers disabled pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0 pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:01: scanning bus pci 0000:01:00.0: [12d8:2303] type 01 class 0x060400 pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x5c pci 0000:01:00.0: supports D1 D2 pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold pci 0000:01:00.0: PME# disabled pci_bus 0000:01: fixups for bus
PCI: bus1: Fast back to back transfers disabled pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0 pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:02: scanning bus pci 0000:02:01.0: [12d8:2303] type 01 class 0x060400 pci 0000:02:01.0: calling pci_fixup_ide_bases+0x0/0x5c pci 0000:02:01.0: supports D1 D2 pci 0000:02:01.0: PME# supported from D0 D1 D2 D3hot D3cold pci 0000:02:01.0: PME# disabled pci 0000:02:02.0: [12d8:2303] type 01 class 0x060400 pci 0000:02:02.0: calling pci_fixup_ide_bases+0x0/0x5c pci 0000:02:02.0: supports D1 D2 pci 0000:02:02.0: PME# supported from D0 D1 D2 D3hot D3cold pci 0000:02:02.0: PME# disabled pci_bus 0000:02: fixups for bus
PCI: bus2: Fast back to back transfers disabled pci 0000:02:01.0: scanning [bus 03-03] behind bridge, pass 0 pci 0000:02:02.0: scanning [bus 04-04] behind bridge, pass 0 pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:03: scanning bus pci 0000:03:00.0: [8086:1531] type 00 class 0x020000 pci 0000:03:00.0: reg 0x10: [mem 0x01000000-0x017fffff] pci 0000:03:00.0: reg 0x18: [io  0x1000-0x101f] pci 0000:03:00.0: reg 0x1c: [mem 0x01800000-0x01803fff] pci 0000:03:00.0: calling pci_fixup_ide_bases+0x0/0x5c pci 0000:03:00.0: PME# supported from D0 D3hot D3cold pci 0000:03:00.0: PME# disabled pci_bus 0000:03: fixups for bus
PCI: bus3: Fast back to back transfers disabled pci_bus 0000:03: bus scan returning with max=03 pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03 pci 0000:02:02.0: scanning [bus 00-00] behind bridge, pass 1 pci_bus 0000:04: scanning bus pci_bus 0000:04: fixups for bus
PCI: bus4: Fast back to back transfers enabled pci_bus 0000:04: bus scan returning with max=04 pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04 pci_bus 0000:02: bus scan returning with max=04 pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 04 pci_bus 0000:01: bus scan returning with max=04 pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04 pci_bus 0000:00: bus scan returning with max=04 pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 04
PCI: Device 0000:00:00.0 not available because of resource collisions
pcieport: probe of 0000:00:00.0 failed with error -22
PCI: Device 0000:00:00.0 not available because of resource collisions pci 0000:00:00.0: Error enabling bridge (-22), continuing
PCI: enabling device 0000:01:00.0 (0140 -> 0143) pcieport 0000:01:00.0: enabling bus mastering
PCI: Device 0000:00:00.0 not available because of resource collisions pci 0000:00:00.0: Error enabling bridge (-22), continuing
PCI: Device 0000:00:00.0 not available because of resource collisions pci 0000:00:00.0: Error enabling bridge (-22), continuing pci 0000:03:00.0: calling quirk_e100_interrupt+0x0/0x20c pci 0000:00:00.0: fixup irq: got 155 pci 0000:00:00.0: assigning IRQ 155 pcieport 0000:01:00.0: fixup irq: got 0 pcieport 0000:01:00.0: assigning IRQ 00 pcieport 0000:02:01.0: fixup irq: got 0 pcieport 0000:02:01.0: assigning IRQ 00 pcieport 0000:02:02.0: fixup irq: got 0 pcieport 0000:02:02.0: assigning IRQ 00 pci 0000:03:00.0: fixup irq: got 155 pci 0000:03:00.0: assigning IRQ 155 pci 0000:00:00.0: BAR 8: assigned [mem 0x01000000-0x01bfffff] pci 0000:00:00.0: BAR 0: assigned [mem 0x01c00000-0x01cfffff] pci 0000:00:00.0: BAR 0: set to [mem 0x01c00000-0x01cfffff] (PCI address [0x1c00000-0x1c
fffff])
pci 0000:00:00.0: BAR 6: assigned [mem 0x01d00000-0x01d0ffff pref] pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff] pcieport 0000:01:00.0: BAR 8: assigned [mem 0x01000000-0x01bfffff] pcieport 0000:01:00.0: BAR 7: assigned [io  0x1000-0x1fff] pcieport 0000:02:01.0: BAR 8: assigned [mem 0x01000000-0x01bfffff] pcieport 0000:02:01.0: BAR 7: assigned [io  0x1000-0x1fff] pci 0000:03:00.0: BAR 0: assigned [mem 0x01000000-0x017fffff] pci 0000:03:00.0: BAR 0: set to [mem 0x01000000-0x017fffff] (PCI address
[0x1000000-0x17
fffff])
pci 0000:03:00.0: BAR 3: assigned [mem 0x01800000-0x01803fff] pci 0000:03:00.0: BAR 3: set to [mem 0x01800000-0x01803fff] (PCI address
[0x1800000-0x18
03fff])
pci 0000:03:00.0: BAR 2: assigned [io  0x1000-0x101f] pci 0000:03:00.0: BAR 2: set to [io  0x1000-0x101f] (PCI address
[0x1000-0x101f])
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 0x01000000-0x01bfffff]
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 0x01000000-0x01bfffff]
pci_bus 0000:00: resource 4 [io  0x1000-0x10000] pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff] pci_bus 0000:01: resource 0 [io  0x1000-0x1fff] pci_bus 0000:01: resource 1 [mem 0x01000000-0x01bfffff] pci_bus 0000:02: resource 0 [io  0x1000-0x1fff] pci_bus 0000:02: resource 1 [mem 0x01000000-0x01bfffff] pci_bus 0000:03: resource 0 [io  0x1000-0x1fff] pci_bus 0000:03: resource 1 [mem 0x01000000-0x01bfffff]

Best regards,
Marek Vasut
--
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-pcie-correct-the-irq-map-when-pcie-switch-is-used.patch
Type: application/octet-stream
Size: 1068 bytes
Desc: 0001-pcie-correct-the-irq-map-when-pcie-switch-is-used.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131011/e30598e8/attachment-0001.obj>

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Yinghai Lu]

On Thu, Oct 10, 2013 at 7:18 PM, Marek Vasut <marex@denx.de> wrote:

> And so does the probe log (but the pcieport failure still persists):
>

> pci_bus 0000:04: bus scan returning with max=04
> pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
> pci_bus 0000:02: bus scan returning with max=04
> pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 04
> pci_bus 0000:01: bus scan returning with max=04
> pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04
> pci_bus 0000:00: bus scan returning with max=04
> pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 04
> PCI: Device 0000:00:00.0 not available because of resource collisions
> pcieport: probe of 0000:00:00.0 failed with error -22

load pcieport driver too early.

> PCI: Device 0000:00:00.0 not available because of resource collisions
> pci 0000:00:00.0: Error enabling bridge (-22), continuing
> PCI: enabling device 0000:01:00.0 (0140 -> 0143)
> pcieport 0000:01:00.0: enabling bus mastering
> PCI: Device 0000:00:00.0 not available because of resource collisions
> pci 0000:00:00.0: Error enabling bridge (-22), continuing
> PCI: Device 0000:00:00.0 not available because of resource collisions
> pci 0000:00:00.0: Error enabling bridge (-22), continuing
> pci 0000:03:00.0: calling quirk_e100_interrupt+0x0/0x20c
> pci 0000:00:00.0: fixup irq: got 155
> pci 0000:00:00.0: assigning IRQ 155
> pcieport 0000:01:00.0: fixup irq: got 0
> pcieport 0000:01:00.0: assigning IRQ 00
> pcieport 0000:02:01.0: fixup irq: got 0
> pcieport 0000:02:01.0: assigning IRQ 00
> pcieport 0000:02:02.0: fixup irq: got 0
> pcieport 0000:02:02.0: assigning IRQ 00
> pci 0000:03:00.0: fixup irq: got 155
> pci 0000:03:00.0: assigning IRQ 155
> pci 0000:00:00.0: BAR 8: assigned [mem 0x01000000-0x01bfffff]
> pci 0000:00:00.0: BAR 0: assigned [mem 0x01c00000-0x01cfffff]
> pci 0000:00:00.0: BAR 0: set to [mem 0x01c00000-0x01cfffff] (PCI address
> [0x1c00000-0x1c
> fffff])
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01d00000-0x01d0ffff pref]
> pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
> pcieport 0000:01:00.0: BAR 8: assigned [mem 0x01000000-0x01bfffff]
> pcieport 0000:01:00.0: BAR 7: assigned [io  0x1000-0x1fff]
> pcieport 0000:02:01.0: BAR 8: assigned [mem 0x01000000-0x01bfffff]
> pcieport 0000:02:01.0: BAR 7: assigned [io  0x1000-0x1fff]
> pci 0000:03:00.0: BAR 0: assigned [mem 0x01000000-0x017fffff]
> pci 0000:03:00.0: BAR 0: set to [mem 0x01000000-0x017fffff] (PCI address
> [0x1000000-0x17
> fffff])
> pci 0000:03:00.0: BAR 3: assigned [mem 0x01800000-0x01803fff]
> pci 0000:03:00.0: BAR 3: set to [mem 0x01800000-0x01803fff] (PCI address
> [0x1800000-0x18
> 03fff])
> pci 0000:03:00.0: BAR 2: assigned [io  0x1000-0x101f]
> pci 0000:03:00.0: BAR 2: set to [io  0x1000-0x101f] (PCI address
> [0x1000-0x101f])
> 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 0x01000000-0x01bfffff]
> 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 0x01000000-0x01bfffff]
> pci_bus 0000:00: resource 4 [io  0x1000-0x10000]
> pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
> pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:01: resource 1 [mem 0x01000000-0x01bfffff]
> pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:02: resource 1 [mem 0x01000000-0x01bfffff]
> pci_bus 0000:03: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:03: resource 1 [mem 0x01000000-0x01bfffff]

Looks your arch call pci_assign_unassigned_resources() too late.

you should have call it with fs_initcall()...

please try to boot with "debug ignore_loglevel initcall_debug" to sort out
the initcall sequence.

Yinghai

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Jingoo Han]

On Friday, October 11, 2013 11:13 AM, Marek Vasut wrote:
> 
> Some boards do not have a PCIe reset GPIO. To avoid probe
> failure on these boards, make the reset GPIO optional as
> well.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Richard Zhu <r65037@freescale.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sean Cross <xobs@kosagi.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Yinghai Lu <yinghai@kernel.org>

Reviewed-by: Jingoo Han <jg1.han@samsung.com>

Best regards,
Jingoo Han

> ---
>  drivers/pci/host/pci-imx6.c | 29 +++++++++++++++--------------
>  1 file changed, 15 insertions(+), 14 deletions(-)

[PATCH 2/2] PCI: imx6: Fix the clock for PCIe

[Jingoo Han]

On Friday, October 11, 2013 11:13 AM, Marek Vasut wrote:
> 
> The clk #205 are lvds_sel, not lvds_gate , so fix this. Moreover,
> the PCIe needs lvds_gate for successful operation, so make the PCIe
> driver enable (set as output) the lvds_gate .
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Richard Zhu <r65037@freescale.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sean Cross <xobs@kosagi.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi |  6 +++---
>  drivers/pci/host/pci-imx6.c    | 19 ++++++++++++++++++-
>  2 files changed, 21 insertions(+), 4 deletions(-)

Hi Marek Vasut,

How about splitting this patch into two patches such as
arch part and driver part?

It is because driver part was merged into PCI tree by Bjorn Helgaas,[1]
and arch part was merged into i.MX tree by Shawn Guo.[2]
Thus, your patch can make the conflict issue.

For example,
  [PATCH 1/2] ARM: dts: imx6qdl: Fix the clock for PCIe
  [PATCH 2/2] PCI: imx6: Fix the clock for PCIe

Then, 1st patch can be merged to i.MX tree, and 2nd patch can be merged
to PCI tree.

If I am wrong, please let me know kindly. :-)

[1] http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=bb38919ec56e0758c3ae56dfc091dcde1391353e
[2] https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=commit;h=3a57291fa4ca7f7647d826f5b47082ef306d839f

Best regards,
Jingoo Han

[PATCH 2/2] PCI: imx6: Fix the clock for PCIe

[Marek Vasut]

Dear Jingoo Han,

> On Friday, October 11, 2013 11:13 AM, Marek Vasut wrote:
> > The clk #205 are lvds_sel, not lvds_gate , so fix this. Moreover,
> > the PCIe needs lvds_gate for successful operation, so make the PCIe
> > driver enable (set as output) the lvds_gate .
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Richard Zhu <r65037@freescale.com>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Sean Cross <xobs@kosagi.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> > 
> >  arch/arm/boot/dts/imx6qdl.dtsi |  6 +++---
> >  drivers/pci/host/pci-imx6.c    | 19 ++++++++++++++++++-
> >  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> Hi Marek Vasut,
> 
> How about splitting this patch into two patches such as
> arch part and driver part?
> 
> It is because driver part was merged into PCI tree by Bjorn Helgaas,[1]
> and arch part was merged into i.MX tree by Shawn Guo.[2]
> Thus, your patch can make the conflict issue.
> 
> For example,
>   [PATCH 1/2] ARM: dts: imx6qdl: Fix the clock for PCIe
>   [PATCH 2/2] PCI: imx6: Fix the clock for PCIe
> 
> Then, 1st patch can be merged to i.MX tree, and 2nd patch can be merged
> to PCI tree.
> 
> If I am wrong, please let me know kindly. :-)

By all means, you're right. Is the patch addressing the issue correctly (if we 
ignore that it's not split)? Shawn?

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Yinghai,

> On Thu, Oct 10, 2013 at 7:18 PM, Marek Vasut <marex@denx.de> wrote:
> > And so does the probe log (but the pcieport failure still persists):
> > 
> > 
> > pci_bus 0000:04: bus scan returning with max=04
> > pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
> > pci_bus 0000:02: bus scan returning with max=04
> > pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 04
> > pci_bus 0000:01: bus scan returning with max=04
> > pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04
> > pci_bus 0000:00: bus scan returning with max=04
> > pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 04
> > PCI: Device 0000:00:00.0 not available because of resource collisions
> > pcieport: probe of 0000:00:00.0 failed with error -22
> 
> load pcieport driver too early.

OK

[...]

> > pci_bus 0000:00: resource 4 [io  0x1000-0x10000]
> > pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
> > pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
> > pci_bus 0000:01: resource 1 [mem 0x01000000-0x01bfffff]
> > pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> > pci_bus 0000:02: resource 1 [mem 0x01000000-0x01bfffff]
> > pci_bus 0000:03: resource 0 [io  0x1000-0x1fff]
> > pci_bus 0000:03: resource 1 [mem 0x01000000-0x01bfffff]
> 
> Looks your arch call pci_assign_unassigned_resources() too late.
> 
> you should have call it with fs_initcall()...

You're right, the pci_assign_unassigned_resources() is called from probe() call 
of the MX6 PCIe driver, which is called from module_init().

imx6_pcie_init() -> imx6_pcie_probe() -> imx6_add_pcie_port() -> 
dw_pcie_host_init() -> pci_assign_unassigned_resources()

> please try to boot with "debug ignore_loglevel initcall_debug" to sort out
> the initcall sequence.

Yes, probing the MX6 PCIe driver in fs_initcall() actually fixed my issues:

diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 32b30ca..771892a 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c

@@ -587,7 +590,7 @@ static int __init imx6_pcie_init(void)
 {
        return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
 }                                                                                                                                                                          
-module_init(imx6_pcie_init);                                                                                                                                               
+fs_initcall(imx6_pcie_init);                                                                                                                                               
                                                                                                                                                                            
 MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");                                                                                                                             
 MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Tim Harvey]

Marek,

Looks like you and I are getting the same results now.  Device
enumeration is working fine through the switch however when I attempt
to use a device behind the switch (gige adapter in my case) I find
that I get a few interrupts to that devices irq handler then the
system hangs (like what occurs when a read is done to dbi without the
pcie controllers clock running).

Anyone have any ideas?

Tim

On Fri, Oct 11, 2013 at 7:44 AM, Marek Vasut <marex@denx.de> wrote:
> Hi Yinghai,
>
>> On Thu, Oct 10, 2013 at 7:18 PM, Marek Vasut <marex@denx.de> wrote:
>> > And so does the probe log (but the pcieport failure still persists):
>> >
>> >
>> > pci_bus 0000:04: bus scan returning with max=04
>> > pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
>> > pci_bus 0000:02: bus scan returning with max=04
>> > pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 04
>> > pci_bus 0000:01: bus scan returning with max=04
>> > pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04
>> > pci_bus 0000:00: bus scan returning with max=04
>> > pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 04
>> > PCI: Device 0000:00:00.0 not available because of resource collisions
>> > pcieport: probe of 0000:00:00.0 failed with error -22
>>
>> load pcieport driver too early.
>
> OK
>
> [...]
>
>> > pci_bus 0000:00: resource 4 [io  0x1000-0x10000]
>> > pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
>> > pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
>> > pci_bus 0000:01: resource 1 [mem 0x01000000-0x01bfffff]
>> > pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
>> > pci_bus 0000:02: resource 1 [mem 0x01000000-0x01bfffff]
>> > pci_bus 0000:03: resource 0 [io  0x1000-0x1fff]
>> > pci_bus 0000:03: resource 1 [mem 0x01000000-0x01bfffff]
>>
>> Looks your arch call pci_assign_unassigned_resources() too late.
>>
>> you should have call it with fs_initcall()...
>
> You're right, the pci_assign_unassigned_resources() is called from probe() call
> of the MX6 PCIe driver, which is called from module_init().
>
> imx6_pcie_init() -> imx6_pcie_probe() -> imx6_add_pcie_port() ->
> dw_pcie_host_init() -> pci_assign_unassigned_resources()
>
>> please try to boot with "debug ignore_loglevel initcall_debug" to sort out
>> the initcall sequence.
>
> Yes, probing the MX6 PCIe driver in fs_initcall() actually fixed my issues:
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 32b30ca..771892a 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
>
> @@ -587,7 +590,7 @@ static int __init imx6_pcie_init(void)
>  {
>         return platform_driver_probe(&imx6_pcie_driver, imx6_pcie_probe);
>  }
> -module_init(imx6_pcie_init);
> +fs_initcall(imx6_pcie_init);
>
>  MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");
>  MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
>
> Best regards,
> Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Dear Tim Harvey,

> Marek,
> 
> Looks like you and I are getting the same results now.  Device
> enumeration is working fine through the switch however when I attempt
> to use a device behind the switch (gige adapter in my case) I find
> that I get a few interrupts to that devices irq handler then the
> system hangs (like what occurs when a read is done to dbi without the
> pcie controllers clock running).
> 
> Anyone have any ideas?

Certainly. My Intel "igb" card now shows Link UP, sends about two packets and 
then the whole system freezes entirely. Not even my BDI3000 is able to "halt" it 
via JTAG.

btw. Tim, just a nit-pick. Top-posting into a public ML is frowned upon.

Best regards,
Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Zhu Richard-R65037]

Hi Tim:
As I know that the clock of pcie controller should be always running.
There are not clock gate on/off operations in host driver after the initialization.


Best Regards
Richard Zhu


-----Original Message-----
From: Tim Harvey [mailto:tharvey at gateworks.com] 
Sent: Friday, October 11, 2013 11:25 PM
To: Marek Vasut
Cc: Yinghai Lu; Bjorn Helgaas; Zhu Richard-R65037; linux-arm-kernel at lists.infradead.org; Shawn Guo; linux-pci at vger.kernel.org; Frank Li; Sean Cross; Sascha Hauer
Subject: Re: [PATCH v7 0/2] Add PCIe support for i.MX6q

Marek,

Looks like you and I are getting the same results now.  Device enumeration is working fine through the switch however when I attempt to use a device behind the switch (gige adapter in my case) I find that I get a few interrupts to that devices irq handler then the system hangs (like what occurs when a read is done to dbi without the pcie controllers clock running).

Anyone have any ideas?

Tim

On Fri, Oct 11, 2013 at 7:44 AM, Marek Vasut <marex@denx.de> wrote:
> Hi Yinghai,
>
>> On Thu, Oct 10, 2013 at 7:18 PM, Marek Vasut <marex@denx.de> wrote:
>> > And so does the probe log (but the pcieport failure still persists):
>> >
>> >
>> > pci_bus 0000:04: bus scan returning with max=04 pci_bus 0000:04: 
>> > busn_res: [bus 04-ff] end is updated to 04 pci_bus 0000:02: bus 
>> > scan returning with max=04 pci_bus 0000:02: busn_res: [bus 02-ff] 
>> > end is updated to 04 pci_bus 0000:01: bus scan returning with 
>> > max=04 pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04 
>> > pci_bus 0000:00: bus scan returning with max=04 pci_bus 0000:00: 
>> > busn_res: [bus 00-ff] end is updated to 04
>> > PCI: Device 0000:00:00.0 not available because of resource 
>> > collisions
>> > pcieport: probe of 0000:00:00.0 failed with error -22
>>
>> load pcieport driver too early.
>
> OK
>
> [...]
>
>> > pci_bus 0000:00: resource 4 [io  0x1000-0x10000] pci_bus 0000:00: 
>> > resource 5 [mem 0x01000000-0x01efffff] pci_bus 0000:01: resource 0 
>> > [io  0x1000-0x1fff] pci_bus 0000:01: resource 1 [mem 
>> > 0x01000000-0x01bfffff] pci_bus 0000:02: resource 0 [io  
>> > 0x1000-0x1fff] pci_bus 0000:02: resource 1 [mem 
>> > 0x01000000-0x01bfffff] pci_bus 0000:03: resource 0 [io  
>> > 0x1000-0x1fff] pci_bus 0000:03: resource 1 [mem 
>> > 0x01000000-0x01bfffff]
>>
>> Looks your arch call pci_assign_unassigned_resources() too late.
>>
>> you should have call it with fs_initcall()...
>
> You're right, the pci_assign_unassigned_resources() is called from 
> probe() call of the MX6 PCIe driver, which is called from module_init().
>
> imx6_pcie_init() -> imx6_pcie_probe() -> imx6_add_pcie_port() ->
> dw_pcie_host_init() -> pci_assign_unassigned_resources()
>
>> please try to boot with "debug ignore_loglevel initcall_debug" to 
>> sort out the initcall sequence.
>
> Yes, probing the MX6 PCIe driver in fs_initcall() actually fixed my issues:
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c 
> index 32b30ca..771892a 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
>
> @@ -587,7 +590,7 @@ static int __init imx6_pcie_init(void)  {
>         return platform_driver_probe(&imx6_pcie_driver, 
> imx6_pcie_probe);  } -module_init(imx6_pcie_init);
> +fs_initcall(imx6_pcie_init);
>
>  MODULE_AUTHOR("Sean Cross <xobs@kosagi.com>");  
> MODULE_DESCRIPTION("Freescale i.MX6 PCIe host controller driver");
>
> Best regards,
> Marek Vasut

[PATCH v7 0/2] Add PCIe support for i.MX6q

[Marek Vasut]

Hi Richard,

> Hi Tim:
> As I know that the clock of pcie controller should be always running.
> There are not clock gate on/off operations in host driver after the
> initialization.

I think the problem might happen when the PCIe device (Ethernet adapter) is bus-
master and either initiates PCIe->AXI->memory write or memory->AXI->PCIe read 
transfer. This is because when the Intel ethernet (igb) is probed, it only uses 
the MEM window that's mapped into the AXI space (that window at 0x01100000). On 
the other hand, when some packet is transfered, the Intel controller operates 
with structures in DRAM directly. And the stall only happens when the interface 
either receives or attempts to send a packet.

Is this theory of mine even reasonable? If this doesn't work properly, could 
this stall the CPU? How can I check if this works correctly? What can I try if 
it does not?

Thanks!

btw. Please be careful about the top-posting ;-)

Best regards,
Marek Vasut

[PATCH 2/2] PCI: imx6: Fix the clock for PCIe

[Shawn Guo]

On Fri, Oct 11, 2013 at 01:55:04PM +0200, Marek Vasut wrote:
> > It is because driver part was merged into PCI tree by Bjorn Helgaas,[1]
> > and arch part was merged into i.MX tree by Shawn Guo.[2]
> > Thus, your patch can make the conflict issue.
> > 
> > For example,
> >   [PATCH 1/2] ARM: dts: imx6qdl: Fix the clock for PCIe
> >   [PATCH 2/2] PCI: imx6: Fix the clock for PCIe
> > 
> > Then, 1st patch can be merged to i.MX tree, and 2nd patch can be merged
> > to PCI tree.
> > 
> > If I am wrong, please let me know kindly. :-)
> 
> By all means, you're right. Is the patch addressing the issue correctly (if we 
> ignore that it's not split)? Shawn?

I need to first understand if you are seeing the issue with the latest
linux-next like next-20131010.  Note, linux-next tree goes to
git://gitorious.org/thierryreding/linux-next [1] these days.

Shawn

[1] https://lkml.org/lkml/2013/9/30/179

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Shawn Guo]

On Fri, Oct 11, 2013 at 04:12:31AM +0200, Marek Vasut wrote:
> Some boards do not have a PCIe reset GPIO. To avoid probe
> failure on these boards, make the reset GPIO optional as
> well.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Richard Zhu <r65037@freescale.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Sean Cross <xobs@kosagi.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
>  drivers/pci/host/pci-imx6.c | 29 +++++++++++++++--------------
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index d3639aa..8e7adce 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -220,9 +220,12 @@ static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
>  	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);
> +	/* Some boards don't have PCIe reset GPIO. */
> +	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
> +		gpio_set_value(imx6_pcie->reset_gpio, 0);
> +		msleep(100);
> +		gpio_set_value(imx6_pcie->reset_gpio, 1);
> +	}
>  
>  	return 0;
>  }
> @@ -447,17 +450,15 @@ static int __init imx6_pcie_probe(struct platform_device *pdev)
>  
>  	/* 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;
> -	}

The 'reset-gpio' is documented as a required property in bindings doc
Documentation/devicetree/bindings/pci/designware-pcie.txt.  You need
to update bindings doc if you turn it into an optional property.

Shawn

> -	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;
> +	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
> +		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);
> -- 
> 1.8.4.rc3
> 

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Marek Vasut]

Dear Shawn Guo,

> On Fri, Oct 11, 2013 at 04:12:31AM +0200, Marek Vasut wrote:
> > Some boards do not have a PCIe reset GPIO. To avoid probe
> > failure on these boards, make the reset GPIO optional as
> > well.
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Richard Zhu <r65037@freescale.com>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Sean Cross <xobs@kosagi.com>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> > 
> >  drivers/pci/host/pci-imx6.c | 29 +++++++++++++++--------------
> >  1 file changed, 15 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> > index d3639aa..8e7adce 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -220,9 +220,12 @@ static int imx6_pcie_assert_core_reset(struct
> > pcie_port *pp)
> > 
> >  	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);
> > +	/* Some boards don't have PCIe reset GPIO. */
> > +	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
> > +		gpio_set_value(imx6_pcie->reset_gpio, 0);
> > +		msleep(100);
> > +		gpio_set_value(imx6_pcie->reset_gpio, 1);
> > +	}
> > 
> >  	return 0;
> >  
> >  }
> > 
> > @@ -447,17 +450,15 @@ static int __init imx6_pcie_probe(struct
> > platform_device *pdev)
> > 
> >  	/* 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;
> > -	}
> 
> The 'reset-gpio' is documented as a required property in bindings doc
> Documentation/devicetree/bindings/pci/designware-pcie.txt.  You need
> to update bindings doc if you turn it into an optional property.

That's true, thanks for pointing it out!

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Jingoo Han]

On Saturday, October 12, 2013 6:29 PM, Marek Vasut wrote:
> > On Fri, Oct 11, 2013 at 04:12:31AM +0200, Marek Vasut wrote:
> > > Some boards do not have a PCIe reset GPIO. To avoid probe
> > > failure on these boards, make the reset GPIO optional as
> > > well.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Cc: Frank Li <lznuaa@gmail.com>
> > > Cc: Richard Zhu <r65037@freescale.com>
> > > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > > Cc: Sean Cross <xobs@kosagi.com>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Tim Harvey <tharvey@gateworks.com>
> > > Cc: Yinghai Lu <yinghai@kernel.org>
> > > ---
> > >
> > >  drivers/pci/host/pci-imx6.c | 29 +++++++++++++++--------------
> > >  1 file changed, 15 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> > > index d3639aa..8e7adce 100644
> > > --- a/drivers/pci/host/pci-imx6.c
> > > +++ b/drivers/pci/host/pci-imx6.c
> > > @@ -220,9 +220,12 @@ static int imx6_pcie_assert_core_reset(struct
> > > pcie_port *pp)
> > >
> > >  	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);
> > > +	/* Some boards don't have PCIe reset GPIO. */
> > > +	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
> > > +		gpio_set_value(imx6_pcie->reset_gpio, 0);
> > > +		msleep(100);
> > > +		gpio_set_value(imx6_pcie->reset_gpio, 1);
> > > +	}
> > >
> > >  	return 0;
> > >
> > >  }
> > >
> > > @@ -447,17 +450,15 @@ static int __init imx6_pcie_probe(struct
> > > platform_device *pdev)
> > >
> > >  	/* 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;
> > > -	}
> >
> > The 'reset-gpio' is documented as a required property in bindings doc
> > Documentation/devicetree/bindings/pci/designware-pcie.txt.  You need
> > to update bindings doc if you turn it into an optional property.
> 
> That's true, thanks for pointing it out!

+cc Kishon Vijay Abraham I, Pratyush Anand, Mohit KUMAR

Yes, right.
"reset-gpio" property can be moved to an optional property.
Also, the patch to fix 'Designware' part such as 'designware-pcie.txt'
can be shared with other related people as below.

  - Samsung Exynos PCIe: Jingoo Han
  - ST Spear PCIe: Pratyush Anand, Mohit KUMAR
  - TI OMAP PCIe: Kishon Vijay Abraham I

Best regards,
Jingoo Han

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Marek Vasut]

Hello Han,

> On Saturday, October 12, 2013 6:29 PM, Marek Vasut wrote:
> > > On Fri, Oct 11, 2013 at 04:12:31AM +0200, Marek Vasut wrote:
> > > > Some boards do not have a PCIe reset GPIO. To avoid probe
> > > > failure on these boards, make the reset GPIO optional as
> > > > well.
> > > > 
> > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > > Cc: Frank Li <lznuaa@gmail.com>
> > > > Cc: Richard Zhu <r65037@freescale.com>
> > > > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > > > Cc: Sean Cross <xobs@kosagi.com>
> > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > Cc: Tim Harvey <tharvey@gateworks.com>
> > > > Cc: Yinghai Lu <yinghai@kernel.org>
> > > > ---
> > > > 
> > > >  drivers/pci/host/pci-imx6.c | 29 +++++++++++++++--------------
> > > >  1 file changed, 15 insertions(+), 14 deletions(-)
> > > > 
> > > > diff --git a/drivers/pci/host/pci-imx6.c
> > > > b/drivers/pci/host/pci-imx6.c index d3639aa..8e7adce 100644
> > > > --- a/drivers/pci/host/pci-imx6.c
> > > > +++ b/drivers/pci/host/pci-imx6.c
> > > > @@ -220,9 +220,12 @@ static int imx6_pcie_assert_core_reset(struct
> > > > pcie_port *pp)
> > > > 
> > > >  	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);
> > > > +	/* Some boards don't have PCIe reset GPIO. */
> > > > +	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
> > > > +		gpio_set_value(imx6_pcie->reset_gpio, 0);
> > > > +		msleep(100);
> > > > +		gpio_set_value(imx6_pcie->reset_gpio, 1);
> > > > +	}
> > > > 
> > > >  	return 0;
> > > >  
> > > >  }
> > > > 
> > > > @@ -447,17 +450,15 @@ static int __init imx6_pcie_probe(struct
> > > > platform_device *pdev)
> > > > 
> > > >  	/* 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;
> > > > -	}
> > > 
> > > The 'reset-gpio' is documented as a required property in bindings doc
> > > Documentation/devicetree/bindings/pci/designware-pcie.txt.  You need
> > > to update bindings doc if you turn it into an optional property.
> > 
> > That's true, thanks for pointing it out!
> 
> +cc Kishon Vijay Abraham I, Pratyush Anand, Mohit KUMAR
> 
> Yes, right.
> "reset-gpio" property can be moved to an optional property.
> Also, the patch to fix 'Designware' part such as 'designware-pcie.txt'
> can be shared with other related people as below.
> 
>   - Samsung Exynos PCIe: Jingoo Han
>   - ST Spear PCIe: Pratyush Anand, Mohit KUMAR
>   - TI OMAP PCIe: Kishon Vijay Abraham I

I'm in the process of rebasing the patches on top of next 2013-10-10. Right now 
I'm getting a crash in __write_msi_msg() when my Intel "igb" reports "enabling 
bus mastering" . Any quick idea? Seems like this MSI support is new in the pcie-
designware.c .

I'll just start plumbing to see what it is.

Best regards,
Marek Vasut

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Marek Vasut]

Hello Han,

> > On Saturday, October 12, 2013 6:29 PM, Marek Vasut wrote:
> > > > On Fri, Oct 11, 2013 at 04:12:31AM +0200, Marek Vasut wrote:
> > > > > Some boards do not have a PCIe reset GPIO. To avoid probe
> > > > > failure on these boards, make the reset GPIO optional as
> > > > > well.
> > > > > 
> > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > > > Cc: Frank Li <lznuaa@gmail.com>
> > > > > Cc: Richard Zhu <r65037@freescale.com>
> > > > > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > Cc: Sean Cross <xobs@kosagi.com>
> > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > > Cc: Tim Harvey <tharvey@gateworks.com>
> > > > > Cc: Yinghai Lu <yinghai@kernel.org>
> > > > > ---
> > > > > 
> > > > >  drivers/pci/host/pci-imx6.c | 29 +++++++++++++++--------------
> > > > >  1 file changed, 15 insertions(+), 14 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/pci/host/pci-imx6.c
> > > > > b/drivers/pci/host/pci-imx6.c index d3639aa..8e7adce 100644
> > > > > --- a/drivers/pci/host/pci-imx6.c
> > > > > +++ b/drivers/pci/host/pci-imx6.c
> > > > > @@ -220,9 +220,12 @@ static int imx6_pcie_assert_core_reset(struct
> > > > > pcie_port *pp)
> > > > > 
> > > > >  	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);
> > > > > +	/* Some boards don't have PCIe reset GPIO. */
> > > > > +	if (gpio_is_valid(imx6_pcie->reset_gpio)) {
> > > > > +		gpio_set_value(imx6_pcie->reset_gpio, 0);
> > > > > +		msleep(100);
> > > > > +		gpio_set_value(imx6_pcie->reset_gpio, 1);
> > > > > +	}
> > > > > 
> > > > >  	return 0;
> > > > >  
> > > > >  }
> > > > > 
> > > > > @@ -447,17 +450,15 @@ static int __init imx6_pcie_probe(struct
> > > > > platform_device *pdev)
> > > > > 
> > > > >  	/* 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;
> > > > > -	}
> > > > 
> > > > The 'reset-gpio' is documented as a required property in bindings doc
> > > > Documentation/devicetree/bindings/pci/designware-pcie.txt.  You need
> > > > to update bindings doc if you turn it into an optional property.
> > > 
> > > That's true, thanks for pointing it out!
> > 
> > +cc Kishon Vijay Abraham I, Pratyush Anand, Mohit KUMAR
> > 
> > Yes, right.
> > "reset-gpio" property can be moved to an optional property.
> > Also, the patch to fix 'Designware' part such as 'designware-pcie.txt'
> > can be shared with other related people as below.
> > 
> >   - Samsung Exynos PCIe: Jingoo Han
> >   - ST Spear PCIe: Pratyush Anand, Mohit KUMAR
> >   - TI OMAP PCIe: Kishon Vijay Abraham I
> 
> I'm in the process of rebasing the patches on top of next 2013-10-10. Right
> now I'm getting a crash in __write_msi_msg() when my Intel "igb" reports
> "enabling bus mastering" . Any quick idea? Seems like this MSI support is
> new in the pcie- designware.c .
> 
> I'll just start plumbing to see what it is.

Looks like irq_alloc_descs() return -EEXIST for me in assign_irq() . Noone 
checks the return value of it , so it can fail later on ;-) Now, why does it 
return -EEXIST in the first place? I'm sure someone more experienced with PCI 
would know right away .

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Jingoo Han]

On Monday, October 14, 2013 10:18 AM, Marek Vasut wrote:
> > > On Saturday, October 12, 2013 6:29 PM, Marek Vasut wrote:
> > > > > On Fri, Oct 11, 2013 at 04:12:31AM +0200, Marek Vasut wrote:

[.....]

> > > +cc Kishon Vijay Abraham I, Pratyush Anand, Mohit KUMAR
> > >
> > > Yes, right.
> > > "reset-gpio" property can be moved to an optional property.
> > > Also, the patch to fix 'Designware' part such as 'designware-pcie.txt'
> > > can be shared with other related people as below.
> > >
> > >   - Samsung Exynos PCIe: Jingoo Han
> > >   - ST Spear PCIe: Pratyush Anand, Mohit KUMAR
> > >   - TI OMAP PCIe: Kishon Vijay Abraham I
> >
> > I'm in the process of rebasing the patches on top of next 2013-10-10. Right
> > now I'm getting a crash in __write_msi_msg() when my Intel "igb" reports
> > "enabling bus mastering" . Any quick idea? Seems like this MSI support is
> > new in the pcie- designware.c .
> >
> > I'll just start plumbing to see what it is.
> 
> Looks like irq_alloc_descs() return -EEXIST for me in assign_irq() . Noone
> checks the return value of it , so it can fail later on ;-) Now, why does it
> return -EEXIST in the first place? I'm sure someone more experienced with PCI
> would know right away .

Hi Marek,

How about applying the following patch, which was made by Pratyush Anand? :-)
I am not sure; however, the patch resolved some problems that were found on
OMAP PCIe and Exynos PCIe, when MSI is enabled.

"PCI: designware: Add irq_create_mapping()"

http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/host-exynos&id=904d0e7889933fb48d921c998fd1cabb3a9d6635

Best regards,
Jingoo Han

[PATCH 1/2] PCI: imx6: Make reset-gpio optional

[Marek Vasut]

Hello Han,

> On Monday, October 14, 2013 10:18 AM, Marek Vasut wrote:
> > > > On Saturday, October 12, 2013 6:29 PM, Marek Vasut wrote:
> > > > > > On Fri, Oct 11, 2013 at 04:12:31AM +0200, Marek Vasut wrote:
> [.....]
> 
> > > > +cc Kishon Vijay Abraham I, Pratyush Anand, Mohit KUMAR
> > > > 
> > > > Yes, right.
> > > > "reset-gpio" property can be moved to an optional property.
> > > > Also, the patch to fix 'Designware' part such as
> > > > 'designware-pcie.txt' can be shared with other related people as
> > > > below.
> > > > 
> > > >   - Samsung Exynos PCIe: Jingoo Han
> > > >   - ST Spear PCIe: Pratyush Anand, Mohit KUMAR
> > > >   - TI OMAP PCIe: Kishon Vijay Abraham I
> > > 
> > > I'm in the process of rebasing the patches on top of next 2013-10-10.
> > > Right now I'm getting a crash in __write_msi_msg() when my Intel "igb"
> > > reports "enabling bus mastering" . Any quick idea? Seems like this MSI
> > > support is new in the pcie- designware.c .
> > > 
> > > I'll just start plumbing to see what it is.
> > 
> > Looks like irq_alloc_descs() return -EEXIST for me in assign_irq() .
> > Noone checks the return value of it , so it can fail later on ;-) Now,
> > why does it return -EEXIST in the first place? I'm sure someone more
> > experienced with PCI would know right away .
> 
> Hi Marek,
> 
> How about applying the following patch, which was made by Pratyush Anand?
> :-) I am not sure; however, the patch resolved some problems that were
> found on OMAP PCIe and Exynos PCIe, when MSI is enabled.
> 
> "PCI: designware: Add irq_create_mapping()"
> 
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/h
> ost-exynos&id=904d0e7889933fb48d921c998fd1cabb3a9d6635

Wow, thanks! I'll check it once I get some sleep, I've been at it for too long 
now.

btw. do you happen to have any idea why would the whole system freeze when I do 
"ifconfig up" on my PCIe-connected intel i210 ethernet adapter (driven by the 
"igb" driver)? It seems that upon reception or transmission of a single packet, 
the whole system freezes to a point where not even JTAG can break (halt) the CPU 
so I can figure out what the problem is. Interestingly enough, the whole probe 
routine of the "igb" driver finishes correctly, the hard-freeze only happens 
shortly after I see that the link is up. Any new ideas on why this might happen 
would be really helpful. Just for completeness, it seems Tim has the same issue 
on Marvell Yucon card (sky2 driver).

Thank you for your help again!

Best regards,
Marek Vasut