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

[Marek Vasut <marex@denx.de>]

On Monday, February 03, 2014 at 08:57:30 PM, Eric Nelson wrote:

[...]

> > "
> > 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 :-(

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

> 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 (!)

Best regards,
Marek Vasut