[U-Boot] U-boot hangs on imx6 pci driver

[Tim Harvey]

On Wed, Jun 4, 2014 at 11:30 PM, "David Müller (ELSOFT AG)"
<d.mueller at 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?).

Regards,

Tim

>
>> David, on your board(s) do you have a PCIe switch as well?
>
> Not yet, but this (using a PEX8603) is planned for the near future.
>
> Dave
>