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

[Eric Nelson]

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?

>>> "
>>> 6.6.1. Conventional Reset
>>>
>>> Conventional Reset includes all reset mechanisms other than Function
>>> Level Reset. There are two categories of Conventional Resets:
>>> Fundamental Reset and resets that are not Fundamental Reset. This
>>> section applies to all types of Conventional Reset.
>>>
>>> In all form factors and system hardware configurations, there must, at
>>> some level, be a hardware mechanism for setting or returning all Port
>>> states to the initial conditions specified in this document – this
>>> mechanism is called “Fundamental Reset.” This mechanism can take the
>>> form of an auxiliary signal provided by the system to a component or
>>> adapter card, in which case the signal must be called PERST#, and must
>>> conform to the rules specified in Section 4.2.4.8.1. When PERST# is
>>> provided to a component or adapter, this signal must be used by the
>>> component or adapter as Fundamental Reset.
>>>
>>> When PERST# is not provided to a component or adapter, Fundamental Reset
>>> is generated autonomously by the component or adapter, and the details
>>> of how this is done are outside the scope of this document. If a
>>> Fundamental Reset is generated autonomously by the component or adapter,
>>> and if power is supplied by the platform to the component/adapter, the
>>> component/adapter must generate a Fundamental Reset to itself if the
>>> supplied power goes outside of the limits specified for the form factor
>>> or system.
>>> "
>>>
>>> This means, your platform _MUST_ have a FR implementation. If you have
>>> PERST connected (that's the reset pin) to for example GPIO, then so be
>>> it and that's your FR.
>>>
>>> The third paragraph states that if you do NOT have PERST connected, you
>>> need some other way of doing FR. Another way of generating FR is to
>>> depend on POR, so when power is applied to the component, it will
>>> generate FR internally. Thus to produce an "alternative" FR without
>>> PERST connected, you toggle the power GPIO of the particular slot.
>>>
>>> I think the SL can do neither, right ? :-(
>>
>> Right again.
>>
>> PCIe was very much an afterthought (and late addition) on SABRE Lite,
>> and unfortunately only slightly improved on Nitrogen6x.
>
> OK. This wasn't an attack in the SL direction, really. I really want to warn
> people to comply with the spec, since otherwise they will suffer from weird bugs
> that are hard to find. The PERST is a prime example of that :-(
>

No worries. I appreciate the details.

> We really should start waving a sign "YOU MUST CONNECT PERST IN YOUR NEW DESIGN,
> OTHERWISE A KITTEN DIES!"
>

Hey, leave the kittens alone!

>> 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.