All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] U-boot hangs on imx6 pci driver
Date: Fri, 20 Jun 2014 02:11:18 +0200	[thread overview]
Message-ID: <201406200211.18240.marex@denx.de> (raw)
In-Reply-To: <CAJ+vNU3DOdLjeaETA=GWac_GH4GpPGaAgYF=GSRfYcU8+je+4Q@mail.gmail.com>

On Thursday, June 05, 2014 at 12:13:39 PM, Tim Harvey wrote:
> On Wed, Jun 4, 2014 at 11:30 PM, "David M?ller (ELSOFT AG)"
> 
> <d.mueller@elsoft.ch> wrote:
> > Tim Harvey wrote:
> >> When enabling PCI support in u-boot my 3.14 kernel hangs somewhere
> >> during PCI init or enumeration (can't tell as uart is not up yet)
> > 
> > Enabling "earlyprintk" support may help.
> 
> David,
> 
> This is definitely related to PCI_RST# as the delay you inserted is
> essentially after imx6_pcie_probe() gets the reset_gpio from OF and
> asserts it low. Moving the delay around I find that it must come
> before imx6_pcie_assert_core_reset(), specifically before
> IMOUX_GPR1:18 is set (phy power down request).
> 
> Enabling earlyprintk to try to debug the 'hang' on my boards further I
> find that I hang in in imx6_pcie_link_up() during the
> readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) which is called after setting
> IOMUXC_GPR12:1 to start LTSSM. If I add a udelay(55) (55us determined
> via trial and error) directly after setting IOMUXC_GPR12:1 I get
> passed 'this' hang however during pci_scan_bridge() I find that
> PCI_PRIMARY_BUS config dword comes back as 0x00000000 instead of
> 0x00010100. This appears to cause the causes the pci code to think the
> RC is a bridge, tries to scan behind it, and hangs (because its not a
> bridge and those transactions are not valid).
> 
> All of this seems to indicate to me that the PLX bridge I have on my
> boards requires a longer minimum time to be held in reset 'before' the
> PCIe PHY is powered down 'if' it has already been enumerated (or
> something to that nature) as I only see this if I enable PCI in uboot.
> Why I also need the extra udelay after enabling LTSSM in this scenario
> I can't say.
> 
> This may correlate with your findings as I believe you say you have an
> i210 attached to the IMX6 RC and have found an errata indicating the
> i210 needs a longer time in reset. Do you find that this is the case
> even if you disable PCI in uboot? My first thought when I read about
> that i210 errata you pointed out was that it wasn't an issue because
> we do hold reset low for 100ms in the kernel but if the issue has
> something to do with holding it in reset with the PHY being powered
> down then perhaps this explains things.
> 
> Merek,
> 
> you've done much more work on IMX6 link than I... any of this make
> sense to you? I believe you have never encountered this 100%
> repeatable issue on your board(s) that David and I do encounter, but
> you have encountered a 1% PCIe link failure rate (which I'm inclined
> to say is something completely different?).

Sorry for the later reply. Most certainly, I observe a failure rate of 1-out-
of-200 or so. I also use i210 though, so it might be related somehow. Can you 
tell me which i210 errata are you talking about here please?

I am currently discussing this with FSL, but it didn't yield any results yet.

Best regards,
Marek Vasut

  reply	other threads:[~2014-06-20  0:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-27 12:30 [U-Boot] U-boot hangs on imx6 pci driver Fabio Estevam
2014-05-27 13:25 ` Marek Vasut
2014-05-27 14:43   ` "David Müller (ELSOFT AG)"
2014-05-27 14:56     ` Marek Vasut
2014-05-28  7:40       ` "David Müller (ELSOFT AG)"
2014-05-28 16:43         ` Fabio Estevam
2014-05-30  7:04           ` "David Müller (ELSOFT AG)"
2014-06-05  0:16             ` Tim Harvey
2014-06-05  6:30               ` "David Müller (ELSOFT AG)"
2014-06-05 10:13                 ` Tim Harvey
2014-06-20  0:11                   ` Marek Vasut [this message]
2014-06-05 15:27               ` Fabio Estevam
2014-06-05 17:53                 ` Marek Vasut
2014-06-05 19:20                   ` Fabio Estevam
2014-06-05 22:04                     ` Marek Vasut
2014-06-05 22:14                       ` Fabio Estevam
2014-06-05 22:15                         ` Marek Vasut
2014-06-06  4:35                 ` Tim Harvey
2014-06-17 14:14                   ` Fabio Estevam
2014-06-20  0:22                     ` Marek Vasut
2014-05-28 16:42 ` Fabio Estevam
2014-05-28 18:31   ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201406200211.18240.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.