[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 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 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 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

Re: [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

[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

Re: [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

[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

Re: [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

[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

RE: [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@vger.kernel.org] On Behalf Of Marek Vasut
Sent: Wednesday, October 09, 2013 4:56 AM
To: linux-arm-kernel@lists.infradead.org
Cc: Bjorn Helgaas; Shawn Guo; Zhu Richard-R65037; linux-pci@vger.kernel.org; tharvey@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@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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

Re: [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

[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

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

[Zhu Richard-R65037]

SGkgTWFyZWsNClRoYW5rcyBmb3IgeW91ciBraW5kbHkgaGVscCBvbiB0aGUgaS5NWDYgUENJZSBz
d2l0Y2ggZGVidWcuDQoNCkkgZW5jb3VudGVyZWQgcmFuZG9tIHBhbmljIGFsdGhvdWdoIEkgYWRk
IHRoZSBpcnFfbWFwIGNvZGVzIHBhc3RlZCBiZWZvcmUuDQpTb21ldGltZXMgdGhlIHN3aXRjaCAr
IGVwIGRldmljZSBjYW4gd29yayB3ZWxsLCBidXQgc3lzdGVtIG1heWJlIHBhbmljIHNvbWV0aW1l
cy4gOigNCg0KSGVyZSBhcmUgdGhlIGxvZ3Mgd2hlbiBzeXN0ZW0gaXMgcGFuaWMuDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQppbXgtcGNpZSAxZmZjMDAwLnBjaWU6
IGxlZ2FjeV9pcnEgMTU1DQppbXgtcGNpZSAxZmZjMDAwLnBjaWU6IG1hcCBbbWVtIDB4MDFmZmMw
MDAtMHgwMWZmZmZmZl0NCmlteC1wY2llIDFmZmMwMDAucGNpZTogc3RhcnRpbmcgdG8gbGluayBw
Y2llIHBvcnQuDQppbXgtcGNpZSAxZmZjMDAwLnBjaWU6IExpbmsgdXANClBDSSBob3N0IGJyaWRn
ZSB0byBidXMgMDAwMDowMA0KcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbaW8g
IDB4MTAwMC0weDEwMDAwXQ0KcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVt
IDB4MDEwMDAwMDAtMHgwMWVmZmZmZl0NCnBjaV9idXMgMDAwMDowMDogTm8gYnVzbiByZXNvdXJj
ZSBmb3VuZCBmb3Igcm9vdCBidXMsIHdpbGwgdXNlIFtidXMgMDAtZmZdDQpQQ0k6IGJ1czA6IEZh
c3QgYmFjayB0byBiYWNrIHRyYW5zZmVycyBkaXNhYmxlZAkNClBDSTogYnVzMTogRmFzdCBiYWNr
IHRvIGJhY2sgdHJhbnNmZXJzIGRpc2FibGVkDQpwY2kgMDAwMDowMTowMC4wOiBicmlkZ2UgY29u
ZmlndXJhdGlvbiBpbnZhbGlkIChbYnVzIDAwLTAwXSksIHJlY29uZmlndXJpbmcNClBDSTogYnVz
MjogRmFzdCBiYWNrIHRvIGJhY2sgdHJhbnNmZXJzIGRpc2FibGVkDQpwY2kgMDAwMDowMjowMS4w
OiBicmlkZ2UgY29uZmlndXJhdGlvbiBpbnZhbGlkIChbYnVzIDAwLTAwXSksIHJlY29uZmlndXJp
bmcNCnBjaSAwMDAwOjAyOjAyLjA6IGJyaWRnZSBjb25maWd1cmF0aW9uIGludmFsaWQgKFtidXMg
MDAtMDBdKSwgcmVjb25maWd1cmluZw0KUENJOiBidXMzOiBGYXN0IGJhY2sgdG8gYmFjayB0cmFu
c2ZlcnMgZGlzYWJsZWQNClBDSTogYnVzNDogRmFzdCBiYWNrIHRvIGJhY2sgdHJhbnNmZXJzIGVu
YWJsZWQNCnBjaSAwMDAwOjAwOjAwLjA6IEJBUiAwOiBhc3NpZ25lZCBbbWVtIDB4MDEwMDAwMDAt
MHgwMTBmZmZmZl0NCnBjaSAwMDAwOjAwOjAwLjA6IEJBUiA4OiBhc3NpZ25lZCBbbWVtIDB4MDEx
MDAwMDAtMHgwMTFmZmZmZl0NCnBjaSAwMDAwOjAwOjAwLjA6IEJBUiA5OiBhc3NpZ25lZCBbbWVt
IDB4MDEyMDAwMDAtMHgwMTJmZmZmZiBwcmVmXQ0KcGNpIDAwMDA6MDA6MDAuMDogQkFSIDY6IGFz
c2lnbmVkIFttZW0gMHgwMTMwMDAwMC0weDAxMzBmZmZmIHByZWZdDQpwY2kgMDAwMDowMDowMC4w
OiBCQVIgNzogYXNzaWduZWQgW2lvICAweDEwMDAtMHgxZmZmXQ0KcGNpIDAwMDA6MDE6MDAuMDog
QkFSIDg6IGFzc2lnbmVkIFttZW0gMHgwMTEwMDAwMC0weDAxMWZmZmZmXQ0KcGNpIDAwMDA6MDE6
MDAuMDogQkFSIDk6IGFzc2lnbmVkIFttZW0gMHgwMTIwMDAwMC0weDAxMmZmZmZmIHByZWZdDQpw
Y2kgMDAwMDowMTowMC4wOiBCQVIgNzogYXNzaWduZWQgW2lvICAweDEwMDAtMHgxZmZmXQ0KcGNp
IDAwMDA6MDI6MDEuMDogQkFSIDg6IGFzc2lnbmVkIFttZW0gMHgwMTEwMDAwMC0weDAxMWZmZmZm
XQ0KcGNpIDAwMDA6MDI6MDEuMDogQkFSIDk6IGFzc2lnbmVkIFttZW0gMHgwMTIwMDAwMC0weDAx
MmZmZmZmIHByZWZdDQpwY2kgMDAwMDowMjowMS4wOiBCQVIgNzogYXNzaWduZWQgW2lvICAweDEw
MDAtMHgxZmZmXQ0KcGNpIDAwMDA6MDM6MDAuMDogQkFSIDE6IGFzc2lnbmVkIFttZW0gMHgwMTEw
MDAwMC0weDAxMTdmZmZmXQ0KcGNpIDAwMDA6MDM6MDAuMDogQkFSIDY6IGFzc2lnbmVkIFttZW0g
MHgwMTIwMDAwMC0weDAxMjNmZmZmIHByZWZdDQpwY2kgMDAwMDowMzowMC4wOiBCQVIgMDogYXNz
aWduZWQgW21lbSAweDAxMTgwMDAwLTB4MDExOWZmZmZdDQpwY2kgMDAwMDowMzowMC4wOiBCQVIg
MzogYXNzaWduZWQgW21lbSAweDAxMWEwMDAwLTB4MDExYTNmZmZdDQpwY2kgMDAwMDowMzowMC4w
OiBCQVIgMjogYXNzaWduZWQgW2lvICAweDEwMDAtMHgxMDFmXQ0KcGNpIDAwMDA6MDI6MDEuMDog
UENJIGJyaWRnZSB0byBbYnVzIDAzXQ0KcGNpIDAwMDA6MDI6MDEuMDogICBicmlkZ2Ugd2luZG93
IFtpbyAgMHgxMDAwLTB4MWZmZl0NCnBjaSAwMDAwOjAyOjAxLjA6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIDB4MDExMDAwMDAtMHgwMTFmZmZmZl0NCnBjaSAwMDAwOjAyOjAxLjA6ICAgYnJpZGdlIHdp
bmRvdyBbbWVtIDB4MDEyMDAwMDAtMHgwMTJmZmZmZiBwcmVmXQ0KcGNpIDAwMDA6MDI6MDIuMDog
UENJIGJyaWRnZSB0byBbYnVzIDA0XQ0KcGNpIDAwMDA6MDE6MDAuMDogUENJIGJyaWRnZSB0byBb
YnVzIDAyLTA0XQ0KcGNpIDAwMDA6MDE6MDAuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHgxMDAw
LTB4MWZmZl0NCnBjaSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDExMDAw
MDAtMHgwMTFmZmZmZl0NCnBjaSAwMDAwOjAxOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4
MDEyMDAwMDAtMHgwMTJmZmZmZiBwcmVmXQ0KcGNpIDAwMDA6MDA6MDAuMDogUENJIGJyaWRnZSB0
byBbYnVzIDAxLTA0XQ0KcGNpIDAwMDA6MDA6MDAuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHgx
MDAwLTB4MWZmZl0NCnBjaSAwMDAwOjAwOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDEx
MDAwMDAtMHgwMTFmZmZmZl0NCnBjaSAwMDAwOjAwOjAwLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IDB4MDEyMDAwMDAtMHgwMTJmZmZmZiBwcmVmXQ0KUENJOiBlbmFibGluZyBkZXZpY2UgMDAwMDow
MTowMC4wICgwMTQwIC0+IDAxNDMpDQpQQ0k6IGVuYWJsaW5nIGRldmljZSAwMDAwOjAyOjAxLjAg
KDAxNDAgLT4gMDE0MykNClBDSTogZW5hYmxpbmcgZGV2aWNlIDAwMDA6MDI6MDIuMCAoMDE0MCAt
PiAwMTQzKSAg74OfIDwtLVBDSWUgYnVzIGVudW1lcmF0aW9uICBpcyBmaW5pc2hlZC4NCi4uLg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1bZGV2aWNlIGRyaXZlciBpcyBsb2FkZWQgaGVyZV0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmUxMDAwZTogSW50ZWwoUikgUFJPLzEwMDAgTmV0
d29yayBEcml2ZXIgLSAyLjMuMi1rDQplMTAwMGU6IENvcHlyaWdodChjKSAxOTk5IC0gMjAxMyBJ
bnRlbCBDb3Jwb3JhdGlvbi4NCmUxMDAwZSAwMDAwOjAzOjAwLjA6IERpc2FibGluZyBBU1BNIEww
cyBMMQ0KUENJOiBlbmFibGluZyBkZXZpY2UgMDAwMDowMzowMC4wICgwMTQwIC0+IDAxNDIpDQpl
MTAwMGUgMDAwMDowMzowMC4wOiBJbnRlcnJ1cHQgVGhyb3R0bGluZyBSYXRlIChpbnRzL3NlYykg
c2V0IHRvIGR5bmFtaWMgY29uc2VydmF0aXZlIG1vZGUNCmUxMDAwZSAwMDAwOjAzOjAwLjAgZXRo
MTogcmVnaXN0ZXJlZCBQSEMgY2xvY2sNCmUxMDAwZSAwMDAwOjAzOjAwLjAgZXRoMTogKFBDSSBF
eHByZXNzOjIuNUdUL3M6V2lkdGggeDEpIDAwOjFiOjIxOjNhOjE4OjhiDQplMTAwMGUgMDAwMDow
MzowMC4wIGV0aDE6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbg0KZTEwMDBl
IDAwMDA6MDM6MDAuMCBldGgxOiBNQUM6IDMsIFBIWTogOCwgUEJBIE5vOiBFNDI2NDEtMDA1DQou
Li4NCmUxMDAwZTogZXRoMSBOSUMgTGluayBpcyBVcCAxMDAwIE1icHMgRnVsbCBEdXBsZXgsIEZs
b3cgQ29udHJvbDogUngvVHggIO+DnyBQQ0llIGRldmljZSBpcyByZWFkeQ0KSVB2NjogQUREUkNP
TkYoTkVUREVWX0NIQU5HRSk6IGV0aDE6IGxpbmsgYmVjb21lcyByZWFkeQ0KLi4uDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQouLi4NCklQLUNvbmZpZzogR290IERI
Q1AgYW5zd2VyIGZyb20gMTAuMTkyLjI0Mi4yNTIsIG15IGFkZHJlc3MgaXMgMTAuMTkyLjI0Mi45
NQ0KSVAtQ29uZmlnOiBDb21wbGV0ZToNCiAgICAgZGV2aWNlPWV0aDAsIGh3YWRkcj0wMDowNDo5
ZjowMjoxODpkZiwgaXBhZGRyPTEwLjE5Mi4yNDIuOTUsIG1hc2s9MjU1LjI1NS4yNTUuMCwgZ3c9
MTAuMTkyLjI0Mi4yNTQNCiAgICAgaG9zdD0xMC4xOTIuMjQyLjk1LCBkb21haW49YXAuZnJlZXNj
YWxlLm5ldCwgbmlzLWRvbWFpbj0obm9uZSkNCiAgICAgYm9vdHNlcnZlcj0wLjAuMC4wLCByb290
c2VydmVyPTEwLjE5Mi4yMjUuMjE2LCByb290cGF0aD0NCiAgICAgbmFtZXNlcnZlcjA9MTAuMTky
LjEzMC4yMDEsIG5hbWVzZXJ2ZXIxPTEwLjIxMS4wLjMsIG5hbWVzZXJ2ZXIyPTEwLjE5Ni41MS4y
MDANCkFMU0EgZGV2aWNlIGxpc3Q6DQogICMwOiB3bTg5NjItYXVkaW8NCiAgIzE6IGlteC1oZG1p
LXNvYw0KVkZTOiBNb3VudGVkIHJvb3QgKG5mcyBmaWxlc3lzdGVtKSBvbiBkZXZpY2UgMDoxMS4N
CmRldnRtcGZzOiBtb3VudGVkDQpGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAzMDBLICg4
MGMyOTAwMCAtIDgwYzc0MDAwKQ0KS2VybmVsIHBhbmljIC0gbm90IHN5bmNpbmc6IEF0dGVtcHRl
ZCB0byBraWxsIGluaXQhIGV4aXRjb2RlPTB4MDAwMDAwMGIgIO+DnyA8LS1TeXN0ZW0gcGFuaWMg
aGVyZSBzb21ldGltZXMuIDooDQoNCkNQVTI6IHN0b3BwaW5nDQpDUFU6IDIgUElEOiAwIENvbW06
IHN3YXBwZXIvMiBOb3QgdGFpbnRlZCAzLjEwLjktMTU5NjMtZ2UwZWVkNDItZGlydHkgIzEzMw0K
Wzw4MDAxNDc2ND5dICh1bndpbmRfYmFja3RyYWNlKzB4MC8weGY0KSBmcm9tIFs8ODAwMTE1OWM+
XSAoc2hvd19zdGFjaysweDEwLzB4MTQpDQpbPDgwMDExNTljPl0gKHNob3dfc3RhY2srMHgxMC8w
eDE0KSBmcm9tIFs8ODAwMTM5Njg+XSAoaGFuZGxlX0lQSSsweDEwOC8weDEzMCkNCls8ODAwMTM5
Njg+XSAoaGFuZGxlX0lQSSsweDEwOC8weDEzMCkgZnJvbSBbPDgwMDA4NWRjPl0gKGdpY19oYW5k
bGVfaXJxKzB4NTgvMHg1YykNCls8ODAwMDg1ZGM+XSAoZ2ljX2hhbmRsZV9pcnErMHg1OC8weDVj
KSBmcm9tIFs8ODAwMGRjMDA+XSAoX19pcnFfc3ZjKzB4NDAvMHg1MCkNCkV4Y2VwdGlvbiBzdGFj
aygweDljMDliZjUwIHRvIDB4OWMwOWJmOTgpDQpiZjQwOiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA5YzA5YmY5OCAwMDAwMDAwOCAzYTM0OTFkZSAwMDAwMDAwMg0KYmY2MDog
MzlkMmY5N2UgMDAwMDAwMDIgODEzNGYwODAgODBjODNmOTAgMDAwMDAwMDAgMDAwMDAwMDAgOWMw
OWEwMDAgODBjN2U0ZDgNCmJmODA6IDAwMDAwMDE3IDljMDliZjk4IDgwMDVhNGI0IDgwNDcwYzkw
IDYwMDAwMDEzIGZmZmZmZmZmDQpbPDgwMDBkYzAwPl0gKF9faXJxX3N2YysweDQwLzB4NTApIGZy
b20gWzw4MDQ3MGM5MD5dIChjcHVpZGxlX2VudGVyX3N0YXRlKzB4NTAvMHhlMCkNCls8ODA0NzBj
OTA+XSAoY3B1aWRsZV9lbnRlcl9zdGF0ZSsweDUwLzB4ZTApIGZyb20gWzw4MDQ3MGRkMD5dIChj
cHVpZGxlX2lkbGVfY2FsbCsweGIwLzB4MTQ4KQ0KWzw4MDQ3MGRkMD5dIChjcHVpZGxlX2lkbGVf
Y2FsbCsweGIwLzB4MTQ4KSBmcm9tIFs8ODAwMGViYmM+XSAoYXJjaF9jcHVfaWRsZSsweDEwLzB4
NTQpDQpbPDgwMDBlYmJjPl0gKGFyY2hfY3B1X2lkbGUrMHgxMC8weDU0KSBmcm9tIFs8ODAwNTlk
NDg+XSAoY3B1X3N0YXJ0dXBfZW50cnkrMHhmYy8weDE0MCkNCls8ODAwNTlkNDg+XSAoY3B1X3N0
YXJ0dXBfZW50cnkrMHhmYy8weDE0MCkgZnJvbSBbPDEwNjQ2Y2E0Pl0gKDB4MTA2NDZjYTQpDQpD
UFUzOiBzdG9wcGluZw0KQ1BVOiAzIFBJRDogMCBDb21tOiBzd2FwcGVyLzMgTm90IHRhaW50ZWQg
My4xMC45LTE1OTYzLWdlMGVlZDQyLWRpcnR5ICMxMzMNCls8ODAwMTQ3NjQ+XSAodW53aW5kX2Jh
Y2t0cmFjZSsweDAvMHhmNCkgZnJvbSBbPDgwMDExNTljPl0gKHNob3dfc3RhY2srMHgxMC8weDE0
KQ0KWzw4MDAxMTU5Yz5dIChzaG93X3N0YWNrKzB4MTAvMHgxNCkgZnJvbSBbPDgwMDEzOTY4Pl0g
KGhhbmRsZV9JUEkrMHgxMDgvMHgxMzApDQpbPDgwMDEzOTY4Pl0gKGhhbmRsZV9JUEkrMHgxMDgv
MHgxMzApIGZyb20gWzw4MDAwODVkYz5dIChnaWNfaGFuZGxlX2lycSsweDU4LzB4NWMpDQpbPDgw
MDA4NWRjPl0gKGdpY19oYW5kbGVfaXJxKzB4NTgvMHg1YykgZnJvbSBbPDgwMDBkYzAwPl0gKF9f
aXJxX3N2YysweDQwLzB4NTApDQpFeGNlcHRpb24gc3RhY2soMHg5YzA5ZGY1MCB0byAweDljMDlk
Zjk4KQ0KZGY0MDogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOWMwOWRmOTgg
MDAwMDAwMDggM2EzNDkxZGUgMDAwMDAwMDINCmRmNjA6IDM5Y2RmYWQ5IDAwMDAwMDAyIDgxMzU3
MDgwIDgwYzgzZjkwIDAwMDAwMDAwIDAwMDAwMDAwIDljMDljMDAwIDgwYzdlNGQ4DQpkZjgwOiAw
MDAwMDAxNyA5YzA5ZGY5OCA4MDA1YTRiNCA4MDQ3MGM5MCA2MDAwMDExMyBmZmZmZmZmZg0KWzw4
MDAwZGMwMD5dIChfX2lycV9zdmMrMHg0MC8weDUwKSBmcm9tIFs8ODA0NzBjOTA+XSAoY3B1aWRs
ZV9lbnRlcl9zdGF0ZSsweDUwLzB4ZTApDQpbPDgwNDcwYzkwPl0gKGNwdWlkbGVfZW50ZXJfc3Rh
dGUrMHg1MC8weGUwKSBmcm9tIFs8ODA0NzBkZDA+XSAoY3B1aWRsZV9pZGxlX2NhbGwrMHhiMC8w
eDE0OCkNCls8ODA0NzBkZDA+XSAoY3B1aWRsZV9pZGxlX2NhbGwrMHhiMC8weDE0OCkgZnJvbSBb
PDgwMDBlYmJjPl0gKGFyY2hfY3B1X2lkbGUrMHgxMC8weDU0KQ0KWzw4MDAwZWJiYz5dIChhcmNo
X2NwdV9pZGxlKzB4MTAvMHg1NCkgZnJvbSBbPDgwMDU5ZDQ4Pl0gKGNwdV9zdGFydHVwX2VudHJ5
KzB4ZmMvMHgxNDApDQpbPDgwMDU5ZDQ4Pl0gKGNwdV9zdGFydHVwX2VudHJ5KzB4ZmMvMHgxNDAp
IGZyb20gWzwxMDY0NmNhND5dICgweDEwNjQ2Y2E0KQ0KQ1BVMTogc3RvcHBpbmcNCkNQVTogMSBQ
SUQ6IDAgQ29tbTogc3dhcHBlci8xIE5vdCB0YWludGVkIDMuMTAuOS0xNTk2My1nZTBlZWQ0Mi1k
aXJ0eSAjMTMzDQpbPDgwMDE0NzY0Pl0gKHVud2luZF9iYWNrdHJhY2UrMHgwLzB4ZjQpIGZyb20g
Wzw4MDAxMTU5Yz5dIChzaG93X3N0YWNrKzB4MTAvMHgxNCkNCls8ODAwMTE1OWM+XSAoc2hvd19z
dGFjaysweDEwLzB4MTQpIGZyb20gWzw4MDAxMzk2OD5dIChoYW5kbGVfSVBJKzB4MTA4LzB4MTMw
KQ0KWzw4MDAxMzk2OD5dIChoYW5kbGVfSVBJKzB4MTA4LzB4MTMwKSBmcm9tIFs8ODAwMDg1ZGM+
XSAoZ2ljX2hhbmRsZV9pcnErMHg1OC8weDVjKQ0KWzw4MDAwODVkYz5dIChnaWNfaGFuZGxlX2ly
cSsweDU4LzB4NWMpIGZyb20gWzw4MDAwZGMwMD5dIChfX2lycV9zdmMrMHg0MC8weDUwKQ0KRXhj
ZXB0aW9uIHN0YWNrKDB4OWMwOTlmNTAgdG8gMHg5YzA5OWY5OCkNCjlmNDA6ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDljMDk5Zjk4IDAwMDAwMDA4IDNhMzQ5MWRlIDAwMDAw
MDAyDQo5ZjYwOiAzOWNkZjgzZSAwMDAwMDAwMiA4MTM0NzA4MCA4MGM4M2Y5MCAwMDAwMDAwMCAw
MDAwMDAwMCA5YzA5ODAwMCA4MGM3ZTRkOA0KOWY4MDogMDAwMDAwMTcgOWMwOTlmOTggODAwNWE0
YjQgODA0NzBjOTAgNjAwMDAwMTMgZmZmZmZmZmYNCls8ODAwMGRjMDA+XSAoX19pcnFfc3ZjKzB4
NDAvMHg1MCkgZnJvbSBbPDgwNDcwYzkwPl0gKGNwdWlkbGVfZW50ZXJfc3RhdGUrMHg1MC8weGUw
KQ0KWzw4MDQ3MGM5MD5dIChjcHVpZGxlX2VudGVyX3N0YXRlKzB4NTAvMHhlMCkgZnJvbSBbPDgw
NDcwZGQwPl0gKGNwdWlkbGVfaWRsZV9jYWxsKzB4YjAvMHgxNDgpDQpbPDgwNDcwZGQwPl0gKGNw
dWlkbGVfaWRsZV9jYWxsKzB4YjAvMHgxNDgpIGZyb20gWzw4MDAwZWJiYz5dIChhcmNoX2NwdV9p
ZGxlKzB4MTAvMHg1NCkNCls8ODAwMGViYmM+XSAoYXJjaF9jcHVfaWRsZSsweDEwLzB4NTQpIGZy
b20gWzw4MDA1OWQ0OD5dIChjcHVfc3RhcnR1cF9lbnRyeSsweGZjLzB4MTQwKQ0KWzw4MDA1OWQ0
OD5dIChjcHVfc3RhcnR1cF9lbnRyeSsweGZjLzB4MTQwKSBmcm9tIFs8MTA2NDZjYTQ+XSAoMHgx
MDY0NmNhNCkNCg0KQW55IGlkZWFzPyANClRoYW5rcyBpbiBhZHZhbmNlLg0KDQpCZXN0IFJlZ2Fy
ZHMNClJpY2hhcmQgWmh1DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1h
cmVrIFZhc3V0IFttYWlsdG86bWFyZXhAZGVueC5kZV0gDQpTZW50OiBUaHVyc2RheSwgT2N0b2Jl
ciAxMCwgMjAxMyA2OjI1IFBNDQpUbzogWmh1IFJpY2hhcmQtUjY1MDM3DQpDYzogbGludXgtYXJt
LWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBCam9ybiBIZWxnYWFzOyBTaGF3biBHdW87IGxp
bnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmc7IHRoYXJ2ZXlAZ2F0ZXdvcmtzLmNvbTsgRnJhbmsgTGk7
IFNlYW4gQ3Jvc3M7IFNhc2NoYSBIYXVlcg0KU3ViamVjdDogUmU6IFtQQVRDSCB2NyAwLzJdIEFk
ZCBQQ0llIHN1cHBvcnQgZm9yIGkuTVg2cQ0KDQpIaSBSaWNoYXJkLA0KDQo+IEhpIE1hcmVrOg0K
PiBUaGFua3MgZm9yIHlvdXIga2luZGx5IHRlc3RzLg0KPiANCj4gUmVnYXJkaW5nIHRvIG15IGV4
cGVyaWVuY2Ugb24gMy4wLjM1IGtlcm5lbCwgYmVzaWRlcyB0aGUgcHJvZ3JhbW1pbmcgDQo+IHRo
ZQ0KPiBSZFdyMCB2cy4gUmRXcjEgbW9kZSBpbnRvIHRoZSBpQVRVLiBUaGUgSU5UeCBzaG91bGQg
YmUgY29uZmlndXJlZCANCj4gcHJvcGVybHksIGZvciBleGFtcGxlLCBsaWtlIHRoZSBmb2xsb3dp
bmcgb25lOg0KPiANCj4gc3RhdGljIGludCBfX2luaXQgaW14X3BjaWVfbWFwX2lycShzdHJ1Y3Qg
cGNpX2RldiAqZGV2LCB1OCBzbG90LCB1OCANCj4gcGluKSB7DQo+ICAgICAgICBzd2l0Y2ggKHBp
bikgew0KPiAgICAgICAgY2FzZSAxOiByZXR1cm4gTVhDX0lOVF9QQ0lFXzM7DQo+ICAgICAgICBj
YXNlIDI6IHJldHVybiBNWENfSU5UX1BDSUVfMjsNCj4gICAgICAgIGNhc2UgMzogcmV0dXJuIE1Y
Q19JTlRfUENJRV8xOw0KPiAgICAgICAgY2FzZSA0OiByZXR1cm4gTVhDX0lOVF9QQ0lFXzA7DQo+
ICAgICAgICBkZWZhdWx0OiByZXR1cm4gLTE7DQo+ICAgICAgICB9DQo+IH0NCj4gDQo+IHN0YXRp
YyBzdHJ1Y3QgaHdfcGNpIGlteF9wY2kgX19pbml0ZGF0YSA9IHsNCj4gICAgICAgICAubnJfY29u
dHJvbGxlcnMgPSAxLA0KPiAgICAgICAgIC5zd2l6emxlICAgICAgICA9IHBjaV9zdGRfc3dpenps
ZSwNCj4gICAgICAgICAuc2V0dXAgICAgICAgICAgPSBpbXhfcGNpZV9zZXR1cCwNCj4gICAgICAg
ICAuc2NhbiAgICAgICAgICAgPSBpbXhfcGNpZV9zY2FuX2J1cywNCj4gICAgICAgICAubWFwX2ly
cSAgICAgICAgPSBpbXhfcGNpZV9tYXBfaXJxLA0KPiB9Ow0KPiBCZXN0IFJlZ2FyZHMNCj4gUmlj
aGFyZCBaaHUNCg0KVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dCwgSSdsbCBjaGVjayB0aGlz
LiBBcmUgdGhlcmUgcGxhbnMgdG8gaW1wbGVtZW50IHRoZSBQQ0llIHN3aXRjaCBzdXBwb3J0IGFs
cmVhZHkgc28gSSB3b24ndCBzdGVwIGludG8gc29tZW9uZSBlbHNlJ3Mgd29yaz8NCg0KSW4gdGhl
IG1lYW50aW1lLCB0aGlzIGlzIHdoYXQgSSBzZWUgdXBvbiBwcm9iZSB3aXRoIFY2IG9mIHRoZSBw
YXRjaGVzOg0KDQpMaW51eCB2ZXJzaW9uIDMuMTIuMC1yYzItbmV4dC0yMDEzMDkyNysNClsuLi5d
DQppbXg2cS1wY2llIDFmZmMwMDAucGNpZTogcGh5IGxpbmsgbmV2ZXIgY2FtZSB1cCBQQ0kgaG9z
dCBicmlkZ2UgdG8gYnVzIDAwMDA6MDAgcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJj
ZSBbaW8gIDB4MTAwMC0weDEwMDAwXSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNl
IFttZW0gMHgwMTAwMDAwMC0weDAxZWZmZmZmXSBwY2lfYnVzIDAwMDA6MDA6IE5vIGJ1c24gcmVz
b3VyY2UgZm91bmQgZm9yIHJvb3QgYnVzLCB3aWxsIHVzZSBbYnVzIDAwLWZmXQ0KUENJOiBidXMw
OiBGYXN0IGJhY2sgdG8gYmFjayB0cmFuc2ZlcnMgZGlzYWJsZWQNClBDSTogYnVzMTogRmFzdCBi
YWNrIHRvIGJhY2sgdHJhbnNmZXJzIGVuYWJsZWQNClBDSTogRGV2aWNlIDAwMDA6MDA6MDAuMCBu
b3QgYXZhaWxhYmxlIGJlY2F1c2Ugb2YgcmVzb3VyY2UgY29sbGlzaW9ucw0KcGNpZXBvcnQ6IHBy
b2JlIG9mIDAwMDA6MDA6MDAuMCBmYWlsZWQgd2l0aCBlcnJvciAtMjIgcGNpIDAwMDA6MDA6MDAu
MDogQkFSIDA6IGFzc2lnbmVkIFttZW0gMHgwMTAwMDAwMC0weDAxMGZmZmZmXSBwY2kgMDAwMDow
MDowMC4wOiBCQVIgNjogYXNzaWduZWQgW21lbSAweDAxMTAwMDAwLTB4MDExMGZmZmYgcHJlZl0g
cGNpIDAwMDA6MDA6MDAuMDogUENJIGJyaWRnZSB0byBbYnVzIDAxXSBwY2kgMDAwMDowMDowMC4w
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMDFdDQoNCklzIHRoaXMgbGluZSBub3JtYWwvZXhwZWN0ZWQ/
IElzIHRoaXMgcmVsYXRlZCB0byB0aGUgUENJZSBzd2l0Y2ggSSBoYXZlIHRoZXJlPw0KcGNpZXBv
cnQ6IHByb2JlIG9mIDAwMDA6MDA6MDAuMCBmYWlsZWQgd2l0aCBlcnJvciAtMjINCg0KVGhhbmsg
eW91IGZvciB5b3VyIGhlbHAhDQoNCkJlc3QgcmVnYXJkcywNCk1hcmVrIFZhc3V0DQoNCg==

[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

Re: [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

[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

Re: [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

[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

Re: [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.

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

Re: [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

[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

Re: [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

[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

Re: [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

[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!

Re: [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

[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

Re: [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

[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

Re: [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 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 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 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

Re: [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 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

Re: [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

[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

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

[Zhu Richard-R65037]

[-- Attachment #1: Type: text/plain, Size: 9502 bytes --]

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@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@lists.infradead.org; Shawn Guo; linux-pci@vger.kernel.org; tharvey@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@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: 0001-pcie-correct-the-irq-map-when-pcie-switch-is-used.patch --]
[-- Type: application/octet-stream, Size: 1068 bytes --]

From 4791403950050d79de16c7efcbda5b4356de3c8f Mon Sep 17 00:00:00 2001
From: Richard Zhu <r65037@freescale.com>
Date: Tue, 8 Oct 2013 10:20:46 +0800
Subject: [PATCH] pcie: correct the irq map when pcie switch is used

correct the irq map when pcie switch is used, otherwise
the pcie ep populatd on the switch wouldn't get the
correct INTx.

Signed-off-by: Richard Zhu <r65037@freescale.com>
---
 drivers/pci/host/pcie-designware.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 2b5ce80..3bfd3c8 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -464,7 +464,13 @@ int dw_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
 	struct pcie_port *pp = sys_to_pcie(dev->bus->sysdata);
 
-	return pp->irq;
+	switch (pin) {
+	case 1: return pp->irq;
+	case 2: return pp->irq - 1;
+	case 3: return pp->irq - 2;
+	case 4: return pp->irq - 3;
+	default: return -1;
+	}
 }
 
 static struct hw_pci dw_pci = {
-- 
1.7.1

[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>

Re: [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 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

Re: [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 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(-)

Re: [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

[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

Re: [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 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

Re: [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

[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

Re: [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

[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

Re: [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

[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

RE: [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@gateworks.com] 
Sent: Friday, October 11, 2013 11:25 PM
To: Marek Vasut
Cc: Yinghai Lu; Bjorn Helgaas; Zhu Richard-R65037; linux-arm-kernel@lists.infradead.org; Shawn Guo; linux-pci@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

[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

Re: [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 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

Re: [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 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

Re: [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

[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
> 

Re: [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

[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!

Re: [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

[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

Re: [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.

Best regards,
Marek Vasut

Re: [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

[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 .

Re: [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

[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

Re: [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

[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