[U-Boot] [PATCH] pci: mx6: Implement reset callback

[Eric Nelson <eric.nelson@boundarydevices.com>]

On 02/03/2014 04:34 PM, Marek Vasut wrote:
> On Monday, February 03, 2014 at 09:54:33 PM, Eric Nelson wrote:
>> Hi Marek,
>>
>> On 02/03/2014 01:16 PM, Marek Vasut wrote:
>>> On Monday, February 03, 2014 at 08:57:30 PM, Eric Nelson wrote:
>>>
>>> [...]
>>
>> I like having this bit included, but do you need to attribute copyright
>> for this block?
>
> I'd hate to tempt PCISIG with this portion actually. That's why I didn't put the
> whole quotation into the patch either.
>
> [...]
>
>>> We really should start waving a sign "YOU MUST CONNECT PERST IN YOUR NEW
>>> DESIGN, OTHERWISE A KITTEN DIES!"
>>
>> Hey, leave the kittens alone!
>
> Are ponies ok? Friendship is magic afterall :-)
>
Works for me.

>>>> We have had success in using/testing PCIe devices without either, but
>>>> that doesn't mean we match the spec, and I suppose we'll have to live
>>>> with the "broken design" message...
>>>
>>> I know. The design without FR works most of the time, but there is one
>>> particular scenario where it may fail (means it fails reliably). I will
>>> assume we have just a simple RC<->EP connection with EP being i82574L
>>> card (well supported and easily available intel NIC):
>>>
>>> 1) Cold boot the system
>>> 2) Bring up the PCIe link in U-Boot
>>> 3) Use the e1000e driver for some transfer
>>> 4) Boot Linux
>>> 5) Bring up the PCIe link in Linux
>>> 6) Use the e1000e driver for some transfer
>>> 7) Reboot the system from Linux
>>> 8) Bring up the PCIe link in U-Boot
>>>
>>> In case you don't have means to do FR, your system will fail during 5)
>>> and/or during 8) because in either case, the link and/or EP device can
>>> be in undefined state from previous usage. You are therefore not able to
>>> send in-band messages to the EP (to issue hot reset for example*) nor
>>> restart the link, thus you're trapped.
>>>
>>> * if you try to send anything over unstable PCIe link on MX6, it can
>>> stall your entire system to the point where the system bus is stuck and
>>> not even JTAG debugger can halt the CPU (!)
>>
>> Thanks. That's a useful test scenario.
>
> Hope it helps :) Sometimes you need to do a few cycles until the hardware hangs.
> I found this out when I was debugging another custom board here. I think we will
> have a rock-solid PCIe implementation on MX6 for 3.14 and 2014.04 ;-)
>

You can bet on a knee-jerk reaction at design reviews here in Arizona...

Regards,


Eric