* [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-arm-kernel
Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
NOTE: I'm sure this will start some discussion. There are quite a few patches
that are more of a hacks. Shawn, I didn't ignore your remark about the
clock patches, I will test it ASAP, I just want to have these fixes in
the public so others can comment/test.
Marek Vasut (6):
PCI: imx6: Make reset-gpio optional
PCI: imx6: Fix the clock for PCIe
ARM: dts: imx6qdl: Fix the clock for PCIe
PCI: imx6: Probe the PCIe in fs_initcall()
PCI: imx6: Force Gen1 operation
PCI: designware: Fix DT resource retrieval
.../devicetree/bindings/pci/designware-pcie.txt | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
drivers/pci/host/pci-imx6.c | 63 ++++++++++++++++------
drivers/pci/host/pcie-designware.c | 17 +++---
4 files changed, 55 insertions(+), 31 deletions(-)
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
--
1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Marek Vasut, Bjorn Helgaas, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Shawn Guo, Siva Reddy Kallam,
Srikanth T Shivanand, Tim Harvey, Troy Kisky, Yinghai Lu
Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
NOTE: I'm sure this will start some discussion. There are quite a few patches
that are more of a hacks. Shawn, I didn't ignore your remark about the
clock patches, I will test it ASAP, I just want to have these fixes in
the public so others can comment/test.
Marek Vasut (6):
PCI: imx6: Make reset-gpio optional
PCI: imx6: Fix the clock for PCIe
ARM: dts: imx6qdl: Fix the clock for PCIe
PCI: imx6: Probe the PCIe in fs_initcall()
PCI: imx6: Force Gen1 operation
PCI: designware: Fix DT resource retrieval
.../devicetree/bindings/pci/designware-pcie.txt | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
drivers/pci/host/pci-imx6.c | 63 ++++++++++++++++------
drivers/pci/host/pcie-designware.c | 17 +++---
4 files changed, 55 insertions(+), 31 deletions(-)
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
--
1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 1/6] PCI: imx6: Make reset-gpio optional
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-15 16:06 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-arm-kernel
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: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
.../devicetree/bindings/pci/designware-pcie.txt | 2 +-
drivers/pci/host/pci-imx6.c | 29 +++++++++++-----------
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d5d26d4..b7a2279 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -19,9 +19,9 @@ Required properties:
to define the mapping of the PCIe interface to interrupt
numbers.
- num-lanes: number of lanes to use
-- reset-gpio: gpio pin number of power good signal
Optional properties for fsl,imx6q-pcie
+- reset-gpio: gpio pin number of power good signal
- 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
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 5afa922..728989a 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;
}
@@ -446,17 +449,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
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 1/6] PCI: imx6: Make reset-gpio optional
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Marek Vasut, Bjorn Helgaas, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Shawn Guo, Siva Reddy Kallam,
Srikanth T Shivanand, Tim Harvey, Troy Kisky, Yinghai Lu
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: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
.../devicetree/bindings/pci/designware-pcie.txt | 2 +-
drivers/pci/host/pci-imx6.c | 29 +++++++++++-----------
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d5d26d4..b7a2279 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -19,9 +19,9 @@ Required properties:
to define the mapping of the PCIe interface to interrupt
numbers.
- num-lanes: number of lanes to use
-- reset-gpio: gpio pin number of power good signal
Optional properties for fsl,imx6q-pcie
+- reset-gpio: gpio pin number of power good signal
- 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
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 5afa922..728989a 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;
}
@@ -446,17 +449,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
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 2/6] PCI: imx6: Fix the clock for PCIe
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-15 16:06 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-arm-kernel
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: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pci-imx6.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 728989a..94e4d0f 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);
@@ -497,6 +506,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
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 2/6] PCI: imx6: Fix the clock for PCIe
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Marek Vasut, Bjorn Helgaas, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Shawn Guo, Siva Reddy Kallam,
Srikanth T Shivanand, Tim Harvey, Troy Kisky, Yinghai Lu
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: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pci-imx6.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 728989a..94e4d0f 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);
@@ -497,6 +506,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
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 3/6] ARM: dts: imx6qdl: Fix the clock for PCIe
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-15 16:06 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-arm-kernel
The clk #205 are lvds_sel, not lvds_gate , so fix this. Moreover,
the PCIe needs lvds_gate for successful operation, so supply these
clock to the PCIe driver.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
arch/arm/boot/dts/imx6qdl.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6e1113e..4497f3e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -127,8 +127,8 @@
0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
num-lanes = <1>;
interrupts = <0 123 0x04>;
- clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>;
- clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
+ clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>, <&clks 204>;
+ clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_sel", "pcie_axi", "lvds_gate";
status = "disabled";
};
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 3/6] ARM: dts: imx6qdl: Fix the clock for PCIe
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Marek Vasut, Bjorn Helgaas, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Shawn Guo, Siva Reddy Kallam,
Srikanth T Shivanand, Tim Harvey, Troy Kisky, Yinghai Lu
The clk #205 are lvds_sel, not lvds_gate , so fix this. Moreover,
the PCIe needs lvds_gate for successful operation, so supply these
clock to the PCIe driver.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
arch/arm/boot/dts/imx6qdl.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6e1113e..4497f3e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -127,8 +127,8 @@
0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; /* non-prefetchable memory */
num-lanes = <1>;
interrupts = <0 123 0x04>;
- clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>;
- clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi";
+ clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>, <&clks 204>;
+ clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_sel", "pcie_axi", "lvds_gate";
status = "disabled";
};
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 4/6] PCI: imx6: Probe the PCIe in fs_initcall()
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-15 16:06 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-arm-kernel
Probe the PCIe driver in fs_initcall() instead of module_init()
to assure that pci_assign_unassigned_resources(); will be called
early. This function is called in dw_pcie_host_init(), which is
in turn called from imx6_add_pcie_port(), which is called from
imx6_pcie_probe() . If this is not called early, we will hit
resource collisions since pcieport driver is then probed way too
late.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pci-imx6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 94e4d0f..ca8c5de 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -586,7 +586,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");
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 4/6] PCI: imx6: Probe the PCIe in fs_initcall()
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Marek Vasut, Bjorn Helgaas, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Shawn Guo, Siva Reddy Kallam,
Srikanth T Shivanand, Tim Harvey, Troy Kisky, Yinghai Lu
Probe the PCIe driver in fs_initcall() instead of module_init()
to assure that pci_assign_unassigned_resources(); will be called
early. This function is called in dw_pcie_host_init(), which is
in turn called from imx6_add_pcie_port(), which is called from
imx6_pcie_probe() . If this is not called early, we will hit
resource collisions since pcieport driver is then probed way too
late.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pci-imx6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 94e4d0f..ca8c5de 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -586,7 +586,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");
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-15 16:06 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-arm-kernel
Without forcing the PCIe core into Gen1 operation, the PCIe switch
attached directly to the PCIe port is not recognised at all. The
PCIe switch is Gen2 capable to make this issue even more puzzling.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index ca8c5de..8402e9a 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
{
int count = 0;
struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+ uint32_t tmp;
imx6_pcie_assert_core_reset(pp);
@@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
dw_pcie_setup_rc(pp);
+ /*
+ * FIXME:
+ * Force Gen1 operation. In case the IP block is in Gen2 operation
+ * mode, it does not detect the PCIe switch at all.
+ */
+ tmp = readl(pp->dbi_base + 0x7c);
+ tmp &= ~0xf;
+ tmp |= 0x1;
+ writel(tmp, 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",
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Marek Vasut, Bjorn Helgaas, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Shawn Guo, Siva Reddy Kallam,
Srikanth T Shivanand, Tim Harvey, Troy Kisky, Yinghai Lu
Without forcing the PCIe core into Gen1 operation, the PCIe switch
attached directly to the PCIe port is not recognised at all. The
PCIe switch is Gen2 capable to make this issue even more puzzling.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index ca8c5de..8402e9a 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
{
int count = 0;
struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+ uint32_t tmp;
imx6_pcie_assert_core_reset(pp);
@@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
dw_pcie_setup_rc(pp);
+ /*
+ * FIXME:
+ * Force Gen1 operation. In case the IP block is in Gen2 operation
+ * mode, it does not detect the PCIe switch at all.
+ */
+ tmp = readl(pp->dbi_base + 0x7c);
+ tmp &= ~0xf;
+ tmp |= 0x1;
+ writel(tmp, 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",
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 6/6] PCI: designware: Fix DT resource retrieval
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-15 16:06 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-arm-kernel
The resource retrieval from the DT was not done right. This resulted
in bogus values in the IO/MEM window configuration. I re-used the code
implementation from pci-tegra.c to do the resource retrieval correctly.
This in turn resulted in very strange behavior on two different kinds
of setup:
Setup #1: ,-------> Intel i210 (igb driver)
i.MX6 root port -----> PCIe switch
`-------> Empty slot
Setup #2: ,-------> Marvell Yukon (sky2 driver)
i.MX6 root port -----> PCIe switch
`-------> Empty slot
Both setups expressed the same behavior. The system booted and the
ethernet controllers were properly detected. After the controllers
were configured and just after they reported "Ethernet Link Up", the
entire system froze. It is now clear this happened because the resources
were incorrectly configured, which in turn means the iATU was also not
configured correctly.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pcie-designware.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 5d183ae..97c5951 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
struct device_node *np = pp->dev->of_node;
struct of_pci_range range;
struct of_pci_range_parser parser;
+ struct resource res;
u32 val;
struct irq_domain *irq_domain;
@@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
/* Get the I/O and memory ranges from DT */
for_each_of_pci_range(&parser, &range) {
- unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
+ of_pci_range_to_resource(&range, np, &res);
+ unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
if (restype == IORESOURCE_IO) {
- of_pci_range_to_resource(&range, np, &pp->io);
+ memcpy(&pp->io, &res, sizeof(res));
pp->io.name = "I/O";
- pp->io.start = max_t(resource_size_t,
- PCIBIOS_MIN_IO,
- range.pci_addr + global_io_offset);
- pp->io.end = min_t(resource_size_t,
- IO_SPACE_LIMIT,
- range.pci_addr + range.size
- + global_io_offset);
pp->config.io_size = resource_size(&pp->io);
pp->config.io_bus_addr = range.pci_addr;
}
if (restype == IORESOURCE_MEM) {
- of_pci_range_to_resource(&range, np, &pp->mem);
+ memcpy(&pp->mem, &res, sizeof(res));
pp->mem.name = "MEM";
pp->config.mem_size = resource_size(&pp->mem);
pp->config.mem_bus_addr = range.pci_addr;
}
if (restype == 0) {
- of_pci_range_to_resource(&range, np, &pp->cfg);
+ memcpy(&pp->cfg, &res, sizeof(res));
pp->config.cfg0_size = resource_size(&pp->cfg)/2;
pp->config.cfg1_size = resource_size(&pp->cfg)/2;
}
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 6/6] PCI: designware: Fix DT resource retrieval
@ 2013-10-15 16:06 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:06 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Marek Vasut, Bjorn Helgaas, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Shawn Guo, Siva Reddy Kallam,
Srikanth T Shivanand, Tim Harvey, Troy Kisky, Yinghai Lu
The resource retrieval from the DT was not done right. This resulted
in bogus values in the IO/MEM window configuration. I re-used the code
implementation from pci-tegra.c to do the resource retrieval correctly.
This in turn resulted in very strange behavior on two different kinds
of setup:
Setup #1: ,-------> Intel i210 (igb driver)
i.MX6 root port -----> PCIe switch
`-------> Empty slot
Setup #2: ,-------> Marvell Yukon (sky2 driver)
i.MX6 root port -----> PCIe switch
`-------> Empty slot
Both setups expressed the same behavior. The system booted and the
ethernet controllers were properly detected. After the controllers
were configured and just after they reported "Ethernet Link Up", the
entire system froze. It is now clear this happened because the resources
were incorrectly configured, which in turn means the iATU was also not
configured correctly.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Frank Li <lznuaa@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/host/pcie-designware.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 5d183ae..97c5951 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
struct device_node *np = pp->dev->of_node;
struct of_pci_range range;
struct of_pci_range_parser parser;
+ struct resource res;
u32 val;
struct irq_domain *irq_domain;
@@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
/* Get the I/O and memory ranges from DT */
for_each_of_pci_range(&parser, &range) {
- unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
+ of_pci_range_to_resource(&range, np, &res);
+ unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
if (restype == IORESOURCE_IO) {
- of_pci_range_to_resource(&range, np, &pp->io);
+ memcpy(&pp->io, &res, sizeof(res));
pp->io.name = "I/O";
- pp->io.start = max_t(resource_size_t,
- PCIBIOS_MIN_IO,
- range.pci_addr + global_io_offset);
- pp->io.end = min_t(resource_size_t,
- IO_SPACE_LIMIT,
- range.pci_addr + range.size
- + global_io_offset);
pp->config.io_size = resource_size(&pp->io);
pp->config.io_bus_addr = range.pci_addr;
}
if (restype == IORESOURCE_MEM) {
- of_pci_range_to_resource(&range, np, &pp->mem);
+ memcpy(&pp->mem, &res, sizeof(res));
pp->mem.name = "MEM";
pp->config.mem_size = resource_size(&pp->mem);
pp->config.mem_bus_addr = range.pci_addr;
}
if (restype == 0) {
- of_pci_range_to_resource(&range, np, &pp->cfg);
+ memcpy(&pp->cfg, &res, sizeof(res));
pp->config.cfg0_size = resource_size(&pp->cfg)/2;
pp->config.cfg1_size = resource_size(&pp->cfg)/2;
}
--
1.8.4.rc3
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-15 16:34 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:34 UTC (permalink / raw
To: linux-arm-kernel
Hi Shawn,
> Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
>
> NOTE: I'm sure this will start some discussion. There are quite a few
> patches that are more of a hacks. Shawn, I didn't ignore your remark about
> the clock patches, I will test it ASAP, I just want to have these fixes in
> the public so others can comment/test.
0002 and 0003 are NOT needed on my setup, Shawn. You were right, so please
ignore these two.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-15 16:34 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-15 16:34 UTC (permalink / raw
To: linux-pci
Cc: linux-arm-kernel, Bjorn Helgaas, Frank Li, Jingoo Han,
Mohit KUMAR, Pratyush Anand, Richard Zhu, Sascha Hauer,
Sean Cross, Shawn Guo, Siva Reddy Kallam, Srikanth T Shivanand,
Tim Harvey, Troy Kisky, Yinghai Lu
Hi Shawn,
> Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
>
> NOTE: I'm sure this will start some discussion. There are quite a few
> patches that are more of a hacks. Shawn, I didn't ignore your remark about
> the clock patches, I will test it ASAP, I just want to have these fixes in
> the public so others can comment/test.
0002 and 0003 are NOT needed on my setup, Shawn. You were right, so please
ignore these two.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-16 0:03 ` Jingoo Han
-1 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-16 0:03 UTC (permalink / raw
To: linux-arm-kernel
> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Wednesday, October 16, 2013 1:07 AM
> To: linux-pci at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org; Marek Vasut; Bjorn Helgaas; Frank Li; Jingoo Han; Mohit
> KUMAR; Pratyush Anand; Richard Zhu; Sascha Hauer; Sean Cross; Shawn Guo; Siva Reddy Kallam; Srikanth T
> Shivanand; Tim Harvey; Troy Kisky; Yinghai Lu
> Subject: [PATCH 0/6] PCI: imx6: Random fixes
>
> Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
>
> NOTE: I'm sure this will start some discussion. There are quite a few patches
> that are more of a hacks. Shawn, I didn't ignore your remark about the
> clock patches, I will test it ASAP, I just want to have these fixes in
> the public so others can comment/test.
>
> Marek Vasut (6):
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Fix the clock for PCIe
> ARM: dts: imx6qdl: Fix the clock for PCIe
> PCI: imx6: Probe the PCIe in fs_initcall()
> PCI: imx6: Force Gen1 operation
> PCI: designware: Fix DT resource retrieval
>
> .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> drivers/pci/host/pci-imx6.c | 63 ++++++++++++++++------
> drivers/pci/host/pcie-designware.c | 17 +++---
> 4 files changed, 55 insertions(+), 31 deletions(-)
Hi Marek,
Your patchset modifies Synopsys Designware part. (pcie-designware.c)
Thus, it would be better to share this patchset with Kishon Vijay Abraham I.
He is also developing OMAP PCIe driver using 'pcie-designware.c'.
Best regards,
Jingoo Han
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
>
> --
> 1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-16 0:03 ` Jingoo Han
0 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-16 0:03 UTC (permalink / raw
To: 'Marek Vasut', 'Kishon Vijay Abraham I'
Cc: linux-pci, linux-arm-kernel, 'Bjorn Helgaas',
'Frank Li', 'Mohit KUMAR',
'Pratyush Anand', 'Richard Zhu',
'Sascha Hauer', 'Sean Cross', 'Shawn Guo',
'Siva Reddy Kallam', 'Srikanth T Shivanand',
'Tim Harvey', 'Troy Kisky', 'Yinghai Lu',
'Jingoo Han'
> -----Original Message-----
> From: Marek Vasut [mailto:marex@denx.de]
> Sent: Wednesday, October 16, 2013 1:07 AM
> To: linux-pci@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org; Marek Vasut; Bjorn Helgaas; Frank Li; Jingoo Han; Mohit
> KUMAR; Pratyush Anand; Richard Zhu; Sascha Hauer; Sean Cross; Shawn Guo; Siva Reddy Kallam; Srikanth T
> Shivanand; Tim Harvey; Troy Kisky; Yinghai Lu
> Subject: [PATCH 0/6] PCI: imx6: Random fixes
>
> Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
>
> NOTE: I'm sure this will start some discussion. There are quite a few patches
> that are more of a hacks. Shawn, I didn't ignore your remark about the
> clock patches, I will test it ASAP, I just want to have these fixes in
> the public so others can comment/test.
>
> Marek Vasut (6):
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Fix the clock for PCIe
> ARM: dts: imx6qdl: Fix the clock for PCIe
> PCI: imx6: Probe the PCIe in fs_initcall()
> PCI: imx6: Force Gen1 operation
> PCI: designware: Fix DT resource retrieval
>
> .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> drivers/pci/host/pci-imx6.c | 63 ++++++++++++++++------
> drivers/pci/host/pcie-designware.c | 17 +++---
> 4 files changed, 55 insertions(+), 31 deletions(-)
Hi Marek,
Your patchset modifies Synopsys Designware part. (pcie-designware.c)
Thus, it would be better to share this patchset with Kishon Vijay Abraham I.
He is also developing OMAP PCIe driver using 'pcie-designware.c'.
Best regards,
Jingoo Han
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
>
> --
> 1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-16 0:03 ` Jingoo Han
@ 2013-10-16 0:08 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-16 0:08 UTC (permalink / raw
To: linux-arm-kernel
Hello Han,
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex at denx.de]
> > Sent: Wednesday, October 16, 2013 1:07 AM
> > To: linux-pci at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org; Marek Vasut; Bjorn Helgaas;
> > Frank Li; Jingoo Han; Mohit KUMAR; Pratyush Anand; Richard Zhu; Sascha
> > Hauer; Sean Cross; Shawn Guo; Siva Reddy Kallam; Srikanth T Shivanand;
> > Tim Harvey; Troy Kisky; Yinghai Lu
> > Subject: [PATCH 0/6] PCI: imx6: Random fixes
> >
> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
> > expected.
> >
> > NOTE: I'm sure this will start some discussion. There are quite a few
> > patches
> >
> > that are more of a hacks. Shawn, I didn't ignore your remark about
> > the clock patches, I will test it ASAP, I just want to have these
> > fixes in the public so others can comment/test.
> >
> > Marek Vasut (6):
> > PCI: imx6: Make reset-gpio optional
> > PCI: imx6: Fix the clock for PCIe
> > ARM: dts: imx6qdl: Fix the clock for PCIe
> > PCI: imx6: Probe the PCIe in fs_initcall()
> > PCI: imx6: Force Gen1 operation
> > PCI: designware: Fix DT resource retrieval
> >
> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> > drivers/pci/host/pci-imx6.c | 63
> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
> > | 17 +++---
> > 4 files changed, 55 insertions(+), 31 deletions(-)
>
> Hi Marek,
>
> Your patchset modifies Synopsys Designware part. (pcie-designware.c)
> Thus, it would be better to share this patchset with Kishon Vijay Abraham
> I. He is also developing OMAP PCIe driver using 'pcie-designware.c'.
Putting him on CC, thanks
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-16 0:08 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-16 0:08 UTC (permalink / raw
To: Jingoo Han
Cc: 'Kishon Vijay Abraham I', linux-pci, linux-arm-kernel,
'Bjorn Helgaas', 'Frank Li',
'Mohit KUMAR', 'Pratyush Anand',
'Richard Zhu', 'Sascha Hauer',
'Sean Cross', 'Shawn Guo',
'Siva Reddy Kallam', 'Srikanth T Shivanand',
'Tim Harvey', 'Troy Kisky', 'Yinghai Lu',
'Kishon Vijay Abraham I'
Hello Han,
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex@denx.de]
> > Sent: Wednesday, October 16, 2013 1:07 AM
> > To: linux-pci@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org; Marek Vasut; Bjorn Helgaas;
> > Frank Li; Jingoo Han; Mohit KUMAR; Pratyush Anand; Richard Zhu; Sascha
> > Hauer; Sean Cross; Shawn Guo; Siva Reddy Kallam; Srikanth T Shivanand;
> > Tim Harvey; Troy Kisky; Yinghai Lu
> > Subject: [PATCH 0/6] PCI: imx6: Random fixes
> >
> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
> > expected.
> >
> > NOTE: I'm sure this will start some discussion. There are quite a few
> > patches
> >
> > that are more of a hacks. Shawn, I didn't ignore your remark about
> > the clock patches, I will test it ASAP, I just want to have these
> > fixes in the public so others can comment/test.
> >
> > Marek Vasut (6):
> > PCI: imx6: Make reset-gpio optional
> > PCI: imx6: Fix the clock for PCIe
> > ARM: dts: imx6qdl: Fix the clock for PCIe
> > PCI: imx6: Probe the PCIe in fs_initcall()
> > PCI: imx6: Force Gen1 operation
> > PCI: designware: Fix DT resource retrieval
> >
> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> > drivers/pci/host/pci-imx6.c | 63
> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
> > | 17 +++---
> > 4 files changed, 55 insertions(+), 31 deletions(-)
>
> Hi Marek,
>
> Your patchset modifies Synopsys Designware part. (pcie-designware.c)
> Thus, it would be better to share this patchset with Kishon Vijay Abraham
> I. He is also developing OMAP PCIe driver using 'pcie-designware.c'.
Putting him on CC, thanks
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 6/6] PCI: designware: Fix DT resource retrieval
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-16 0:15 ` Tim Harvey
-1 siblings, 0 replies; 62+ messages in thread
From: Tim Harvey @ 2013-10-16 0:15 UTC (permalink / raw
To: linux-arm-kernel
On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
>
> The resource retrieval from the DT was not done right. This resulted
> in bogus values in the IO/MEM window configuration. I re-used the code
> implementation from pci-tegra.c to do the resource retrieval correctly.
>
> This in turn resulted in very strange behavior on two different kinds
> of setup:
>
> Setup #1: ,-------> Intel i210 (igb driver)
> i.MX6 root port -----> PCIe switch
> `-------> Empty slot
>
> Setup #2: ,-------> Marvell Yukon (sky2 driver)
> i.MX6 root port -----> PCIe switch
> `-------> Empty slot
>
> Both setups expressed the same behavior. The system booted and the
> ethernet controllers were properly detected. After the controllers
> were configured and just after they reported "Ethernet Link Up", the
> entire system froze. It is now clear this happened because the resources
> were incorrectly configured, which in turn means the iATU was also not
> configured correctly.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
> drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> index 5d183ae..97c5951 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> struct device_node *np = pp->dev->of_node;
> struct of_pci_range range;
> struct of_pci_range_parser parser;
> + struct resource res;
> u32 val;
>
> struct irq_domain *irq_domain;
> @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
>
> /* Get the I/O and memory ranges from DT */
> for_each_of_pci_range(&parser, &range) {
> - unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> + of_pci_range_to_resource(&range, np, &res);
> + unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
> if (restype == IORESOURCE_IO) {
> - of_pci_range_to_resource(&range, np, &pp->io);
> + memcpy(&pp->io, &res, sizeof(res));
> pp->io.name = "I/O";
> - pp->io.start = max_t(resource_size_t,
> - PCIBIOS_MIN_IO,
> - range.pci_addr + global_io_offset);
> - pp->io.end = min_t(resource_size_t,
> - IO_SPACE_LIMIT,
> - range.pci_addr + range.size
> - + global_io_offset);
Nak - removing the adjustment to io.start/io.end breaks the io space
mapping as the entire io-space allocation gets taken by the root
complex. This causes any device that requests io space to fail to
obtain it (your igb driver from Setup1 apparently doesn't use io space
where my sky2 device from Setup2 above does).
If I put back the adjustment to io.start/io.end above my sky2 device
gets its io resource properly but still hangs the bus after a few
interrupts. Are you sure you don't have other changes that you
haven't posted yet that could have addressed the hang you get when you
bring up your igb device?
I agree that the the 'hang' we are seeing is a bus-hang caused by an
improper iATU mapping, however I'm not convinced its a dts parsing
issue.
Tim
> pp->config.io_size = resource_size(&pp->io);
> pp->config.io_bus_addr = range.pci_addr;
> }
> if (restype == IORESOURCE_MEM) {
> - of_pci_range_to_resource(&range, np, &pp->mem);
> + memcpy(&pp->mem, &res, sizeof(res));
> pp->mem.name = "MEM";
> pp->config.mem_size = resource_size(&pp->mem);
> pp->config.mem_bus_addr = range.pci_addr;
> }
> if (restype == 0) {
> - of_pci_range_to_resource(&range, np, &pp->cfg);
> + memcpy(&pp->cfg, &res, sizeof(res));
> pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> }
> --
> 1.8.4.rc3
>
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 6/6] PCI: designware: Fix DT resource retrieval
@ 2013-10-16 0:15 ` Tim Harvey
0 siblings, 0 replies; 62+ messages in thread
From: Tim Harvey @ 2013-10-16 0:15 UTC (permalink / raw
To: Marek Vasut
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Bjorn Helgaas, Frank Li, Jingoo Han, Mohit KUMAR, Pratyush Anand,
Richard Zhu, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Troy Kisky, Yinghai Lu
On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
>
> The resource retrieval from the DT was not done right. This resulted
> in bogus values in the IO/MEM window configuration. I re-used the code
> implementation from pci-tegra.c to do the resource retrieval correctly.
>
> This in turn resulted in very strange behavior on two different kinds
> of setup:
>
> Setup #1: ,-------> Intel i210 (igb driver)
> i.MX6 root port -----> PCIe switch
> `-------> Empty slot
>
> Setup #2: ,-------> Marvell Yukon (sky2 driver)
> i.MX6 root port -----> PCIe switch
> `-------> Empty slot
>
> Both setups expressed the same behavior. The system booted and the
> ethernet controllers were properly detected. After the controllers
> were configured and just after they reported "Ethernet Link Up", the
> entire system froze. It is now clear this happened because the resources
> were incorrectly configured, which in turn means the iATU was also not
> configured correctly.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
> drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> index 5d183ae..97c5951 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> struct device_node *np = pp->dev->of_node;
> struct of_pci_range range;
> struct of_pci_range_parser parser;
> + struct resource res;
> u32 val;
>
> struct irq_domain *irq_domain;
> @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
>
> /* Get the I/O and memory ranges from DT */
> for_each_of_pci_range(&parser, &range) {
> - unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> + of_pci_range_to_resource(&range, np, &res);
> + unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
> if (restype == IORESOURCE_IO) {
> - of_pci_range_to_resource(&range, np, &pp->io);
> + memcpy(&pp->io, &res, sizeof(res));
> pp->io.name = "I/O";
> - pp->io.start = max_t(resource_size_t,
> - PCIBIOS_MIN_IO,
> - range.pci_addr + global_io_offset);
> - pp->io.end = min_t(resource_size_t,
> - IO_SPACE_LIMIT,
> - range.pci_addr + range.size
> - + global_io_offset);
Nak - removing the adjustment to io.start/io.end breaks the io space
mapping as the entire io-space allocation gets taken by the root
complex. This causes any device that requests io space to fail to
obtain it (your igb driver from Setup1 apparently doesn't use io space
where my sky2 device from Setup2 above does).
If I put back the adjustment to io.start/io.end above my sky2 device
gets its io resource properly but still hangs the bus after a few
interrupts. Are you sure you don't have other changes that you
haven't posted yet that could have addressed the hang you get when you
bring up your igb device?
I agree that the the 'hang' we are seeing is a bus-hang caused by an
improper iATU mapping, however I'm not convinced its a dts parsing
issue.
Tim
> pp->config.io_size = resource_size(&pp->io);
> pp->config.io_bus_addr = range.pci_addr;
> }
> if (restype == IORESOURCE_MEM) {
> - of_pci_range_to_resource(&range, np, &pp->mem);
> + memcpy(&pp->mem, &res, sizeof(res));
> pp->mem.name = "MEM";
> pp->config.mem_size = resource_size(&pp->mem);
> pp->config.mem_bus_addr = range.pci_addr;
> }
> if (restype == 0) {
> - of_pci_range_to_resource(&range, np, &pp->cfg);
> + memcpy(&pp->cfg, &res, sizeof(res));
> pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> }
> --
> 1.8.4.rc3
>
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 1/6] PCI: imx6: Make reset-gpio optional
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-16 1:24 ` Jingoo Han
-1 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-16 1:24 UTC (permalink / raw
To: linux-arm-kernel
On Wednesday, October 16, 2013 1:07 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>
[.....]
> ---
> .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> drivers/pci/host/pci-imx6.c | 29 +++++++++++-----------
> 2 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index d5d26d4..b7a2279 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -19,9 +19,9 @@ Required properties:
> to define the mapping of the PCIe interface to interrupt
> numbers.
> - num-lanes: number of lanes to use
> -- reset-gpio: gpio pin number of power good signal
>
> Optional properties for fsl,imx6q-pcie
> +- reset-gpio: gpio pin number of power good signal
> - 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
(+cc Kishon Vijay Abraham I)
Also, 'reset-gpio' property can be used for 'samsung,exynos5440-pcie'.
Thus, it is not specific for 'fsl,imx6q-pcie'.
Please, modify it as below:
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -19,6 +19,8 @@ Required properties:
to define the mapping of the PCIe interface to interrupt
numbers.
- num-lanes: number of lanes to use
+
+Optional properties
- reset-gpio: gpio pin number of power good signal
Optional properties for fsl,imx6q-pcie
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 1/6] PCI: imx6: Make reset-gpio optional
@ 2013-10-16 1:24 ` Jingoo Han
0 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-16 1:24 UTC (permalink / raw
To: 'Marek Vasut', linux-pci
Cc: linux-arm-kernel, 'Bjorn Helgaas', 'Frank Li',
'Mohit KUMAR', 'Pratyush Anand',
'Richard Zhu', 'Sascha Hauer',
'Sean Cross', 'Shawn Guo',
'Siva Reddy Kallam', 'Srikanth T Shivanand',
'Tim Harvey', 'Troy Kisky', 'Yinghai Lu',
'Kishon Vijay Abraham I', 'Jingoo Han'
On Wednesday, October 16, 2013 1:07 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>
[.....]
> ---
> .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> drivers/pci/host/pci-imx6.c | 29 +++++++++++-----------
> 2 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index d5d26d4..b7a2279 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -19,9 +19,9 @@ Required properties:
> to define the mapping of the PCIe interface to interrupt
> numbers.
> - num-lanes: number of lanes to use
> -- reset-gpio: gpio pin number of power good signal
>
> Optional properties for fsl,imx6q-pcie
> +- reset-gpio: gpio pin number of power good signal
> - 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
(+cc Kishon Vijay Abraham I)
Also, 'reset-gpio' property can be used for 'samsung,exynos5440-pcie'.
Thus, it is not specific for 'fsl,imx6q-pcie'.
Please, modify it as below:
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -19,6 +19,8 @@ Required properties:
to define the mapping of the PCIe interface to interrupt
numbers.
- num-lanes: number of lanes to use
+
+Optional properties
- reset-gpio: gpio pin number of power good signal
Optional properties for fsl,imx6q-pcie
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 6/6] PCI: designware: Fix DT resource retrieval
2013-10-16 0:15 ` Tim Harvey
@ 2013-10-16 3:56 ` Jingoo Han
-1 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-16 3:56 UTC (permalink / raw
To: linux-arm-kernel
On Wednesday, October 16, 2013 9:15 AM, Tim Harvey wrote:
> On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> >
> > The resource retrieval from the DT was not done right. This resulted
> > in bogus values in the IO/MEM window configuration. I re-used the code
> > implementation from pci-tegra.c to do the resource retrieval correctly.
> >
> > This in turn resulted in very strange behavior on two different kinds
> > of setup:
> >
> > Setup #1: ,-------> Intel i210 (igb driver)
> > i.MX6 root port -----> PCIe switch
> > `-------> Empty slot
> >
> > Setup #2: ,-------> Marvell Yukon (sky2 driver)
> > i.MX6 root port -----> PCIe switch
> > `-------> Empty slot
> >
> > Both setups expressed the same behavior. The system booted and the
> > ethernet controllers were properly detected. After the controllers
> > were configured and just after they reported "Ethernet Link Up", the
> > entire system froze. It is now clear this happened because the resources
> > were incorrectly configured, which in turn means the iATU was also not
> > configured correctly.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> > drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> > 1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> > index 5d183ae..97c5951 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > struct device_node *np = pp->dev->of_node;
> > struct of_pci_range range;
> > struct of_pci_range_parser parser;
> > + struct resource res;
> > u32 val;
> >
> > struct irq_domain *irq_domain;
> > @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> >
> > /* Get the I/O and memory ranges from DT */
> > for_each_of_pci_range(&parser, &range) {
> > - unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> > + of_pci_range_to_resource(&range, np, &res);
> > + unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
This makes the following build warning.
warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
Please modify it as below:
unsigned long restype;
of_pci_range_to_resource(&range, np, &res);
restype = res.flags & IORESOURCE_TYPE_BITS;
> > if (restype == IORESOURCE_IO) {
> > - of_pci_range_to_resource(&range, np, &pp->io);
> > + memcpy(&pp->io, &res, sizeof(res));
> > pp->io.name = "I/O";
> > - pp->io.start = max_t(resource_size_t,
> > - PCIBIOS_MIN_IO,
> > - range.pci_addr + global_io_offset);
> > - pp->io.end = min_t(resource_size_t,
> > - IO_SPACE_LIMIT,
> > - range.pci_addr + range.size
> > - + global_io_offset);
>
> Nak - removing the adjustment to io.start/io.end breaks the io space
> mapping as the entire io-space allocation gets taken by the root
> complex. This causes any device that requests io space to fail to
> obtain it (your igb driver from Setup1 apparently doesn't use io space
> where my sky2 device from Setup2 above does).
>
> If I put back the adjustment to io.start/io.end above my sky2 device
> gets its io resource properly but still hangs the bus after a few
> interrupts. Are you sure you don't have other changes that you
> haven't posted yet that could have addressed the hang you get when you
> bring up your igb device?
>
> I agree that the the 'hang' we are seeing is a bus-hang caused by an
> improper iATU mapping, however I'm not convinced its a dts parsing
> issue.
>
> Tim
+cc Kishon Vijay Abraham I, Arnd Bergmann
I agree with Tim's opinion.
Please, don't remove the adjustment to io.start/io.end mapping.
It was already confirmed by Arnd Bergmann (ARM-SoC Maintainer).
Best regards,
Jingoo Han
>
> > pp->config.io_size = resource_size(&pp->io);
> > pp->config.io_bus_addr = range.pci_addr;
> > }
> > if (restype == IORESOURCE_MEM) {
> > - of_pci_range_to_resource(&range, np, &pp->mem);
> > + memcpy(&pp->mem, &res, sizeof(res));
> > pp->mem.name = "MEM";
> > pp->config.mem_size = resource_size(&pp->mem);
> > pp->config.mem_bus_addr = range.pci_addr;
> > }
> > if (restype == 0) {
> > - of_pci_range_to_resource(&range, np, &pp->cfg);
> > + memcpy(&pp->cfg, &res, sizeof(res));
> > pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> > pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> > }
> > --
> > 1.8.4.rc3
> >
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 6/6] PCI: designware: Fix DT resource retrieval
@ 2013-10-16 3:56 ` Jingoo Han
0 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-16 3:56 UTC (permalink / raw
To: 'Tim Harvey', 'Marek Vasut'
Cc: linux-pci, linux-arm-kernel, 'Bjorn Helgaas',
'Frank Li', 'Mohit KUMAR',
'Pratyush Anand', 'Richard Zhu',
'Sascha Hauer', 'Sean Cross', 'Shawn Guo',
'Siva Reddy Kallam', 'Srikanth T Shivanand',
'Troy Kisky', 'Yinghai Lu',
'Kishon Vijay Abraham I', 'Arnd Bergmann',
'Jingoo Han'
On Wednesday, October 16, 2013 9:15 AM, Tim Harvey wrote:
> On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> >
> > The resource retrieval from the DT was not done right. This resulted
> > in bogus values in the IO/MEM window configuration. I re-used the code
> > implementation from pci-tegra.c to do the resource retrieval correctly.
> >
> > This in turn resulted in very strange behavior on two different kinds
> > of setup:
> >
> > Setup #1: ,-------> Intel i210 (igb driver)
> > i.MX6 root port -----> PCIe switch
> > `-------> Empty slot
> >
> > Setup #2: ,-------> Marvell Yukon (sky2 driver)
> > i.MX6 root port -----> PCIe switch
> > `-------> Empty slot
> >
> > Both setups expressed the same behavior. The system booted and the
> > ethernet controllers were properly detected. After the controllers
> > were configured and just after they reported "Ethernet Link Up", the
> > entire system froze. It is now clear this happened because the resources
> > were incorrectly configured, which in turn means the iATU was also not
> > configured correctly.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> > drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> > 1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> > index 5d183ae..97c5951 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > struct device_node *np = pp->dev->of_node;
> > struct of_pci_range range;
> > struct of_pci_range_parser parser;
> > + struct resource res;
> > u32 val;
> >
> > struct irq_domain *irq_domain;
> > @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> >
> > /* Get the I/O and memory ranges from DT */
> > for_each_of_pci_range(&parser, &range) {
> > - unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> > + of_pci_range_to_resource(&range, np, &res);
> > + unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
This makes the following build warning.
warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
Please modify it as below:
unsigned long restype;
of_pci_range_to_resource(&range, np, &res);
restype = res.flags & IORESOURCE_TYPE_BITS;
> > if (restype == IORESOURCE_IO) {
> > - of_pci_range_to_resource(&range, np, &pp->io);
> > + memcpy(&pp->io, &res, sizeof(res));
> > pp->io.name = "I/O";
> > - pp->io.start = max_t(resource_size_t,
> > - PCIBIOS_MIN_IO,
> > - range.pci_addr + global_io_offset);
> > - pp->io.end = min_t(resource_size_t,
> > - IO_SPACE_LIMIT,
> > - range.pci_addr + range.size
> > - + global_io_offset);
>
> Nak - removing the adjustment to io.start/io.end breaks the io space
> mapping as the entire io-space allocation gets taken by the root
> complex. This causes any device that requests io space to fail to
> obtain it (your igb driver from Setup1 apparently doesn't use io space
> where my sky2 device from Setup2 above does).
>
> If I put back the adjustment to io.start/io.end above my sky2 device
> gets its io resource properly but still hangs the bus after a few
> interrupts. Are you sure you don't have other changes that you
> haven't posted yet that could have addressed the hang you get when you
> bring up your igb device?
>
> I agree that the the 'hang' we are seeing is a bus-hang caused by an
> improper iATU mapping, however I'm not convinced its a dts parsing
> issue.
>
> Tim
+cc Kishon Vijay Abraham I, Arnd Bergmann
I agree with Tim's opinion.
Please, don't remove the adjustment to io.start/io.end mapping.
It was already confirmed by Arnd Bergmann (ARM-SoC Maintainer).
Best regards,
Jingoo Han
>
> > pp->config.io_size = resource_size(&pp->io);
> > pp->config.io_bus_addr = range.pci_addr;
> > }
> > if (restype == IORESOURCE_MEM) {
> > - of_pci_range_to_resource(&range, np, &pp->mem);
> > + memcpy(&pp->mem, &res, sizeof(res));
> > pp->mem.name = "MEM";
> > pp->config.mem_size = resource_size(&pp->mem);
> > pp->config.mem_bus_addr = range.pci_addr;
> > }
> > if (restype == 0) {
> > - of_pci_range_to_resource(&range, np, &pp->cfg);
> > + memcpy(&pp->cfg, &res, sizeof(res));
> > pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> > pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> > }
> > --
> > 1.8.4.rc3
> >
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-16 5:54 ` Pratyush Anand
-1 siblings, 0 replies; 62+ messages in thread
From: Pratyush Anand @ 2013-10-16 5:54 UTC (permalink / raw
To: linux-arm-kernel
On Wed, Oct 16, 2013 at 12:06:39AM +0800, Marek Vasut wrote:
> Without forcing the PCIe core into Gen1 operation, the PCIe switch
> attached directly to the PCIe port is not recognised at all. The
> PCIe switch is Gen2 capable to make this issue even more puzzling.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
> drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index ca8c5de..8402e9a 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
> {
> int count = 0;
> struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> + uint32_t tmp;
>
> imx6_pcie_assert_core_reset(pp);
>
> @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
>
> dw_pcie_setup_rc(pp);
>
> + /*
> + * FIXME:
> + * Force Gen1 operation. In case the IP block is in Gen2 operation
> + * mode, it does not detect the PCIe switch at all.
> + */
> + tmp = readl(pp->dbi_base + 0x7c);
> + tmp &= ~0xf;
> + tmp |= 0x1;
> + writel(tmp, pp->dbi_base + 0x7c);
> +
Since you are forcing RC to work in GEN1, so you will not be able to
connect any device at GEN2 now.
Yes, There are some buggy PCIe devices which works with GEN1 only host.
So better solution should be to initialize RC by default at GEN2 or
highest speed. Further, a parameter say gen_only can be passed from
DT to force GEN1 only mode.
What do you say?
Regards
Pratyush
> 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",
> --
> 1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-16 5:54 ` Pratyush Anand
0 siblings, 0 replies; 62+ messages in thread
From: Pratyush Anand @ 2013-10-16 5:54 UTC (permalink / raw
To: Marek Vasut, Bjorn Helgaas
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Frank Li, Jingoo Han, Mohit KUMAR DCG, Richard Zhu, Sascha Hauer,
Sean Cross, Shawn Guo, Siva Reddy Kallam, Srikanth T Shivanand,
Tim Harvey, Troy Kisky, Yinghai Lu
On Wed, Oct 16, 2013 at 12:06:39AM +0800, Marek Vasut wrote:
> Without forcing the PCIe core into Gen1 operation, the PCIe switch
> attached directly to the PCIe port is not recognised at all. The
> PCIe switch is Gen2 capable to make this issue even more puzzling.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
> drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index ca8c5de..8402e9a 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
> {
> int count = 0;
> struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> + uint32_t tmp;
>
> imx6_pcie_assert_core_reset(pp);
>
> @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
>
> dw_pcie_setup_rc(pp);
>
> + /*
> + * FIXME:
> + * Force Gen1 operation. In case the IP block is in Gen2 operation
> + * mode, it does not detect the PCIe switch at all.
> + */
> + tmp = readl(pp->dbi_base + 0x7c);
> + tmp &= ~0xf;
> + tmp |= 0x1;
> + writel(tmp, pp->dbi_base + 0x7c);
> +
Since you are forcing RC to work in GEN1, so you will not be able to
connect any device at GEN2 now.
Yes, There are some buggy PCIe devices which works with GEN1 only host.
So better solution should be to initialize RC by default at GEN2 or
highest speed. Further, a parameter say gen_only can be passed from
DT to force GEN1 only mode.
What do you say?
Regards
Pratyush
> 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",
> --
> 1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-16 5:54 ` Pratyush Anand
@ 2013-10-16 13:57 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-16 13:57 UTC (permalink / raw
To: linux-arm-kernel
Dear Pratyush Anand,
> On Wed, Oct 16, 2013 at 12:06:39AM +0800, Marek Vasut wrote:
> > Without forcing the PCIe core into Gen1 operation, the PCIe switch
> > attached directly to the PCIe port is not recognised at all. The
> > PCIe switch is Gen2 capable to make this issue even more puzzling.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> >
> > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> > index ca8c5de..8402e9a 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
> >
> > {
> >
> > int count = 0;
> > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> >
> > + uint32_t tmp;
> >
> > imx6_pcie_assert_core_reset(pp);
> >
> > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct pcie_port
> > *pp)
> >
> > dw_pcie_setup_rc(pp);
> >
> > + /*
> > + * FIXME:
> > + * Force Gen1 operation. In case the IP block is in Gen2 operation
> > + * mode, it does not detect the PCIe switch at all.
> > + */
> > + tmp = readl(pp->dbi_base + 0x7c);
> > + tmp &= ~0xf;
> > + tmp |= 0x1;
> > + writel(tmp, pp->dbi_base + 0x7c);
> > +
>
> Since you are forcing RC to work in GEN1, so you will not be able to
> connect any device at GEN2 now.
I'd rather prefer to know WHY if the RC is operating in Gen2 mode by default, I
cannot see the PCIe switch (Pericom PI7C9X2G303) connected to it. I was unable
to figure this out. Tim pointed out this thread [1] , so it might be related in
some way.
[1] https://community.freescale.com/message/316162#316162
I tried switching the PCIe RC to Gen2 operation right after LinkUp by writing
this register with 0x2 again and re-issuing the LinkUp check, which passed and
the status register reported Gen2 operation, but then the PCIe Intel NIC
connected to the downstream port of the Pericom switch still reported Gen1
operation for some reason.
> Yes, There are some buggy PCIe devices which works with GEN1 only host.
The pericom one is Gen2 according to it's datasheet.
> So better solution should be to initialize RC by default at GEN2 or
> highest speed. Further, a parameter say gen_only can be passed from
> DT to force GEN1 only mode.
>
> What do you say?
I say I'd like to know the root cause of this problem. This Gen2 fix was pulled
from one of the myriad variants of the FSL PCIe driver, so apparently this issue
happens to other people as well. But why and how to properly fix this so the
whole PCIe bus does operate in Gen2 mode, I cannot tell :-(
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-16 13:57 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-16 13:57 UTC (permalink / raw
To: Pratyush Anand
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Frank Li, Jingoo Han,
Mohit KUMAR DCG, Richard Zhu, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Tim Harvey, Troy Kisky,
Yinghai Lu
Dear Pratyush Anand,
> On Wed, Oct 16, 2013 at 12:06:39AM +0800, Marek Vasut wrote:
> > Without forcing the PCIe core into Gen1 operation, the PCIe switch
> > attached directly to the PCIe port is not recognised at all. The
> > PCIe switch is Gen2 capable to make this issue even more puzzling.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> >
> > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> > index ca8c5de..8402e9a 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
> >
> > {
> >
> > int count = 0;
> > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> >
> > + uint32_t tmp;
> >
> > imx6_pcie_assert_core_reset(pp);
> >
> > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct pcie_port
> > *pp)
> >
> > dw_pcie_setup_rc(pp);
> >
> > + /*
> > + * FIXME:
> > + * Force Gen1 operation. In case the IP block is in Gen2 operation
> > + * mode, it does not detect the PCIe switch at all.
> > + */
> > + tmp = readl(pp->dbi_base + 0x7c);
> > + tmp &= ~0xf;
> > + tmp |= 0x1;
> > + writel(tmp, pp->dbi_base + 0x7c);
> > +
>
> Since you are forcing RC to work in GEN1, so you will not be able to
> connect any device at GEN2 now.
I'd rather prefer to know WHY if the RC is operating in Gen2 mode by default, I
cannot see the PCIe switch (Pericom PI7C9X2G303) connected to it. I was unable
to figure this out. Tim pointed out this thread [1] , so it might be related in
some way.
[1] https://community.freescale.com/message/316162#316162
I tried switching the PCIe RC to Gen2 operation right after LinkUp by writing
this register with 0x2 again and re-issuing the LinkUp check, which passed and
the status register reported Gen2 operation, but then the PCIe Intel NIC
connected to the downstream port of the Pericom switch still reported Gen1
operation for some reason.
> Yes, There are some buggy PCIe devices which works with GEN1 only host.
The pericom one is Gen2 according to it's datasheet.
> So better solution should be to initialize RC by default at GEN2 or
> highest speed. Further, a parameter say gen_only can be passed from
> DT to force GEN1 only mode.
>
> What do you say?
I say I'd like to know the root cause of this problem. This Gen2 fix was pulled
from one of the myriad variants of the FSL PCIe driver, so apparently this issue
happens to other people as well. But why and how to properly fix this so the
whole PCIe bus does operate in Gen2 mode, I cannot tell :-(
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 6/6] PCI: designware: Fix DT resource retrieval
2013-10-16 0:15 ` Tim Harvey
@ 2013-10-16 14:05 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-16 14:05 UTC (permalink / raw
To: linux-arm-kernel
Hi Tim,
> On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> > The resource retrieval from the DT was not done right. This resulted
> > in bogus values in the IO/MEM window configuration. I re-used the code
> > implementation from pci-tegra.c to do the resource retrieval correctly.
> >
> > This in turn resulted in very strange behavior on two different kinds
> > of setup:
> >
> > Setup #1: ,-------> Intel i210 (igb driver)
> >
> > i.MX6 root port -----> PCIe switch
> >
> > `-------> Empty slot
> >
> > Setup #2: ,-------> Marvell Yukon (sky2
> > driver)
> >
> > i.MX6 root port -----> PCIe switch
> >
> > `-------> Empty slot
> >
> > Both setups expressed the same behavior. The system booted and the
> > ethernet controllers were properly detected. After the controllers
> > were configured and just after they reported "Ethernet Link Up", the
> > entire system froze. It is now clear this happened because the resources
> > were incorrectly configured, which in turn means the iATU was also not
> > configured correctly.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> >
> > drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> > 1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c index 5d183ae..97c5951 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> >
> > struct device_node *np = pp->dev->of_node;
> > struct of_pci_range range;
> > struct of_pci_range_parser parser;
> >
> > + struct resource res;
> >
> > u32 val;
> >
> > struct irq_domain *irq_domain;
> >
> > @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> >
> > /* Get the I/O and memory ranges from DT */
> > for_each_of_pci_range(&parser, &range) {
> >
> > - unsigned long restype = range.flags &
> > IORESOURCE_TYPE_BITS; + of_pci_range_to_resource(&range,
> > np, &res);
> > + unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
> >
> > if (restype == IORESOURCE_IO) {
> >
> > - of_pci_range_to_resource(&range, np, &pp->io);
> > + memcpy(&pp->io, &res, sizeof(res));
> >
> > pp->io.name = "I/O";
> >
> > - pp->io.start = max_t(resource_size_t,
> > - PCIBIOS_MIN_IO,
> > - range.pci_addr +
> > global_io_offset); - pp->io.end =
> > min_t(resource_size_t,
> > - IO_SPACE_LIMIT,
> > - range.pci_addr + range.size
> > - + global_io_offset);
>
> Nak - removing the adjustment to io.start/io.end breaks the io space
> mapping as the entire io-space allocation gets taken by the root
> complex. This causes any device that requests io space to fail to
> obtain it (your igb driver from Setup1 apparently doesn't use io space
> where my sky2 device from Setup2 above does).
OK. I still think this kind of restype comparison is bogus. The range.flags and
IORESOURCE_.* do not match bit-wise. Do we agree on this part? I also agree --
as disussed with you -- that there might be bugs in the DT bindings. I will
repost the V2s later tonight.
--->8---
unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
[...]
if (restype == IORESOURCE_MEM) {
---8<---
> If I put back the adjustment to io.start/io.end above my sky2 device
> gets its io resource properly but still hangs the bus after a few
> interrupts. Are you sure you don't have other changes that you
> haven't posted yet that could have addressed the hang you get when you
> bring up your igb device?
I'm absolutely positive. I double-checked this now. One more patch I have is
this IRQ fixup, but that's all.
pcie: correct the irq map when pcie switch is used
> I agree that the the 'hang' we are seeing is a bus-hang caused by an
> improper iATU mapping, however I'm not convinced its a dts parsing
> issue.
>
> Tim
> >
> > - of_pci_range_to_resource(&range, np, &pp->mem);
> > + memcpy(&pp->mem, &res, sizeof(res));
> >
> > pp->mem.name = "MEM";
> > pp->config.mem_size = resource_size(&pp->mem);
> > pp->config.mem_bus_addr = range.pci_addr;
> >
> > }
> > if (restype == 0) {
> >
> > - of_pci_range_to_resource(&range, np, &pp->cfg);
> > + memcpy(&pp->cfg, &res, sizeof(res));
> >
> > pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> > pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> >
> > }
> >
> > --
> > 1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 6/6] PCI: designware: Fix DT resource retrieval
@ 2013-10-16 14:05 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-16 14:05 UTC (permalink / raw
To: Tim Harvey
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Bjorn Helgaas, Frank Li, Jingoo Han, Mohit KUMAR, Pratyush Anand,
Richard Zhu, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Troy Kisky, Yinghai Lu
Hi Tim,
> On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> > The resource retrieval from the DT was not done right. This resulted
> > in bogus values in the IO/MEM window configuration. I re-used the code
> > implementation from pci-tegra.c to do the resource retrieval correctly.
> >
> > This in turn resulted in very strange behavior on two different kinds
> > of setup:
> >
> > Setup #1: ,-------> Intel i210 (igb driver)
> >
> > i.MX6 root port -----> PCIe switch
> >
> > `-------> Empty slot
> >
> > Setup #2: ,-------> Marvell Yukon (sky2
> > driver)
> >
> > i.MX6 root port -----> PCIe switch
> >
> > `-------> Empty slot
> >
> > Both setups expressed the same behavior. The system booted and the
> > ethernet controllers were properly detected. After the controllers
> > were configured and just after they reported "Ethernet Link Up", the
> > entire system froze. It is now clear this happened because the resources
> > were incorrectly configured, which in turn means the iATU was also not
> > configured correctly.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Frank Li <lznuaa@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> > Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> > Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> > Cc: Tim Harvey <tharvey@gateworks.com>
> > Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > ---
> >
> > drivers/pci/host/pcie-designware.c | 17 ++++++-----------
> > 1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c index 5d183ae..97c5951 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -370,6 +370,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> >
> > struct device_node *np = pp->dev->of_node;
> > struct of_pci_range range;
> > struct of_pci_range_parser parser;
> >
> > + struct resource res;
> >
> > u32 val;
> >
> > struct irq_domain *irq_domain;
> >
> > @@ -381,28 +382,22 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> >
> > /* Get the I/O and memory ranges from DT */
> > for_each_of_pci_range(&parser, &range) {
> >
> > - unsigned long restype = range.flags &
> > IORESOURCE_TYPE_BITS; + of_pci_range_to_resource(&range,
> > np, &res);
> > + unsigned long restype = res.flags & IORESOURCE_TYPE_BITS;
> >
> > if (restype == IORESOURCE_IO) {
> >
> > - of_pci_range_to_resource(&range, np, &pp->io);
> > + memcpy(&pp->io, &res, sizeof(res));
> >
> > pp->io.name = "I/O";
> >
> > - pp->io.start = max_t(resource_size_t,
> > - PCIBIOS_MIN_IO,
> > - range.pci_addr +
> > global_io_offset); - pp->io.end =
> > min_t(resource_size_t,
> > - IO_SPACE_LIMIT,
> > - range.pci_addr + range.size
> > - + global_io_offset);
>
> Nak - removing the adjustment to io.start/io.end breaks the io space
> mapping as the entire io-space allocation gets taken by the root
> complex. This causes any device that requests io space to fail to
> obtain it (your igb driver from Setup1 apparently doesn't use io space
> where my sky2 device from Setup2 above does).
OK. I still think this kind of restype comparison is bogus. The range.flags and
IORESOURCE_.* do not match bit-wise. Do we agree on this part? I also agree --
as disussed with you -- that there might be bugs in the DT bindings. I will
repost the V2s later tonight.
--->8---
unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
[...]
if (restype == IORESOURCE_MEM) {
---8<---
> If I put back the adjustment to io.start/io.end above my sky2 device
> gets its io resource properly but still hangs the bus after a few
> interrupts. Are you sure you don't have other changes that you
> haven't posted yet that could have addressed the hang you get when you
> bring up your igb device?
I'm absolutely positive. I double-checked this now. One more patch I have is
this IRQ fixup, but that's all.
pcie: correct the irq map when pcie switch is used
> I agree that the the 'hang' we are seeing is a bus-hang caused by an
> improper iATU mapping, however I'm not convinced its a dts parsing
> issue.
>
> Tim
> >
> > - of_pci_range_to_resource(&range, np, &pp->mem);
> > + memcpy(&pp->mem, &res, sizeof(res));
> >
> > pp->mem.name = "MEM";
> > pp->config.mem_size = resource_size(&pp->mem);
> > pp->config.mem_bus_addr = range.pci_addr;
> >
> > }
> > if (restype == 0) {
> >
> > - of_pci_range_to_resource(&range, np, &pp->cfg);
> > + memcpy(&pp->cfg, &res, sizeof(res));
> >
> > pp->config.cfg0_size = resource_size(&pp->cfg)/2;
> > pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> >
> > }
> >
> > --
> > 1.8.4.rc3
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-16 13:57 ` Marek Vasut
@ 2013-10-17 7:02 ` Zhu Richard-R65037
-1 siblings, 0 replies; 62+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-17 7:02 UTC (permalink / raw
To: linux-arm-kernel
Hi Marek:
> -----Original Message-----
[...]
> > > ---
> > >
> > > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/pci/host/pci-imx6.c
> > > b/drivers/pci/host/pci-imx6.c index ca8c5de..8402e9a 100644
> > > --- a/drivers/pci/host/pci-imx6.c
> > > +++ b/drivers/pci/host/pci-imx6.c
> > > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port
> > > *pp)
> > >
> > > {
> > >
> > > int count = 0;
> > > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> > >
> > > + uint32_t tmp;
> > >
> > > imx6_pcie_assert_core_reset(pp);
> > >
> > > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct
> > > pcie_port
> > > *pp)
> > >
> > > dw_pcie_setup_rc(pp);
> > >
> > > + /*
> > > + * FIXME:
> > > + * Force Gen1 operation. In case the IP block is in Gen2 operation
> > > + * mode, it does not detect the PCIe switch at all.
> > > + */
> > > + tmp = readl(pp->dbi_base + 0x7c);
> > > + tmp &= ~0xf;
> > > + tmp |= 0x1;
> > > + writel(tmp, pp->dbi_base + 0x7c);
> > > +
> >
> > Since you are forcing RC to work in GEN1, so you will not be able to
> > connect any device at GEN2 now.
>
> I'd rather prefer to know WHY if the RC is operating in Gen2 mode by default,
> I cannot see the PCIe switch (Pericom PI7C9X2G303) connected to it. I was
> unable to figure this out. Tim pointed out this thread [1] , so it might be
> related in some way.
>
> [1] https://community.freescale.com/message/316162#316162
>
> I tried switching the PCIe RC to Gen2 operation right after LinkUp by writing
> this register with 0x2 again and re-issuing the LinkUp check, which passed and
> the status register reported Gen2 operation, but then the PCIe Intel NIC
> connected to the downstream port of the Pericom switch still reported Gen1
> operation for some reason.
>
[Richard] Is your Inetl NIC GEN1 EP device?
> > Yes, There are some buggy PCIe devices which works with GEN1 only host.
>
> The pericom one is Gen2 according to it's datasheet.
[Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
It had been verified on FSL's 3.0.35 releases.
>
> > So better solution should be to initialize RC by default at GEN2 or
> > highest speed. Further, a parameter say gen_only can be passed from DT
> > to force GEN1 only mode.
> >
> > What do you say?
>
> I say I'd like to know the root cause of this problem. This Gen2 fix was
> pulled from one of the myriad variants of the FSL PCIe driver, so apparently
> this issue happens to other people as well. But why and how to properly fix
> this so the whole PCIe bus does operate in Gen2 mode, I cannot tell :-(
[Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases before.
I don't know why it can't work in GEN2 mode in the latest kernel.
BTW, Based on for-next branch of shawn's git reops and applied Merak's patch-set,
my PI7C9X2G303EL with intel e1000e network card plugged can't be detected at all. :(.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Best Regards
Richard Zhu
^ permalink raw reply [flat|nested] 62+ messages in thread
* RE: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-17 7:02 ` Zhu Richard-R65037
0 siblings, 0 replies; 62+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-17 7:02 UTC (permalink / raw
To: Marek Vasut, Pratyush Anand
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Frank Li, Jingoo Han,
Mohit KUMAR DCG, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Tim Harvey, Troy Kisky,
Yinghai Lu
Hi Marek:
> -----Original Message-----
[...]
> > > ---
> > >
> > > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/pci/host/pci-imx6.c
> > > b/drivers/pci/host/pci-imx6.c index ca8c5de..8402e9a 100644
> > > --- a/drivers/pci/host/pci-imx6.c
> > > +++ b/drivers/pci/host/pci-imx6.c
> > > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port
> > > *pp)
> > >
> > > {
> > >
> > > int count = 0;
> > > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> > >
> > > + uint32_t tmp;
> > >
> > > imx6_pcie_assert_core_reset(pp);
> > >
> > > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct
> > > pcie_port
> > > *pp)
> > >
> > > dw_pcie_setup_rc(pp);
> > >
> > > + /*
> > > + * FIXME:
> > > + * Force Gen1 operation. In case the IP block is in Gen2 operation
> > > + * mode, it does not detect the PCIe switch at all.
> > > + */
> > > + tmp = readl(pp->dbi_base + 0x7c);
> > > + tmp &= ~0xf;
> > > + tmp |= 0x1;
> > > + writel(tmp, pp->dbi_base + 0x7c);
> > > +
> >
> > Since you are forcing RC to work in GEN1, so you will not be able to
> > connect any device at GEN2 now.
>
> I'd rather prefer to know WHY if the RC is operating in Gen2 mode by default,
> I cannot see the PCIe switch (Pericom PI7C9X2G303) connected to it. I was
> unable to figure this out. Tim pointed out this thread [1] , so it might be
> related in some way.
>
> [1] https://community.freescale.com/message/316162#316162
>
> I tried switching the PCIe RC to Gen2 operation right after LinkUp by writing
> this register with 0x2 again and re-issuing the LinkUp check, which passed and
> the status register reported Gen2 operation, but then the PCIe Intel NIC
> connected to the downstream port of the Pericom switch still reported Gen1
> operation for some reason.
>
[Richard] Is your Inetl NIC GEN1 EP device?
> > Yes, There are some buggy PCIe devices which works with GEN1 only host.
>
> The pericom one is Gen2 according to it's datasheet.
[Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
It had been verified on FSL's 3.0.35 releases.
>
> > So better solution should be to initialize RC by default at GEN2 or
> > highest speed. Further, a parameter say gen_only can be passed from DT
> > to force GEN1 only mode.
> >
> > What do you say?
>
> I say I'd like to know the root cause of this problem. This Gen2 fix was
> pulled from one of the myriad variants of the FSL PCIe driver, so apparently
> this issue happens to other people as well. But why and how to properly fix
> this so the whole PCIe bus does operate in Gen2 mode, I cannot tell :-(
[Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases before.
I don't know why it can't work in GEN2 mode in the latest kernel.
BTW, Based on for-next branch of shawn's git reops and applied Merak's patch-set,
my PI7C9X2G303EL with intel e1000e network card plugged can't be detected at all. :(.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Best Regards
Richard Zhu
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-17 7:02 ` Zhu Richard-R65037
@ 2013-10-17 17:34 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-17 17:34 UTC (permalink / raw
To: linux-arm-kernel
Hi Richard,
> Hi Marek:
> > -----Original Message-----
>
> [...]
>
> > > > ---
> > > >
> > > > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/host/pci-imx6.c
> > > > b/drivers/pci/host/pci-imx6.c index ca8c5de..8402e9a 100644
> > > > --- a/drivers/pci/host/pci-imx6.c
> > > > +++ b/drivers/pci/host/pci-imx6.c
> > > > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port
> > > > *pp)
> > > >
> > > > {
> > > >
> > > > int count = 0;
> > > > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> > > >
> > > > + uint32_t tmp;
> > > >
> > > > imx6_pcie_assert_core_reset(pp);
> > > >
> > > > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct
> > > > pcie_port
> > > > *pp)
> > > >
> > > > dw_pcie_setup_rc(pp);
> > > >
> > > > + /*
> > > > + * FIXME:
> > > > + * Force Gen1 operation. In case the IP block is in Gen2
operation
> > > > + * mode, it does not detect the PCIe switch at all.
> > > > + */
> > > > + tmp = readl(pp->dbi_base + 0x7c);
> > > > + tmp &= ~0xf;
> > > > + tmp |= 0x1;
> > > > + writel(tmp, pp->dbi_base + 0x7c);
> > > > +
> > >
> > > Since you are forcing RC to work in GEN1, so you will not be able to
> > > connect any device at GEN2 now.
> >
> > I'd rather prefer to know WHY if the RC is operating in Gen2 mode by
> > default, I cannot see the PCIe switch (Pericom PI7C9X2G303) connected to
> > it. I was unable to figure this out. Tim pointed out this thread [1] ,
> > so it might be related in some way.
> >
> > [1] https://community.freescale.com/message/316162#316162
> >
> > I tried switching the PCIe RC to Gen2 operation right after LinkUp by
> > writing this register with 0x2 again and re-issuing the LinkUp check,
> > which passed and the status register reported Gen2 operation, but then
> > the PCIe Intel NIC connected to the downstream port of the Pericom
> > switch still reported Gen1 operation for some reason.
>
> [Richard] Is your Inetl NIC GEN1 EP device?
Yes, the i210 is PCIe v2.1 (2.5GT/s) x1 device.
> > > Yes, There are some buggy PCIe devices which works with GEN1 only host.
> >
> > The pericom one is Gen2 according to it's datasheet.
>
> [Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
> It had been verified on FSL's 3.0.35 releases.
Verified how? What does it mean?
Note that when I followed [1] in this manner:
1) Force GEN1 mode
2) Wait for PHY link up
3) Allow GEN2 mode
4) Start GEN2 speed change
5) Wait for PHY link up
my devices were detected and the link between pericom and mx6 was operating in
gen2 mode. Thus I suspect we might need to start the port in Gen1 mode and
switch to Gen2 only after link is up. Does that make sense?
https://community.freescale.com/thread/304284
> > > So better solution should be to initialize RC by default at GEN2 or
> > > highest speed. Further, a parameter say gen_only can be passed from DT
> > > to force GEN1 only mode.
> > >
> > > What do you say?
> >
> > I say I'd like to know the root cause of this problem. This Gen2 fix was
> > pulled from one of the myriad variants of the FSL PCIe driver, so
> > apparently this issue happens to other people as well. But why and how
> > to properly fix this so the whole PCIe bus does operate in Gen2 mode, I
> > cannot tell :-(
>
> [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases before.
> I don't know why it can't work in GEN2 mode in the latest kernel.
> BTW, Based on for-next branch of shawn's git reops and applied Merak's
> patch-set, my PI7C9X2G303EL with intel e1000e network card plugged can't
> be detected at all. :(.
I think we're still fighting some issue with resource mappings here. We also
agreed with Tim that my patches are incomplete. I will send out a new version
ASAP.
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-17 17:34 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-17 17:34 UTC (permalink / raw
To: Zhu Richard-R65037
Cc: Pratyush Anand, Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Frank Li, Jingoo Han,
Mohit KUMAR DCG, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Tim Harvey, Troy Kisky,
Yinghai Lu
Hi Richard,
> Hi Marek:
> > -----Original Message-----
>
> [...]
>
> > > > ---
> > > >
> > > > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/host/pci-imx6.c
> > > > b/drivers/pci/host/pci-imx6.c index ca8c5de..8402e9a 100644
> > > > --- a/drivers/pci/host/pci-imx6.c
> > > > +++ b/drivers/pci/host/pci-imx6.c
> > > > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct pcie_port
> > > > *pp)
> > > >
> > > > {
> > > >
> > > > int count = 0;
> > > > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> > > >
> > > > + uint32_t tmp;
> > > >
> > > > imx6_pcie_assert_core_reset(pp);
> > > >
> > > > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct
> > > > pcie_port
> > > > *pp)
> > > >
> > > > dw_pcie_setup_rc(pp);
> > > >
> > > > + /*
> > > > + * FIXME:
> > > > + * Force Gen1 operation. In case the IP block is in Gen2
operation
> > > > + * mode, it does not detect the PCIe switch at all.
> > > > + */
> > > > + tmp = readl(pp->dbi_base + 0x7c);
> > > > + tmp &= ~0xf;
> > > > + tmp |= 0x1;
> > > > + writel(tmp, pp->dbi_base + 0x7c);
> > > > +
> > >
> > > Since you are forcing RC to work in GEN1, so you will not be able to
> > > connect any device at GEN2 now.
> >
> > I'd rather prefer to know WHY if the RC is operating in Gen2 mode by
> > default, I cannot see the PCIe switch (Pericom PI7C9X2G303) connected to
> > it. I was unable to figure this out. Tim pointed out this thread [1] ,
> > so it might be related in some way.
> >
> > [1] https://community.freescale.com/message/316162#316162
> >
> > I tried switching the PCIe RC to Gen2 operation right after LinkUp by
> > writing this register with 0x2 again and re-issuing the LinkUp check,
> > which passed and the status register reported Gen2 operation, but then
> > the PCIe Intel NIC connected to the downstream port of the Pericom
> > switch still reported Gen1 operation for some reason.
>
> [Richard] Is your Inetl NIC GEN1 EP device?
Yes, the i210 is PCIe v2.1 (2.5GT/s) x1 device.
> > > Yes, There are some buggy PCIe devices which works with GEN1 only host.
> >
> > The pericom one is Gen2 according to it's datasheet.
>
> [Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
> It had been verified on FSL's 3.0.35 releases.
Verified how? What does it mean?
Note that when I followed [1] in this manner:
1) Force GEN1 mode
2) Wait for PHY link up
3) Allow GEN2 mode
4) Start GEN2 speed change
5) Wait for PHY link up
my devices were detected and the link between pericom and mx6 was operating in
gen2 mode. Thus I suspect we might need to start the port in Gen1 mode and
switch to Gen2 only after link is up. Does that make sense?
https://community.freescale.com/thread/304284
> > > So better solution should be to initialize RC by default at GEN2 or
> > > highest speed. Further, a parameter say gen_only can be passed from DT
> > > to force GEN1 only mode.
> > >
> > > What do you say?
> >
> > I say I'd like to know the root cause of this problem. This Gen2 fix was
> > pulled from one of the myriad variants of the FSL PCIe driver, so
> > apparently this issue happens to other people as well. But why and how
> > to properly fix this so the whole PCIe bus does operate in Gen2 mode, I
> > cannot tell :-(
>
> [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases before.
> I don't know why it can't work in GEN2 mode in the latest kernel.
> BTW, Based on for-next branch of shawn's git reops and applied Merak's
> patch-set, my PI7C9X2G303EL with intel e1000e network card plugged can't
> be detected at all. :(.
I think we're still fighting some issue with resource mappings here. We also
agreed with Tim that my patches are incomplete. I will send out a new version
ASAP.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4/6] PCI: imx6: Probe the PCIe in fs_initcall()
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-17 23:31 ` Tim Harvey
-1 siblings, 0 replies; 62+ messages in thread
From: Tim Harvey @ 2013-10-17 23:31 UTC (permalink / raw
To: linux-arm-kernel
On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> Probe the PCIe driver in fs_initcall() instead of module_init()
> to assure that pci_assign_unassigned_resources(); will be called
> early. This function is called in dw_pcie_host_init(), which is
> in turn called from imx6_add_pcie_port(), which is called from
> imx6_pcie_probe() . If this is not called early, we will hit
> resource collisions since pcieport driver is then probed way too
> late.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
> drivers/pci/host/pci-imx6.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 94e4d0f..ca8c5de 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -586,7 +586,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");
> --
> 1.8.4.rc3
>
Acked-by: Tim Harvey <tharvey@gateworks.com>
Tested-by: Tim Harvey <tharvey@gateworks.com>
Tim
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 4/6] PCI: imx6: Probe the PCIe in fs_initcall()
@ 2013-10-17 23:31 ` Tim Harvey
0 siblings, 0 replies; 62+ messages in thread
From: Tim Harvey @ 2013-10-17 23:31 UTC (permalink / raw
To: Marek Vasut
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Bjorn Helgaas, Frank Li, Jingoo Han, Mohit KUMAR, Pratyush Anand,
Richard Zhu, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Troy Kisky, Yinghai Lu
On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> Probe the PCIe driver in fs_initcall() instead of module_init()
> to assure that pci_assign_unassigned_resources(); will be called
> early. This function is called in dw_pcie_host_init(), which is
> in turn called from imx6_add_pcie_port(), which is called from
> imx6_pcie_probe() . If this is not called early, we will hit
> resource collisions since pcieport driver is then probed way too
> late.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Frank Li <lznuaa@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.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: Siva Reddy Kallam <siva.kallam@samsung.com>
> Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Troy Kisky <troy.kisky@boundarydevices.com>
> Cc: Yinghai Lu <yinghai@kernel.org>
> ---
> drivers/pci/host/pci-imx6.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 94e4d0f..ca8c5de 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -586,7 +586,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");
> --
> 1.8.4.rc3
>
Acked-by: Tim Harvey <tharvey@gateworks.com>
Tested-by: Tim Harvey <tharvey@gateworks.com>
Tim
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-17 17:34 ` Marek Vasut
@ 2013-10-18 2:12 ` Zhu Richard-R65037
-1 siblings, 0 replies; 62+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-18 2:12 UTC (permalink / raw
To: linux-arm-kernel
Hi Merak:
Thanks for your great help on the imx6 pcie switch support on the latest kernel fristly.
> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Friday, October 18, 2013 1:35 AM
> To: Zhu Richard-R65037
> Cc: Pratyush Anand; Bjorn Helgaas; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Frank Li; Jingoo Han; Mohit KUMAR DCG; Sascha
> Hauer; Sean Cross; Shawn Guo; Siva Reddy Kallam; Srikanth T Shivanand; Tim
> Harvey; Troy Kisky; Yinghai Lu
> Subject: Re: [PATCH 5/6] PCI: imx6: Force Gen1 operation
>
> Hi Richard,
>
> > Hi Marek:
> > > -----Original Message-----
> >
> > [...]
> >
> > > > > ---
> > > > >
> > > > > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/pci/host/pci-imx6.c
> > > > > b/drivers/pci/host/pci-imx6.c index ca8c5de..8402e9a 100644
> > > > > --- a/drivers/pci/host/pci-imx6.c
> > > > > +++ b/drivers/pci/host/pci-imx6.c
> > > > > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct
> > > > > pcie_port
> > > > > *pp)
> > > > >
> > > > > {
> > > > >
> > > > > int count = 0;
> > > > > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> > > > >
> > > > > + uint32_t tmp;
> > > > >
> > > > > imx6_pcie_assert_core_reset(pp);
> > > > >
> > > > > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct
> > > > > pcie_port
> > > > > *pp)
> > > > >
> > > > > dw_pcie_setup_rc(pp);
> > > > >
> > > > > + /*
> > > > > + * FIXME:
> > > > > + * Force Gen1 operation. In case the IP block is in Gen2
> operation
> > > > > + * mode, it does not detect the PCIe switch at all.
> > > > > + */
> > > > > + tmp = readl(pp->dbi_base + 0x7c);
> > > > > + tmp &= ~0xf;
> > > > > + tmp |= 0x1;
> > > > > + writel(tmp, pp->dbi_base + 0x7c);
> > > > > +
> > > >
> > > > Since you are forcing RC to work in GEN1, so you will not be able
> > > > to connect any device at GEN2 now.
> > >
> > > I'd rather prefer to know WHY if the RC is operating in Gen2 mode by
> > > default, I cannot see the PCIe switch (Pericom PI7C9X2G303)
> > > connected to it. I was unable to figure this out. Tim pointed out
> > > this thread [1] , so it might be related in some way.
> > >
> > > [1] https://community.freescale.com/message/316162#316162
> > >
> > > I tried switching the PCIe RC to Gen2 operation right after LinkUp
> > > by writing this register with 0x2 again and re-issuing the LinkUp
> > > check, which passed and the status register reported Gen2 operation,
> > > but then the PCIe Intel NIC connected to the downstream port of the
> > > Pericom switch still reported Gen1 operation for some reason.
> >
> > [Richard] Is your Inetl NIC GEN1 EP device?
>
> Yes, the i210 is PCIe v2.1 (2.5GT/s) x1 device.
>
> > > > Yes, There are some buggy PCIe devices which works with GEN1 only host.
> > >
> > > The pericom one is Gen2 according to it's datasheet.
> >
> > [Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
> > It had been verified on FSL's 3.0.35 releases.
>
> Verified how? What does it mean?
>
> Note that when I followed [1] in this manner:
>
> 1) Force GEN1 mode
> 2) Wait for PHY link up
> 3) Allow GEN2 mode
> 4) Start GEN2 speed change
> 5) Wait for PHY link up
>
> my devices were detected and the link between pericom and mx6 was operating in
> gen2 mode. Thus I suspect we might need to start the port in Gen1 mode and
> switch to Gen2 only after link is up. Does that make sense?
>
> https://community.freescale.com/thread/304284
>
[Richard] Yes, it make sense regarding to the https://community.freescale.com/thread/304284.
The verification I said above means that the Pericom's PI7C9X2G303EL PCIe GEN2 switch can
work well on 3.0.35 kernel in GEN2 mode(without GEN1 force), and hand been tested by kinds
of PCIe EP device(GEN1: Intel e1000e network card, GEN2 xHCI USB3.0 PCIe x1 card).
Regarding to your comments why FORCE GEN1 mode in RC " Force Gen1 operation. In case the IP block
is in Gen2 operation mode, it does not detect the PCIe switch at all.",
does the gen2 link can be set-up without force gen1 mode?
About the errata mentioned in https://community.freescale.com/thread/304284,
the errata-SW-workaround of initialization is contained in previous Sean Cross' codes, like this.
/*
* 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
*/
> > > > So better solution should be to initialize RC by default at GEN2
> > > > or highest speed. Further, a parameter say gen_only can be passed
> > > > from DT to force GEN1 only mode.
> > > >
> > > > What do you say?
> > >
> > > I say I'd like to know the root cause of this problem. This Gen2 fix
> > > was pulled from one of the myriad variants of the FSL PCIe driver,
> > > so apparently this issue happens to other people as well. But why
> > > and how to properly fix this so the whole PCIe bus does operate in
> > > Gen2 mode, I cannot tell :-(
> >
> > [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases before.
> > I don't know why it can't work in GEN2 mode in the latest kernel.
> > BTW, Based on for-next branch of shawn's git reops and applied Merak's
> > patch-set, my PI7C9X2G303EL with intel e1000e network card plugged
> > can't be detected at all. :(.
>
> I think we're still fighting some issue with resource mappings here. We also
> agreed with Tim that my patches are incomplete. I will send out a new version
> ASAP.
[Richard] What's I said above is just curious that I encounter different phenomena at my side
With the almost same codes.
Thanks again.
Best Regards
Richard Zhu
^ permalink raw reply [flat|nested] 62+ messages in thread
* RE: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-18 2:12 ` Zhu Richard-R65037
0 siblings, 0 replies; 62+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-18 2:12 UTC (permalink / raw
To: Marek Vasut
Cc: Pratyush Anand, Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Frank Li, Jingoo Han,
Mohit KUMAR DCG, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Tim Harvey, Troy Kisky,
Yinghai Lu
Hi Merak:
Thanks for your great help on the imx6 pcie switch support on the latest kernel fristly.
> -----Original Message-----
> From: Marek Vasut [mailto:marex@denx.de]
> Sent: Friday, October 18, 2013 1:35 AM
> To: Zhu Richard-R65037
> Cc: Pratyush Anand; Bjorn Helgaas; linux-pci@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; Frank Li; Jingoo Han; Mohit KUMAR DCG; Sascha
> Hauer; Sean Cross; Shawn Guo; Siva Reddy Kallam; Srikanth T Shivanand; Tim
> Harvey; Troy Kisky; Yinghai Lu
> Subject: Re: [PATCH 5/6] PCI: imx6: Force Gen1 operation
>
> Hi Richard,
>
> > Hi Marek:
> > > -----Original Message-----
> >
> > [...]
> >
> > > > > ---
> > > > >
> > > > > drivers/pci/host/pci-imx6.c | 13 ++++++++++++-
> > > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/pci/host/pci-imx6.c
> > > > > b/drivers/pci/host/pci-imx6.c index ca8c5de..8402e9a 100644
> > > > > --- a/drivers/pci/host/pci-imx6.c
> > > > > +++ b/drivers/pci/host/pci-imx6.c
> > > > > @@ -321,6 +321,7 @@ static void imx6_pcie_host_init(struct
> > > > > pcie_port
> > > > > *pp)
> > > > >
> > > > > {
> > > > >
> > > > > int count = 0;
> > > > > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> > > > >
> > > > > + uint32_t tmp;
> > > > >
> > > > > imx6_pcie_assert_core_reset(pp);
> > > > >
> > > > > @@ -330,13 +331,23 @@ static void imx6_pcie_host_init(struct
> > > > > pcie_port
> > > > > *pp)
> > > > >
> > > > > dw_pcie_setup_rc(pp);
> > > > >
> > > > > + /*
> > > > > + * FIXME:
> > > > > + * Force Gen1 operation. In case the IP block is in Gen2
> operation
> > > > > + * mode, it does not detect the PCIe switch at all.
> > > > > + */
> > > > > + tmp = readl(pp->dbi_base + 0x7c);
> > > > > + tmp &= ~0xf;
> > > > > + tmp |= 0x1;
> > > > > + writel(tmp, pp->dbi_base + 0x7c);
> > > > > +
> > > >
> > > > Since you are forcing RC to work in GEN1, so you will not be able
> > > > to connect any device at GEN2 now.
> > >
> > > I'd rather prefer to know WHY if the RC is operating in Gen2 mode by
> > > default, I cannot see the PCIe switch (Pericom PI7C9X2G303)
> > > connected to it. I was unable to figure this out. Tim pointed out
> > > this thread [1] , so it might be related in some way.
> > >
> > > [1] https://community.freescale.com/message/316162#316162
> > >
> > > I tried switching the PCIe RC to Gen2 operation right after LinkUp
> > > by writing this register with 0x2 again and re-issuing the LinkUp
> > > check, which passed and the status register reported Gen2 operation,
> > > but then the PCIe Intel NIC connected to the downstream port of the
> > > Pericom switch still reported Gen1 operation for some reason.
> >
> > [Richard] Is your Inetl NIC GEN1 EP device?
>
> Yes, the i210 is PCIe v2.1 (2.5GT/s) x1 device.
>
> > > > Yes, There are some buggy PCIe devices which works with GEN1 only host.
> > >
> > > The pericom one is Gen2 according to it's datasheet.
> >
> > [Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
> > It had been verified on FSL's 3.0.35 releases.
>
> Verified how? What does it mean?
>
> Note that when I followed [1] in this manner:
>
> 1) Force GEN1 mode
> 2) Wait for PHY link up
> 3) Allow GEN2 mode
> 4) Start GEN2 speed change
> 5) Wait for PHY link up
>
> my devices were detected and the link between pericom and mx6 was operating in
> gen2 mode. Thus I suspect we might need to start the port in Gen1 mode and
> switch to Gen2 only after link is up. Does that make sense?
>
> https://community.freescale.com/thread/304284
>
[Richard] Yes, it make sense regarding to the https://community.freescale.com/thread/304284.
The verification I said above means that the Pericom's PI7C9X2G303EL PCIe GEN2 switch can
work well on 3.0.35 kernel in GEN2 mode(without GEN1 force), and hand been tested by kinds
of PCIe EP device(GEN1: Intel e1000e network card, GEN2 xHCI USB3.0 PCIe x1 card).
Regarding to your comments why FORCE GEN1 mode in RC " Force Gen1 operation. In case the IP block
is in Gen2 operation mode, it does not detect the PCIe switch at all.",
does the gen2 link can be set-up without force gen1 mode?
About the errata mentioned in https://community.freescale.com/thread/304284,
the errata-SW-workaround of initialization is contained in previous Sean Cross' codes, like this.
/*
* 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
*/
> > > > So better solution should be to initialize RC by default at GEN2
> > > > or highest speed. Further, a parameter say gen_only can be passed
> > > > from DT to force GEN1 only mode.
> > > >
> > > > What do you say?
> > >
> > > I say I'd like to know the root cause of this problem. This Gen2 fix
> > > was pulled from one of the myriad variants of the FSL PCIe driver,
> > > so apparently this issue happens to other people as well. But why
> > > and how to properly fix this so the whole PCIe bus does operate in
> > > Gen2 mode, I cannot tell :-(
> >
> > [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases before.
> > I don't know why it can't work in GEN2 mode in the latest kernel.
> > BTW, Based on for-next branch of shawn's git reops and applied Merak's
> > patch-set, my PI7C9X2G303EL with intel e1000e network card plugged
> > can't be detected at all. :(.
>
> I think we're still fighting some issue with resource mappings here. We also
> agreed with Tim that my patches are incomplete. I will send out a new version
> ASAP.
[Richard] What's I said above is just curious that I encounter different phenomena at my side
With the almost same codes.
Thanks again.
Best Regards
Richard Zhu
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-18 5:04 ` Tim Harvey
-1 siblings, 0 replies; 62+ messages in thread
From: Tim Harvey @ 2013-10-18 5:04 UTC (permalink / raw
To: linux-arm-kernel
On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> Without forcing the PCIe core into Gen1 operation, the PCIe switch
> attached directly to the PCIe port is not recognised at all. The
> PCIe switch is Gen2 capable to make this issue even more puzzling.
>
[...]
>
> 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",
> --
> 1.8.4.rc3
>
Marek,
Can you split this patch out? I found that with the PLX PEX860x PCIe
switches I have on the i.MX6 RC I needed this longer wait for link as
well, but I don't think this is related to gen1/gen2.
Thanks,
Tim
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-18 5:04 ` Tim Harvey
0 siblings, 0 replies; 62+ messages in thread
From: Tim Harvey @ 2013-10-18 5:04 UTC (permalink / raw
To: Marek Vasut
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Bjorn Helgaas, Frank Li, Jingoo Han, Mohit KUMAR, Pratyush Anand,
Richard Zhu, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Troy Kisky, Yinghai Lu
On Tue, Oct 15, 2013 at 9:06 AM, Marek Vasut <marex@denx.de> wrote:
> Without forcing the PCIe core into Gen1 operation, the PCIe switch
> attached directly to the PCIe port is not recognised at all. The
> PCIe switch is Gen2 capable to make this issue even more puzzling.
>
[...]
>
> 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",
> --
> 1.8.4.rc3
>
Marek,
Can you split this patch out? I found that with the PLX PEX860x PCIe
switches I have on the i.MX6 RC I needed this longer wait for link as
well, but I don't think this is related to gen1/gen2.
Thanks,
Tim
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-18 2:12 ` Zhu Richard-R65037
@ 2013-10-19 5:07 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-19 5:07 UTC (permalink / raw
To: linux-arm-kernel
Hi Richard,
> Hi Merak:
> Thanks for your great help on the imx6 pcie switch support on the latest
> kernel fristly.
Let's get this PCIe thing working well :)
[...]
> > > > > Since you are forcing RC to work in GEN1, so you will not be able
> > > > > to connect any device at GEN2 now.
> > > >
> > > > I'd rather prefer to know WHY if the RC is operating in Gen2 mode by
> > > > default, I cannot see the PCIe switch (Pericom PI7C9X2G303)
> > > > connected to it. I was unable to figure this out. Tim pointed out
> > > > this thread [1] , so it might be related in some way.
> > > >
> > > > [1] https://community.freescale.com/message/316162#316162
> > > >
> > > > I tried switching the PCIe RC to Gen2 operation right after LinkUp
> > > > by writing this register with 0x2 again and re-issuing the LinkUp
> > > > check, which passed and the status register reported Gen2 operation,
> > > > but then the PCIe Intel NIC connected to the downstream port of the
> > > > Pericom switch still reported Gen1 operation for some reason.
> > >
> > > [Richard] Is your Inetl NIC GEN1 EP device?
> >
> > Yes, the i210 is PCIe v2.1 (2.5GT/s) x1 device.
> >
> > > > > Yes, There are some buggy PCIe devices which works with GEN1 only
> > > > > host.
> > > >
> > > > The pericom one is Gen2 according to it's datasheet.
> > >
> > > [Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
> > > It had been verified on FSL's 3.0.35 releases.
> >
> > Verified how? What does it mean?
> >
> > Note that when I followed [1] in this manner:
> >
> > 1) Force GEN1 mode
> > 2) Wait for PHY link up
> > 3) Allow GEN2 mode
> > 4) Start GEN2 speed change
> > 5) Wait for PHY link up
> >
> > my devices were detected and the link between pericom and mx6 was
> > operating in gen2 mode. Thus I suspect we might need to start the port
> > in Gen1 mode and switch to Gen2 only after link is up. Does that make
> > sense?
> >
> > https://community.freescale.com/thread/304284
>
> [Richard] Yes, it make sense regarding to the
> https://community.freescale.com/thread/304284.
>
> The verification I said above means that the Pericom's PI7C9X2G303EL PCIe
> GEN2 switch can work well on 3.0.35 kernel in GEN2 mode(without GEN1
> force), and hand been tested by kinds of PCIe EP device(GEN1: Intel e1000e
> network card, GEN2 xHCI USB3.0 PCIe x1 card).
Oh, thanks for verifying this!
> Regarding to your comments why FORCE GEN1 mode in RC " Force Gen1
> operation. In case the IP block is in Gen2 operation mode, it does not
> detect the PCIe switch at all.", does the gen2 link can be set-up without
> force gen1 mode?
What I did in the end for testing purpose was I followed the thread at FSL
community in the link above, forced the link into Gen1 mode , then waited for
link up, then started directed gen2 switch and waited for linkup again. This
worked and the PCIe indicated the link is in Gen2 mode.
Interestingly enough, I also implemented PCIe driver for MX6 for U-Boot (will
submit it shortly to U-Boot ML) and use it with the Intel i210 ethernet NIC now.
When I use the PCIe in U-Boot, I don't need the Force-Gen1 thing above. I
suspect though, that the Gen1 setting is preserved from U-Boot, where I have
this as well.
> About the errata mentioned in
> https://community.freescale.com/thread/304284, the errata-SW-workaround of
> initialization is contained in previous Sean Cross' codes, like this. /*
> * 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
> */
Is this not handling only the PHY part ? Honestly, I'm quite lost in the flurry
of different opinions on the MX6 PCIe. Maybe you as a FSL guy could scrounge
some internal knowledge ?
> > > > > So better solution should be to initialize RC by default at GEN2
> > > > > or highest speed. Further, a parameter say gen_only can be passed
> > > > > from DT to force GEN1 only mode.
> > > > >
> > > > > What do you say?
> > > >
> > > > I say I'd like to know the root cause of this problem. This Gen2 fix
> > > > was pulled from one of the myriad variants of the FSL PCIe driver,
> > > > so apparently this issue happens to other people as well. But why
> > > > and how to properly fix this so the whole PCIe bus does operate in
> > > > Gen2 mode, I cannot tell :-(
> > >
> > > [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases
> > > before. I don't know why it can't work in GEN2 mode in the latest
> > > kernel. BTW, Based on for-next branch of shawn's git reops and applied
> > > Merak's patch-set, my PI7C9X2G303EL with intel e1000e network card
> > > plugged can't be detected at all. :(.
> >
> > I think we're still fighting some issue with resource mappings here. We
> > also agreed with Tim that my patches are incomplete. I will send out a
> > new version ASAP.
>
> [Richard] What's I said above is just curious that I encounter different
> phenomena at my side With the almost same codes.
I talked to Tim about the mappings some more. It seems if the IOspace is
disabled, everything works without hangs. If the IOspace is not disabled on the
ethernet NICs, we get a hang.
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-19 5:07 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-19 5:07 UTC (permalink / raw
To: Zhu Richard-R65037
Cc: Pratyush Anand, Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Frank Li, Jingoo Han,
Mohit KUMAR DCG, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Tim Harvey, Troy Kisky,
Yinghai Lu
Hi Richard,
> Hi Merak:
> Thanks for your great help on the imx6 pcie switch support on the latest
> kernel fristly.
Let's get this PCIe thing working well :)
[...]
> > > > > Since you are forcing RC to work in GEN1, so you will not be able
> > > > > to connect any device at GEN2 now.
> > > >
> > > > I'd rather prefer to know WHY if the RC is operating in Gen2 mode by
> > > > default, I cannot see the PCIe switch (Pericom PI7C9X2G303)
> > > > connected to it. I was unable to figure this out. Tim pointed out
> > > > this thread [1] , so it might be related in some way.
> > > >
> > > > [1] https://community.freescale.com/message/316162#316162
> > > >
> > > > I tried switching the PCIe RC to Gen2 operation right after LinkUp
> > > > by writing this register with 0x2 again and re-issuing the LinkUp
> > > > check, which passed and the status register reported Gen2 operation,
> > > > but then the PCIe Intel NIC connected to the downstream port of the
> > > > Pericom switch still reported Gen1 operation for some reason.
> > >
> > > [Richard] Is your Inetl NIC GEN1 EP device?
> >
> > Yes, the i210 is PCIe v2.1 (2.5GT/s) x1 device.
> >
> > > > > Yes, There are some buggy PCIe devices which works with GEN1 only
> > > > > host.
> > > >
> > > > The pericom one is Gen2 according to it's datasheet.
> > >
> > > [Richard] Yes, it is. Pericom's PI7C9X2G303EL is GEN2 PCIe switch.
> > > It had been verified on FSL's 3.0.35 releases.
> >
> > Verified how? What does it mean?
> >
> > Note that when I followed [1] in this manner:
> >
> > 1) Force GEN1 mode
> > 2) Wait for PHY link up
> > 3) Allow GEN2 mode
> > 4) Start GEN2 speed change
> > 5) Wait for PHY link up
> >
> > my devices were detected and the link between pericom and mx6 was
> > operating in gen2 mode. Thus I suspect we might need to start the port
> > in Gen1 mode and switch to Gen2 only after link is up. Does that make
> > sense?
> >
> > https://community.freescale.com/thread/304284
>
> [Richard] Yes, it make sense regarding to the
> https://community.freescale.com/thread/304284.
>
> The verification I said above means that the Pericom's PI7C9X2G303EL PCIe
> GEN2 switch can work well on 3.0.35 kernel in GEN2 mode(without GEN1
> force), and hand been tested by kinds of PCIe EP device(GEN1: Intel e1000e
> network card, GEN2 xHCI USB3.0 PCIe x1 card).
Oh, thanks for verifying this!
> Regarding to your comments why FORCE GEN1 mode in RC " Force Gen1
> operation. In case the IP block is in Gen2 operation mode, it does not
> detect the PCIe switch at all.", does the gen2 link can be set-up without
> force gen1 mode?
What I did in the end for testing purpose was I followed the thread at FSL
community in the link above, forced the link into Gen1 mode , then waited for
link up, then started directed gen2 switch and waited for linkup again. This
worked and the PCIe indicated the link is in Gen2 mode.
Interestingly enough, I also implemented PCIe driver for MX6 for U-Boot (will
submit it shortly to U-Boot ML) and use it with the Intel i210 ethernet NIC now.
When I use the PCIe in U-Boot, I don't need the Force-Gen1 thing above. I
suspect though, that the Gen1 setting is preserved from U-Boot, where I have
this as well.
> About the errata mentioned in
> https://community.freescale.com/thread/304284, the errata-SW-workaround of
> initialization is contained in previous Sean Cross' codes, like this. /*
> * 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
> */
Is this not handling only the PHY part ? Honestly, I'm quite lost in the flurry
of different opinions on the MX6 PCIe. Maybe you as a FSL guy could scrounge
some internal knowledge ?
> > > > > So better solution should be to initialize RC by default at GEN2
> > > > > or highest speed. Further, a parameter say gen_only can be passed
> > > > > from DT to force GEN1 only mode.
> > > > >
> > > > > What do you say?
> > > >
> > > > I say I'd like to know the root cause of this problem. This Gen2 fix
> > > > was pulled from one of the myriad variants of the FSL PCIe driver,
> > > > so apparently this issue happens to other people as well. But why
> > > > and how to properly fix this so the whole PCIe bus does operate in
> > > > Gen2 mode, I cannot tell :-(
> > >
> > > [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel releases
> > > before. I don't know why it can't work in GEN2 mode in the latest
> > > kernel. BTW, Based on for-next branch of shawn's git reops and applied
> > > Merak's patch-set, my PI7C9X2G303EL with intel e1000e network card
> > > plugged can't be detected at all. :(.
> >
> > I think we're still fighting some issue with resource mappings here. We
> > also agreed with Tim that my patches are incomplete. I will send out a
> > new version ASAP.
>
> [Richard] What's I said above is just curious that I encounter different
> phenomena at my side With the almost same codes.
I talked to Tim about the mappings some more. It seems if the IOspace is
disabled, everything works without hangs. If the IOspace is not disabled on the
ethernet NICs, we get a hang.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 5/6] PCI: imx6: Force Gen1 operation
2013-10-19 5:07 ` Marek Vasut
@ 2013-10-21 6:33 ` Zhu Richard-R65037
-1 siblings, 0 replies; 62+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-21 6:33 UTC (permalink / raw
To: linux-arm-kernel
Hi Merak:
> Hi Richard,
>
> > Hi Merak:
> > Thanks for your great help on the imx6 pcie switch support on the
> > latest kernel fristly.
>
> Let's get this PCIe thing working well :)
>
> [...]
>
>
> > Regarding to your comments why FORCE GEN1 mode in RC " Force Gen1
> > operation. In case the IP block is in Gen2 operation mode, it does not
> > detect the PCIe switch at all.", does the gen2 link can be set-up
> > without force gen1 mode?
>
> What I did in the end for testing purpose was I followed the thread at FSL
> community in the link above, forced the link into Gen1 mode , then waited for
> link up, then started directed gen2 switch and waited for linkup again. This
> worked and the PCIe indicated the link is in Gen2 mode.
>
> Interestingly enough, I also implemented PCIe driver for MX6 for U-Boot (will
> submit it shortly to U-Boot ML) and use it with the Intel i210 ethernet NIC
> now.
> When I use the PCIe in U-Boot, I don't need the Force-Gen1 thing above. I
> suspect though, that the Gen1 setting is preserved from U-Boot, where I have
> this as well.
>
[Richard] It's great, thanks.
> > About the errata mentioned in
> > https://community.freescale.com/thread/304284, the
> > errata-SW-workaround of initialization is contained in previous Sean Cross'
> codes, like this. /*
> > * 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
> > */
>
> Is this not handling only the PHY part ? Honestly, I'm quite lost in the
> flurry of different opinions on the MX6 PCIe. Maybe you as a FSL guy could
> scrounge some internal knowledge ?
>
[Richard] Take it easy, maybe there is a misunderstand between you and me.
It is handling only the PHY part.
The errata "PCIe: Clock pointers can lose sync during clock rate changes",
I mentioned previously is discussed in
(https://community.freescale.com/message/316162#316162) too.
Charies Powe think that the SW workaround contained in FSL BSP is not complete for the errata.
Because I couldn't reproduce this issue at my side, the complete version of the SW workaround
of this errata is not included in the BSP yet.
That's all. Thanks.
> > > > > > So better solution should be to initialize RC by default at
> > > > > > GEN2 or highest speed. Further, a parameter say gen_only can
> > > > > > be passed from DT to force GEN1 only mode.
> > > > > >
> > > > > > What do you say?
> > > > >
> > > > > I say I'd like to know the root cause of this problem. This Gen2
> > > > > fix was pulled from one of the myriad variants of the FSL PCIe
> > > > > driver, so apparently this issue happens to other people as
> > > > > well. But why and how to properly fix this so the whole PCIe bus
> > > > > does operate in
> > > > > Gen2 mode, I cannot tell :-(
> > > >
> > > > [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel
> > > > releases before. I don't know why it can't work in GEN2 mode in
> > > > the latest kernel. BTW, Based on for-next branch of shawn's git
> > > > reops and applied Merak's patch-set, my PI7C9X2G303EL with intel
> > > > e1000e network card plugged can't be detected at all. :(.
> > >
> > > I think we're still fighting some issue with resource mappings here.
> > > We also agreed with Tim that my patches are incomplete. I will send
> > > out a new version ASAP.
> >
> > [Richard] What's I said above is just curious that I encounter
> > different phenomena at my side With the almost same codes.
>
> I talked to Tim about the mappings some more. It seems if the IOspace is
> disabled, everything works without hangs. If the IOspace is not disabled on
> the ethernet NICs, we get a hang.
[Richard] Ok, I see. Thanks.
Best Regards
Richard.
^ permalink raw reply [flat|nested] 62+ messages in thread
* RE: [PATCH 5/6] PCI: imx6: Force Gen1 operation
@ 2013-10-21 6:33 ` Zhu Richard-R65037
0 siblings, 0 replies; 62+ messages in thread
From: Zhu Richard-R65037 @ 2013-10-21 6:33 UTC (permalink / raw
To: Marek Vasut
Cc: Pratyush Anand, Bjorn Helgaas, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Frank Li, Jingoo Han,
Mohit KUMAR DCG, Sascha Hauer, Sean Cross, Shawn Guo,
Siva Reddy Kallam, Srikanth T Shivanand, Tim Harvey, Troy Kisky,
Yinghai Lu
Hi Merak:
> Hi Richard,
>
> > Hi Merak:
> > Thanks for your great help on the imx6 pcie switch support on the
> > latest kernel fristly.
>
> Let's get this PCIe thing working well :)
>
> [...]
>
>
> > Regarding to your comments why FORCE GEN1 mode in RC " Force Gen1
> > operation. In case the IP block is in Gen2 operation mode, it does not
> > detect the PCIe switch at all.", does the gen2 link can be set-up
> > without force gen1 mode?
>
> What I did in the end for testing purpose was I followed the thread at FSL
> community in the link above, forced the link into Gen1 mode , then waited for
> link up, then started directed gen2 switch and waited for linkup again. This
> worked and the PCIe indicated the link is in Gen2 mode.
>
> Interestingly enough, I also implemented PCIe driver for MX6 for U-Boot (will
> submit it shortly to U-Boot ML) and use it with the Intel i210 ethernet NIC
> now.
> When I use the PCIe in U-Boot, I don't need the Force-Gen1 thing above. I
> suspect though, that the Gen1 setting is preserved from U-Boot, where I have
> this as well.
>
[Richard] It's great, thanks.
> > About the errata mentioned in
> > https://community.freescale.com/thread/304284, the
> > errata-SW-workaround of initialization is contained in previous Sean Cross'
> codes, like this. /*
> > * 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
> > */
>
> Is this not handling only the PHY part ? Honestly, I'm quite lost in the
> flurry of different opinions on the MX6 PCIe. Maybe you as a FSL guy could
> scrounge some internal knowledge ?
>
[Richard] Take it easy, maybe there is a misunderstand between you and me.
It is handling only the PHY part.
The errata "PCIe: Clock pointers can lose sync during clock rate changes",
I mentioned previously is discussed in
(https://community.freescale.com/message/316162#316162) too.
Charies Powe think that the SW workaround contained in FSL BSP is not complete for the errata.
Because I couldn't reproduce this issue at my side, the complete version of the SW workaround
of this errata is not included in the BSP yet.
That's all. Thanks.
> > > > > > So better solution should be to initialize RC by default at
> > > > > > GEN2 or highest speed. Further, a parameter say gen_only can
> > > > > > be passed from DT to force GEN1 only mode.
> > > > > >
> > > > > > What do you say?
> > > > >
> > > > > I say I'd like to know the root cause of this problem. This Gen2
> > > > > fix was pulled from one of the myriad variants of the FSL PCIe
> > > > > driver, so apparently this issue happens to other people as
> > > > > well. But why and how to properly fix this so the whole PCIe bus
> > > > > does operate in
> > > > > Gen2 mode, I cannot tell :-(
> > > >
> > > > [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel
> > > > releases before. I don't know why it can't work in GEN2 mode in
> > > > the latest kernel. BTW, Based on for-next branch of shawn's git
> > > > reops and applied Merak's patch-set, my PI7C9X2G303EL with intel
> > > > e1000e network card plugged can't be detected at all. :(.
> > >
> > > I think we're still fighting some issue with resource mappings here.
> > > We also agreed with Tim that my patches are incomplete. I will send
> > > out a new version ASAP.
> >
> > [Richard] What's I said above is just curious that I encounter
> > different phenomena at my side With the almost same codes.
>
> I talked to Tim about the mappings some more. It seems if the IOspace is
> disabled, everything works without hangs. If the IOspace is not disabled on
> the ethernet NICs, we get a hang.
[Richard] Ok, I see. Thanks.
Best Regards
Richard.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-15 16:06 ` Marek Vasut
@ 2013-10-29 19:14 ` Bjorn Helgaas
-1 siblings, 0 replies; 62+ messages in thread
From: Bjorn Helgaas @ 2013-10-29 19:14 UTC (permalink / raw
To: linux-arm-kernel
On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
> Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
>
> NOTE: I'm sure this will start some discussion. There are quite a few patches
> that are more of a hacks. Shawn, I didn't ignore your remark about the
> clock patches, I will test it ASAP, I just want to have these fixes in
> the public so others can comment/test.
>
> Marek Vasut (6):
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Fix the clock for PCIe
> ARM: dts: imx6qdl: Fix the clock for PCIe
> PCI: imx6: Probe the PCIe in fs_initcall()
> PCI: imx6: Force Gen1 operation
> PCI: designware: Fix DT resource retrieval
>
> .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> drivers/pci/host/pci-imx6.c | 63 ++++++++++++++++------
> drivers/pci/host/pcie-designware.c | 17 +++---
> 4 files changed, 55 insertions(+), 31 deletions(-)
I'm ignoring this series for now. I assume you'll post an updated
series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
Force Gen1 operation." Please mark that series as "v2" when you post
it. My assumption is still that Shawn Guo will ack the
drivers/pci/host/ pieces before I apply them [1].
Bjorn
[1] http://marc.info/?l=linux-pci&m=138030833011687&w=2
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-29 19:14 ` Bjorn Helgaas
0 siblings, 0 replies; 62+ messages in thread
From: Bjorn Helgaas @ 2013-10-29 19:14 UTC (permalink / raw
To: Marek Vasut
Cc: linux-pci@vger.kernel.org, linux-arm, Frank Li, Jingoo Han,
Mohit KUMAR, Pratyush Anand, Richard Zhu, Sascha Hauer,
Sean Cross, Shawn Guo, Siva Reddy Kallam, Srikanth T Shivanand,
Tim Harvey, Troy Kisky, Yinghai Lu
On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
> Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as expected.
>
> NOTE: I'm sure this will start some discussion. There are quite a few patches
> that are more of a hacks. Shawn, I didn't ignore your remark about the
> clock patches, I will test it ASAP, I just want to have these fixes in
> the public so others can comment/test.
>
> Marek Vasut (6):
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Fix the clock for PCIe
> ARM: dts: imx6qdl: Fix the clock for PCIe
> PCI: imx6: Probe the PCIe in fs_initcall()
> PCI: imx6: Force Gen1 operation
> PCI: designware: Fix DT resource retrieval
>
> .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> drivers/pci/host/pci-imx6.c | 63 ++++++++++++++++------
> drivers/pci/host/pcie-designware.c | 17 +++---
> 4 files changed, 55 insertions(+), 31 deletions(-)
I'm ignoring this series for now. I assume you'll post an updated
series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
Force Gen1 operation." Please mark that series as "v2" when you post
it. My assumption is still that Shawn Guo will ack the
drivers/pci/host/ pieces before I apply them [1].
Bjorn
[1] http://marc.info/?l=linux-pci&m=138030833011687&w=2
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-29 19:14 ` Bjorn Helgaas
@ 2013-10-30 14:52 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-30 14:52 UTC (permalink / raw
To: linux-arm-kernel
Dear Bjorn Helgaas,
> On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
> > expected.
> >
> > NOTE: I'm sure this will start some discussion. There are quite a few
> > patches
> >
> > that are more of a hacks. Shawn, I didn't ignore your remark about
> > the clock patches, I will test it ASAP, I just want to have these
> > fixes in the public so others can comment/test.
> >
> > Marek Vasut (6):
> > PCI: imx6: Make reset-gpio optional
> > PCI: imx6: Fix the clock for PCIe
> > ARM: dts: imx6qdl: Fix the clock for PCIe
> > PCI: imx6: Probe the PCIe in fs_initcall()
> > PCI: imx6: Force Gen1 operation
> > PCI: designware: Fix DT resource retrieval
> >
> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> > drivers/pci/host/pci-imx6.c | 63
> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
> > | 17 +++---
> > 4 files changed, 55 insertions(+), 31 deletions(-)
>
> I'm ignoring this series for now. I assume you'll post an updated
> series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
> Force Gen1 operation." Please mark that series as "v2" when you post
> it. My assumption is still that Shawn Guo will ack the
> drivers/pci/host/ pieces before I apply them [1].
Can you maybe pick at least these two:
PCI: imx6: Make reset-gpio optional
PCI: imx6: Probe the PCIe in fs_initcall()
I think they should be harmless and the later one fixes a problem on MX6. I'm
now digging in the PCIe MX6 again btw.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-30 14:52 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-10-30 14:52 UTC (permalink / raw
To: Bjorn Helgaas
Cc: linux-pci@vger.kernel.org, linux-arm, Frank Li, Jingoo Han,
Mohit KUMAR, Pratyush Anand, Richard Zhu, Sascha Hauer,
Sean Cross, Shawn Guo, Siva Reddy Kallam, Srikanth T Shivanand,
Tim Harvey, Troy Kisky, Yinghai Lu
Dear Bjorn Helgaas,
> On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
> > expected.
> >
> > NOTE: I'm sure this will start some discussion. There are quite a few
> > patches
> >
> > that are more of a hacks. Shawn, I didn't ignore your remark about
> > the clock patches, I will test it ASAP, I just want to have these
> > fixes in the public so others can comment/test.
> >
> > Marek Vasut (6):
> > PCI: imx6: Make reset-gpio optional
> > PCI: imx6: Fix the clock for PCIe
> > ARM: dts: imx6qdl: Fix the clock for PCIe
> > PCI: imx6: Probe the PCIe in fs_initcall()
> > PCI: imx6: Force Gen1 operation
> > PCI: designware: Fix DT resource retrieval
> >
> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
> > drivers/pci/host/pci-imx6.c | 63
> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
> > | 17 +++---
> > 4 files changed, 55 insertions(+), 31 deletions(-)
>
> I'm ignoring this series for now. I assume you'll post an updated
> series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
> Force Gen1 operation." Please mark that series as "v2" when you post
> it. My assumption is still that Shawn Guo will ack the
> drivers/pci/host/ pieces before I apply them [1].
Can you maybe pick at least these two:
PCI: imx6: Make reset-gpio optional
PCI: imx6: Probe the PCIe in fs_initcall()
I think they should be harmless and the later one fixes a problem on MX6. I'm
now digging in the PCIe MX6 again btw.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-30 14:52 ` Marek Vasut
@ 2013-10-30 16:25 ` Bjorn Helgaas
-1 siblings, 0 replies; 62+ messages in thread
From: Bjorn Helgaas @ 2013-10-30 16:25 UTC (permalink / raw
To: linux-arm-kernel
On Wed, Oct 30, 2013 at 8:52 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Bjorn Helgaas,
>
>> On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
>> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
>> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
>> > expected.
>> >
>> > NOTE: I'm sure this will start some discussion. There are quite a few
>> > patches
>> >
>> > that are more of a hacks. Shawn, I didn't ignore your remark about
>> > the clock patches, I will test it ASAP, I just want to have these
>> > fixes in the public so others can comment/test.
>> >
>> > Marek Vasut (6):
>> > PCI: imx6: Make reset-gpio optional
>> > PCI: imx6: Fix the clock for PCIe
>> > ARM: dts: imx6qdl: Fix the clock for PCIe
>> > PCI: imx6: Probe the PCIe in fs_initcall()
>> > PCI: imx6: Force Gen1 operation
>> > PCI: designware: Fix DT resource retrieval
>> >
>> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
>> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
>> > drivers/pci/host/pci-imx6.c | 63
>> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
>> > | 17 +++---
>> > 4 files changed, 55 insertions(+), 31 deletions(-)
>>
>> I'm ignoring this series for now. I assume you'll post an updated
>> series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
>> Force Gen1 operation." Please mark that series as "v2" when you post
>> it. My assumption is still that Shawn Guo will ack the
>> drivers/pci/host/ pieces before I apply them [1].
>
> Can you maybe pick at least these two:
>
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Probe the PCIe in fs_initcall()
>
> I think they should be harmless and the later one fixes a problem on MX6. I'm
> now digging in the PCIe MX6 again btw.
I'm fine with taking these as long as Shawn acks them.
Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-30 16:25 ` Bjorn Helgaas
0 siblings, 0 replies; 62+ messages in thread
From: Bjorn Helgaas @ 2013-10-30 16:25 UTC (permalink / raw
To: Marek Vasut
Cc: linux-pci@vger.kernel.org, linux-arm, Frank Li, Jingoo Han,
Mohit KUMAR, Pratyush Anand, Richard Zhu, Sascha Hauer,
Sean Cross, Shawn Guo, Siva Reddy Kallam, Srikanth T Shivanand,
Tim Harvey, Troy Kisky, Yinghai Lu
On Wed, Oct 30, 2013 at 8:52 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Bjorn Helgaas,
>
>> On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
>> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
>> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
>> > expected.
>> >
>> > NOTE: I'm sure this will start some discussion. There are quite a few
>> > patches
>> >
>> > that are more of a hacks. Shawn, I didn't ignore your remark about
>> > the clock patches, I will test it ASAP, I just want to have these
>> > fixes in the public so others can comment/test.
>> >
>> > Marek Vasut (6):
>> > PCI: imx6: Make reset-gpio optional
>> > PCI: imx6: Fix the clock for PCIe
>> > ARM: dts: imx6qdl: Fix the clock for PCIe
>> > PCI: imx6: Probe the PCIe in fs_initcall()
>> > PCI: imx6: Force Gen1 operation
>> > PCI: designware: Fix DT resource retrieval
>> >
>> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
>> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
>> > drivers/pci/host/pci-imx6.c | 63
>> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
>> > | 17 +++---
>> > 4 files changed, 55 insertions(+), 31 deletions(-)
>>
>> I'm ignoring this series for now. I assume you'll post an updated
>> series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
>> Force Gen1 operation." Please mark that series as "v2" when you post
>> it. My assumption is still that Shawn Guo will ack the
>> drivers/pci/host/ pieces before I apply them [1].
>
> Can you maybe pick at least these two:
>
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Probe the PCIe in fs_initcall()
>
> I think they should be harmless and the later one fixes a problem on MX6. I'm
> now digging in the PCIe MX6 again btw.
I'm fine with taking these as long as Shawn acks them.
Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-30 16:25 ` Bjorn Helgaas
@ 2013-10-31 1:26 ` Shawn Guo
-1 siblings, 0 replies; 62+ messages in thread
From: Shawn Guo @ 2013-10-31 1:26 UTC (permalink / raw
To: linux-arm-kernel
On Wed, Oct 30, 2013 at 10:25:37AM -0600, Bjorn Helgaas wrote:
> > Can you maybe pick at least these two:
> >
> > PCI: imx6: Make reset-gpio optional
Isn't there a comment from Jingoo on this patch unresolved?
> > PCI: imx6: Probe the PCIe in fs_initcall()
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> >
> > I think they should be harmless and the later one fixes a problem on MX6. I'm
> > now digging in the PCIe MX6 again btw.
>
> I'm fine with taking these as long as Shawn acks them.
>
> Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-31 1:26 ` Shawn Guo
0 siblings, 0 replies; 62+ messages in thread
From: Shawn Guo @ 2013-10-31 1:26 UTC (permalink / raw
To: Bjorn Helgaas
Cc: Marek Vasut, linux-pci@vger.kernel.org, linux-arm, Frank Li,
Jingoo Han, Mohit KUMAR, Pratyush Anand, Richard Zhu,
Sascha Hauer, Sean Cross, Siva Reddy Kallam, Srikanth T Shivanand,
Tim Harvey, Troy Kisky, Yinghai Lu
On Wed, Oct 30, 2013 at 10:25:37AM -0600, Bjorn Helgaas wrote:
> > Can you maybe pick at least these two:
> >
> > PCI: imx6: Make reset-gpio optional
Isn't there a comment from Jingoo on this patch unresolved?
> > PCI: imx6: Probe the PCIe in fs_initcall()
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> >
> > I think they should be harmless and the later one fixes a problem on MX6. I'm
> > now digging in the PCIe MX6 again btw.
>
> I'm fine with taking these as long as Shawn acks them.
>
> Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-31 1:26 ` Shawn Guo
@ 2013-10-31 1:38 ` Jingoo Han
-1 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-31 1:38 UTC (permalink / raw
To: linux-arm-kernel
On Thursday, October 31, 2013 10:26 AM, Shawn Guo wrote:
> On Wed, Oct 30, 2013 at 10:25:37AM -0600, Bjorn Helgaas wrote:
> > > Can you maybe pick at least these two:
> > >
> > > PCI: imx6: Make reset-gpio optional
>
> Isn't there a comment from Jingoo on this patch unresolved?
(+cc Kishon Vijay Abraham I)
Oh, right.
Please fix the Documentation part as below.
: http://www.spinics.net/lists/linux-pci/msg25951.html
>
> > > PCI: imx6: Probe the PCIe in fs_initcall()
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
> > >
> > > I think they should be harmless and the later one fixes a problem on MX6. I'm
> > > now digging in the PCIe MX6 again btw.
> >
> > I'm fine with taking these as long as Shawn acks them.
> >
> > Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-31 1:38 ` Jingoo Han
0 siblings, 0 replies; 62+ messages in thread
From: Jingoo Han @ 2013-10-31 1:38 UTC (permalink / raw
To: 'Shawn Guo', 'Bjorn Helgaas'
Cc: 'Marek Vasut', linux-pci, 'linux-arm',
'Frank Li', 'Mohit KUMAR',
'Pratyush Anand', 'Richard Zhu',
'Sascha Hauer', 'Sean Cross',
'Siva Reddy Kallam', 'Srikanth T Shivanand',
'Tim Harvey', 'Troy Kisky', 'Yinghai Lu',
'Kishon Vijay Abraham I', 'Jingoo Han'
On Thursday, October 31, 2013 10:26 AM, Shawn Guo wrote:
> On Wed, Oct 30, 2013 at 10:25:37AM -0600, Bjorn Helgaas wrote:
> > > Can you maybe pick at least these two:
> > >
> > > PCI: imx6: Make reset-gpio optional
>
> Isn't there a comment from Jingoo on this patch unresolved?
(+cc Kishon Vijay Abraham I)
Oh, right.
Please fix the Documentation part as below.
: http://www.spinics.net/lists/linux-pci/msg25951.html
>
> > > PCI: imx6: Probe the PCIe in fs_initcall()
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
> > >
> > > I think they should be harmless and the later one fixes a problem on MX6. I'm
> > > now digging in the PCIe MX6 again btw.
> >
> > I'm fine with taking these as long as Shawn acks them.
> >
> > Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-30 14:52 ` Marek Vasut
@ 2013-10-31 17:36 ` Bjorn Helgaas
-1 siblings, 0 replies; 62+ messages in thread
From: Bjorn Helgaas @ 2013-10-31 17:36 UTC (permalink / raw
To: linux-arm-kernel
On Wed, Oct 30, 2013 at 8:52 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Bjorn Helgaas,
>
>> On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
>> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
>> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
>> > expected.
>> >
>> > NOTE: I'm sure this will start some discussion. There are quite a few
>> > patches
>> >
>> > that are more of a hacks. Shawn, I didn't ignore your remark about
>> > the clock patches, I will test it ASAP, I just want to have these
>> > fixes in the public so others can comment/test.
>> >
>> > Marek Vasut (6):
>> > PCI: imx6: Make reset-gpio optional
>> > PCI: imx6: Fix the clock for PCIe
>> > ARM: dts: imx6qdl: Fix the clock for PCIe
>> > PCI: imx6: Probe the PCIe in fs_initcall()
>> > PCI: imx6: Force Gen1 operation
>> > PCI: designware: Fix DT resource retrieval
>> >
>> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
>> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
>> > drivers/pci/host/pci-imx6.c | 63
>> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
>> > | 17 +++---
>> > 4 files changed, 55 insertions(+), 31 deletions(-)
>>
>> I'm ignoring this series for now. I assume you'll post an updated
>> series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
>> Force Gen1 operation." Please mark that series as "v2" when you post
>> it. My assumption is still that Shawn Guo will ack the
>> drivers/pci/host/ pieces before I apply them [1].
>
> Can you maybe pick at least these two:
>
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Probe the PCIe in fs_initcall()
Applied "Probe the PCIe in fs_initcall()" with Shawn's ack to my
pci/host-imx6 branch for v3.13, thanks.
Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-10-31 17:36 ` Bjorn Helgaas
0 siblings, 0 replies; 62+ messages in thread
From: Bjorn Helgaas @ 2013-10-31 17:36 UTC (permalink / raw
To: Marek Vasut
Cc: linux-pci@vger.kernel.org, linux-arm, Frank Li, Jingoo Han,
Mohit KUMAR, Pratyush Anand, Richard Zhu, Sascha Hauer,
Sean Cross, Shawn Guo, Siva Reddy Kallam, Srikanth T Shivanand,
Tim Harvey, Troy Kisky, Yinghai Lu
On Wed, Oct 30, 2013 at 8:52 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Bjorn Helgaas,
>
>> On Tue, Oct 15, 2013 at 10:06 AM, Marek Vasut <marex@denx.de> wrote:
>> > Set of random fixes for the PCIe driver for i.MX6 . With these fixes, my
>> > setup with MX6Q -> PCIe bridge -> i210 ethernet adapter works as
>> > expected.
>> >
>> > NOTE: I'm sure this will start some discussion. There are quite a few
>> > patches
>> >
>> > that are more of a hacks. Shawn, I didn't ignore your remark about
>> > the clock patches, I will test it ASAP, I just want to have these
>> > fixes in the public so others can comment/test.
>> >
>> > Marek Vasut (6):
>> > PCI: imx6: Make reset-gpio optional
>> > PCI: imx6: Fix the clock for PCIe
>> > ARM: dts: imx6qdl: Fix the clock for PCIe
>> > PCI: imx6: Probe the PCIe in fs_initcall()
>> > PCI: imx6: Force Gen1 operation
>> > PCI: designware: Fix DT resource retrieval
>> >
>> > .../devicetree/bindings/pci/designware-pcie.txt | 2 +-
>> > arch/arm/boot/dts/imx6qdl.dtsi | 4 +-
>> > drivers/pci/host/pci-imx6.c | 63
>> > ++++++++++++++++------ drivers/pci/host/pcie-designware.c
>> > | 17 +++---
>> > 4 files changed, 55 insertions(+), 31 deletions(-)
>>
>> I'm ignoring this series for now. I assume you'll post an updated
>> series as mentioned in your Oct 17 response to "[Patch 5/6] PCI: imx6:
>> Force Gen1 operation." Please mark that series as "v2" when you post
>> it. My assumption is still that Shawn Guo will ack the
>> drivers/pci/host/ pieces before I apply them [1].
>
> Can you maybe pick at least these two:
>
> PCI: imx6: Make reset-gpio optional
> PCI: imx6: Probe the PCIe in fs_initcall()
Applied "Probe the PCIe in fs_initcall()" with Shawn's ack to my
pci/host-imx6 branch for v3.13, thanks.
Bjorn
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-10-15 16:06 ` Marek Vasut
@ 2013-11-11 13:32 ` Jürgen Beisert
-1 siblings, 0 replies; 62+ messages in thread
From: Jürgen Beisert @ 2013-11-11 13:32 UTC (permalink / raw
To: linux-arm-kernel
Hi,
I'm also trying to get the PCIe to work on an i.MX6. But the attached device
cannot be enabled. The external device is an FPGA directly connected to the
i.MX6. I'm using the changes from linux-next to get the machine working up
to this point. But it seems I still miss something.
What I see is:
[...]
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: [1172:0004] type 00 class 0x000000
pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff]
pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x5c
pci_bus 0000:01: fixups for bus
PCI: bus1: Fast back to back transfers disabled
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 0000:00:00.0: fixup irq: got 155
pci 0000:00:00.0: assigning IRQ 155
pci 0000:01:00.0: fixup irq: got 155
pci 0000:01: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-0x10fffff])
pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
pci_bus 0000:00: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
pci_bus 0000:00: resource 4 [io 0x1000-0x10000]
pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
pci_bus 0000:01: resource 1 [mem 0x01100000-0x011fffff]
[...]
pcieport 0000:00:00.0: Resource 0: from 1000000 to 10FFFFF <- my message from pcibios_enable_device()/arch/arm/kernel/bios32.c
[...]
FPGA 0000:01:00.0: Dummy FPGA driver starts probing
FPGA 0000:01:00.0: Resource 0: from 0 to FFFF <- my message from pcibios_enable_device()/arch/arm/kernel/bios32.c
PCI: Device 0000:01:00.0 not available because of resource collisions
FPGA 000:01:00.0: Cannot enable PCIe device, aborting
FPGA: probe of 0000:01:00.0 failed with error -5
pcibios_enable_device() fails due to the start address of this device is
still 0.
Accesses to the configuration space are working. Here the output:
root@platform:~ lspci -vv
00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Region 0: Memory@01000000 (32-bit, non-prefetchable) [size=1M]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: 01100000-011fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
[virtual] Expansion ROM@01200000 [disabled] [size=64K]
BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable+
Address: 0000000090000000 Data: 0000
Masking: 00000001 Pending: 00000000
Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 unlimited
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140] Virtual Channel <?>
Kernel driver in use: pcieport
01:00.0 Non-VGA unclassified device: Altera Corporation Device 0004 (rev 01)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 155
Capabilities: [50] MSI: Mask- 64bit+ Count=1/1 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM unknown, Latency L0 <4us, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100] Virtual Channel <?>
Capabilities: [200] Vendor Specific Information <?>
Any idea what is missing?
Regards,
Juergen
--
Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Juergen Beisert ? ? ? ? ? ? |
Linux Solutions for Science and Industry ? ? ?| http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-11-11 13:32 ` Jürgen Beisert
0 siblings, 0 replies; 62+ messages in thread
From: Jürgen Beisert @ 2013-11-11 13:32 UTC (permalink / raw
To: linux-arm-kernel; +Cc: Marek Vasut, linux-pci
Hi,
I'm also trying to get the PCIe to work on an i.MX6. But the attached device
cannot be enabled. The external device is an FPGA directly connected to the
i.MX6. I'm using the changes from linux-next to get the machine working up
to this point. But it seems I still miss something.
What I see is:
[...]
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: [1172:0004] type 00 class 0x000000
pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff]
pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x5c
pci_bus 0000:01: fixups for bus
PCI: bus1: Fast back to back transfers disabled
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 0000:00:00.0: fixup irq: got 155
pci 0000:00:00.0: assigning IRQ 155
pci 0000:01:00.0: fixup irq: got 155
pci 0000:01: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-0x10fffff])
pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
pci_bus 0000:00: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
pci_bus 0000:00: resource 4 [io 0x1000-0x10000]
pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
pci_bus 0000:01: resource 1 [mem 0x01100000-0x011fffff]
[...]
pcieport 0000:00:00.0: Resource 0: from 1000000 to 10FFFFF <- my message from pcibios_enable_device()/arch/arm/kernel/bios32.c
[...]
FPGA 0000:01:00.0: Dummy FPGA driver starts probing
FPGA 0000:01:00.0: Resource 0: from 0 to FFFF <- my message from pcibios_enable_device()/arch/arm/kernel/bios32.c
PCI: Device 0000:01:00.0 not available because of resource collisions
FPGA 000:01:00.0: Cannot enable PCIe device, aborting
FPGA: probe of 0000:01:00.0 failed with error -5
pcibios_enable_device() fails due to the start address of this device is
still 0.
Accesses to the configuration space are working. Here the output:
root@platform:~ lspci -vv
00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Region 0: Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: 01100000-011fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
[virtual] Expansion ROM at 01200000 [disabled] [size=64K]
BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable+
Address: 0000000090000000 Data: 0000
Masking: 00000001 Pending: 00000000
Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 unlimited
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140] Virtual Channel <?>
Kernel driver in use: pcieport
01:00.0 Non-VGA unclassified device: Altera Corporation Device 0004 (rev 01)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 155
Capabilities: [50] MSI: Mask- 64bit+ Count=1/1 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM unknown, Latency L0 <4us, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100] Virtual Channel <?>
Capabilities: [200] Vendor Specific Information <?>
Any idea what is missing?
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 0/6] PCI: imx6: Random fixes
2013-11-11 13:32 ` Jürgen Beisert
@ 2013-11-11 13:48 ` Marek Vasut
-1 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-11-11 13:48 UTC (permalink / raw
To: linux-arm-kernel
Dear J?rgen Beisert,
> Hi,
>
> I'm also trying to get the PCIe to work on an i.MX6. But the attached
> device cannot be enabled. The external device is an FPGA directly
> connected to the i.MX6. I'm using the changes from linux-next to get the
> machine working up to this point. But it seems I still miss something.
>
> What I see is:
>
> [...]
> 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: [1172:0004] type 00 class 0x000000
> pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff]
> pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x5c
> pci_bus 0000:01: fixups for bus
> PCI: bus1: Fast back to back transfers disabled
> 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 0000:00:00.0: fixup irq: got 155
> pci 0000:00:00.0: assigning IRQ 155
> pci 0000:01:00.0: fixup irq: got 155
> pci 0000:01: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-0x10fffff]) pci 0000:00:00.0: BAR 8: assigned [mem
> 0x01100000-0x011fffff]
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci_bus 0000:00: max bus depth: 1 pci_try_num: 2
> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci_bus 0000:00: resource 4 [io 0x1000-0x10000]
> pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
> pci_bus 0000:01: resource 1 [mem 0x01100000-0x011fffff]
> [...]
> pcieport 0000:00:00.0: Resource 0: from 1000000 to 10FFFFF <- my message
> from pcibios_enable_device()/arch/arm/kernel/bios32.c [...]
> FPGA 0000:01:00.0: Dummy FPGA driver starts probing
> FPGA 0000:01:00.0: Resource 0: from 0 to FFFF <- my message from
> pcibios_enable_device()/arch/arm/kernel/bios32.c PCI: Device 0000:01:00.0
> not available because of resource collisions FPGA 000:01:00.0: Cannot
> enable PCIe device, aborting
> FPGA: probe of 0000:01:00.0 failed with error -5
>
> pcibios_enable_device() fails due to the start address of this device is
> still 0.
Looks like your device isn't assigned it's memory windows for some reason. There
is a discussion going on about DWC PCIe and how the iATU configuration is wrong
and how to fix it in the PCI ML. I'd check that.
btw. do you need to switch the bus to Gen1 to get it to probe your device?
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 0/6] PCI: imx6: Random fixes
@ 2013-11-11 13:48 ` Marek Vasut
0 siblings, 0 replies; 62+ messages in thread
From: Marek Vasut @ 2013-11-11 13:48 UTC (permalink / raw
To: Jürgen Beisert; +Cc: linux-arm-kernel, linux-pci
Dear Jürgen Beisert,
> Hi,
>
> I'm also trying to get the PCIe to work on an i.MX6. But the attached
> device cannot be enabled. The external device is an FPGA directly
> connected to the i.MX6. I'm using the changes from linux-next to get the
> machine working up to this point. But it seems I still miss something.
>
> What I see is:
>
> [...]
> 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: [1172:0004] type 00 class 0x000000
> pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0000ffff]
> pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x5c
> pci_bus 0000:01: fixups for bus
> PCI: bus1: Fast back to back transfers disabled
> 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 0000:00:00.0: fixup irq: got 155
> pci 0000:00:00.0: assigning IRQ 155
> pci 0000:01:00.0: fixup irq: got 155
> pci 0000:01: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-0x10fffff]) pci 0000:00:00.0: BAR 8: assigned [mem
> 0x01100000-0x011fffff]
> pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci_bus 0000:00: max bus depth: 1 pci_try_num: 2
> pci 0000:00:00.0: PCI bridge to [bus 01]
> pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff]
> pci_bus 0000:00: resource 4 [io 0x1000-0x10000]
> pci_bus 0000:00: resource 5 [mem 0x01000000-0x01efffff]
> pci_bus 0000:01: resource 1 [mem 0x01100000-0x011fffff]
> [...]
> pcieport 0000:00:00.0: Resource 0: from 1000000 to 10FFFFF <- my message
> from pcibios_enable_device()/arch/arm/kernel/bios32.c [...]
> FPGA 0000:01:00.0: Dummy FPGA driver starts probing
> FPGA 0000:01:00.0: Resource 0: from 0 to FFFF <- my message from
> pcibios_enable_device()/arch/arm/kernel/bios32.c PCI: Device 0000:01:00.0
> not available because of resource collisions FPGA 000:01:00.0: Cannot
> enable PCIe device, aborting
> FPGA: probe of 0000:01:00.0 failed with error -5
>
> pcibios_enable_device() fails due to the start address of this device is
> still 0.
Looks like your device isn't assigned it's memory windows for some reason. There
is a discussion going on about DWC PCIe and how the iATU configuration is wrong
and how to fix it in the PCI ML. I'd check that.
btw. do you need to switch the bus to Gen1 to get it to probe your device?
^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~2013-11-11 13:48 UTC | newest]
Thread overview: 62+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-15 16:06 [PATCH 0/6] PCI: imx6: Random fixes Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-15 16:06 ` [PATCH 1/6] PCI: imx6: Make reset-gpio optional Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-16 1:24 ` Jingoo Han
2013-10-16 1:24 ` Jingoo Han
2013-10-15 16:06 ` [PATCH 2/6] PCI: imx6: Fix the clock for PCIe Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-15 16:06 ` [PATCH 3/6] ARM: dts: imx6qdl: " Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-15 16:06 ` [PATCH 4/6] PCI: imx6: Probe the PCIe in fs_initcall() Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-17 23:31 ` Tim Harvey
2013-10-17 23:31 ` Tim Harvey
2013-10-15 16:06 ` [PATCH 5/6] PCI: imx6: Force Gen1 operation Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-16 5:54 ` Pratyush Anand
2013-10-16 5:54 ` Pratyush Anand
2013-10-16 13:57 ` Marek Vasut
2013-10-16 13:57 ` Marek Vasut
2013-10-17 7:02 ` Zhu Richard-R65037
2013-10-17 7:02 ` Zhu Richard-R65037
2013-10-17 17:34 ` Marek Vasut
2013-10-17 17:34 ` Marek Vasut
2013-10-18 2:12 ` Zhu Richard-R65037
2013-10-18 2:12 ` Zhu Richard-R65037
2013-10-19 5:07 ` Marek Vasut
2013-10-19 5:07 ` Marek Vasut
2013-10-21 6:33 ` Zhu Richard-R65037
2013-10-21 6:33 ` Zhu Richard-R65037
2013-10-18 5:04 ` Tim Harvey
2013-10-18 5:04 ` Tim Harvey
2013-10-15 16:06 ` [PATCH 6/6] PCI: designware: Fix DT resource retrieval Marek Vasut
2013-10-15 16:06 ` Marek Vasut
2013-10-16 0:15 ` Tim Harvey
2013-10-16 0:15 ` Tim Harvey
2013-10-16 3:56 ` Jingoo Han
2013-10-16 3:56 ` Jingoo Han
2013-10-16 14:05 ` Marek Vasut
2013-10-16 14:05 ` Marek Vasut
2013-10-15 16:34 ` [PATCH 0/6] PCI: imx6: Random fixes Marek Vasut
2013-10-15 16:34 ` Marek Vasut
2013-10-16 0:03 ` Jingoo Han
2013-10-16 0:03 ` Jingoo Han
2013-10-16 0:08 ` Marek Vasut
2013-10-16 0:08 ` Marek Vasut
2013-10-29 19:14 ` Bjorn Helgaas
2013-10-29 19:14 ` Bjorn Helgaas
2013-10-30 14:52 ` Marek Vasut
2013-10-30 14:52 ` Marek Vasut
2013-10-30 16:25 ` Bjorn Helgaas
2013-10-30 16:25 ` Bjorn Helgaas
2013-10-31 1:26 ` Shawn Guo
2013-10-31 1:26 ` Shawn Guo
2013-10-31 1:38 ` Jingoo Han
2013-10-31 1:38 ` Jingoo Han
2013-10-31 17:36 ` Bjorn Helgaas
2013-10-31 17:36 ` Bjorn Helgaas
2013-11-11 13:32 ` Jürgen Beisert
2013-11-11 13:32 ` Jürgen Beisert
2013-11-11 13:48 ` Marek Vasut
2013-11-11 13:48 ` Marek Vasut
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.