diff mbox

[RFC] PCI: pci-imx6: Add delay to workaround kernel hang

Message ID 1405675599.6072.8.camel@weser.hi.pengutronix.de (mailing list archive)
State New, archived
Headers show

Commit Message

Lucas Stach July 18, 2014, 9:26 a.m. UTC 
Hi Tim,

Am Donnerstag, den 26.06.2014, 17:29 -0700 schrieb Tim Harvey:
[...]
> Shawn / Richard,
> 
> I am also affected by this issue on IMX6 boards that I support. If I
> enable PCI in the bootloader I see similar hangs.
> 
> I have the following hardware configurations on my bench:
>   1. IMX6DL + i210 (same PCI setup as Fabio's above, but DL instead of Q)
>   2. IMX6Q + ath9k device
>   3. IMX6DL + PLX PEX860x PCIe-to-PCIe bridge with various devices
> behind the bridge, using a clock buffer from IMX6 PCIe clock
>   4. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> behind the bridge, using a clock buffer from IMX6 PCIe clock
>   5. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> behind the bridge using a clock generator (always on, ignoring the
> PCIe clock)
> 
> For all of the above I have no PCI issues using
> 3.14/3.15/3.16-rc2/vendor 3.10.17_1.0.0_ga unless I enable PCI in the
> bootloader. When I do so, all of the above configurations hang
> somewhere around PCI init/enumeration. The same occurs with the most
> recent vendor kernel 3.10.17_1.0.0_ga kernel (works when PCI is
> disabled in the bootloader, hangs otherwise).
> 
> When I apply Fabio's patch above to the 3.16-rc2 kernel I find that
> scenarios #4 and #5 above then work, #3 boots but the PLX bridge fails
> all config cycles (0xff's), #2 boots but with no PCIe link, and #1
> above still hangs. Previously, when I have dug into this particular
> 'hang' issue on 3.15 I found that the delay needed to be between
> imx6_pcie_probe() requesting and asserting reset_gpio low, and before
> setting IOMUX_GPR1:18 to power down the PCIe PHY (note here, that the
> PHY is currently enabled in the bootloader when PCI is enabled there).
> 
> When I apply Fabio's patch above to the most recent vendor kernel
> 3.10.17_1.0.0_ga I still hang in all cases.
> 
> So while I agree there is something horribly wrong with IMX6 PCI
> still, I don't think Fabio's patch is the right solution and I don't
> have anything better at this point in time. I'm happy to share any
> hardware with anyone that can work through this issue.
> 
Can you try if the attached patch makes any difference?

Regards,
Lucas
------------------------------>8---------------------------------
From 0e2fc443c760290166f6371d50813e6c30a678da Mon Sep 17 00:00:00 2001
From: Lucas Stach <l.stach@pengutronix.de>
Date: Thu, 17 Jul 2014 18:54:44 +0200
Subject: [PATCH] try forcing LTSSM into detect state

---
 drivers/pci/host/pci-imx6.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Marek Vasut July 18, 2014, 9:44 a.m. UTC | #1 
On Friday, July 18, 2014 at 11:26:39 AM, Lucas Stach wrote:
> Hi Tim,
> 
> Am Donnerstag, den 26.06.2014, 17:29 -0700 schrieb Tim Harvey:
> [...]
> 
> > Shawn / Richard,
> > 
> > I am also affected by this issue on IMX6 boards that I support. If I
> > enable PCI in the bootloader I see similar hangs.
> > 
> > I have the following hardware configurations on my bench:
> >   1. IMX6DL + i210 (same PCI setup as Fabio's above, but DL instead of Q)
> >   2. IMX6Q + ath9k device
> >   3. IMX6DL + PLX PEX860x PCIe-to-PCIe bridge with various devices
> > 
> > behind the bridge, using a clock buffer from IMX6 PCIe clock
> > 
> >   4. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> > 
> > behind the bridge, using a clock buffer from IMX6 PCIe clock
> > 
> >   5. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> > 
> > behind the bridge using a clock generator (always on, ignoring the
> > PCIe clock)
> > 
> > For all of the above I have no PCI issues using
> > 3.14/3.15/3.16-rc2/vendor 3.10.17_1.0.0_ga unless I enable PCI in the
> > bootloader. When I do so, all of the above configurations hang
> > somewhere around PCI init/enumeration. The same occurs with the most
> > recent vendor kernel 3.10.17_1.0.0_ga kernel (works when PCI is
> > disabled in the bootloader, hangs otherwise).
> > 
> > When I apply Fabio's patch above to the 3.16-rc2 kernel I find that
> > scenarios #4 and #5 above then work, #3 boots but the PLX bridge fails
> > all config cycles (0xff's), #2 boots but with no PCIe link, and #1
> > above still hangs. Previously, when I have dug into this particular
> > 'hang' issue on 3.15 I found that the delay needed to be between
> > imx6_pcie_probe() requesting and asserting reset_gpio low, and before
> > setting IOMUX_GPR1:18 to power down the PCIe PHY (note here, that the
> > PHY is currently enabled in the bootloader when PCI is enabled there).
> > 
> > When I apply Fabio's patch above to the most recent vendor kernel
> > 3.10.17_1.0.0_ga I still hang in all cases.
> > 
> > So while I agree there is something horribly wrong with IMX6 PCI
> > still, I don't think Fabio's patch is the right solution and I don't
> > have anything better at this point in time. I'm happy to share any
> > hardware with anyone that can work through this issue.
> 
> Can you try if the attached patch makes any difference?
> 
> Regards,
> Lucas
> ------------------------------>8---------------------------------
> From 0e2fc443c760290166f6371d50813e6c30a678da Mon Sep 17 00:00:00 2001
> From: Lucas Stach <l.stach@pengutronix.de>
> Date: Thu, 17 Jul 2014 18:54:44 +0200
> Subject: [PATCH] try forcing LTSSM into detect state
> 
> ---
>  drivers/pci/host/pci-imx6.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index a568efaa331c..afa450c54aba 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -215,6 +215,8 @@ static int imx6_pcie_assert_core_reset(struct pcie_port
> *pp) {
>  	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> 
> +	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> +			IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
>  	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
>  			IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
>  	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,

Tried this, among many other things, but please let someone else also re-verify 
this. What I observed is that the LTSSM cannot leave the POLLING phase .
David Müller July 18, 2014, 11:44 a.m. UTC | #2 
Hello

Lucas Stach wrote:
> @@ -215,6 +215,8 @@ static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
>  {
>  	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
>  
> +	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> +			IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
>  	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
>  			IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
>  	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> 

Sorry, this doesn't seem to fix the problem (at least not with my
hardware).

Dave
diff mbox

Patch

diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index a568efaa331c..afa450c54aba 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -215,6 +215,8 @@  static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
 {
 	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
 
+	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 			IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
 	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,