[U-Boot] [PATCH 3/3] apalis_t30: fix optional pcie port reset for reliable pcie operation

[Marcel Ziswiler <marcel.ziswiler@toradex.com>]

Hi Stephen

On Tue, 2017-08-08 at 10:14 -0600, Stephen Warren wrote:
> On 08/08/2017 06:43 AM, Marcel Ziswiler wrote:
> > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > 
> > Allow optionally bringing up the Apalis type specific 4 lane PCIe
> > port
> > as well as the PCIe switch as found on the Apalis Evaluation board.
> > In
> > order to avoid violating the PCIe reset timing do this by
> > overriding the
> > tegra_pcie_board_port_reset() function. Note however that both the
> > Apalis type specific 4 lane PCIe port as well as the regular Apalis
> > PCIe
> > port are also left disabled in the device tree by default.
> > diff --git a/board/toradex/apalis_t30/apalis_t30.c
> > b/board/toradex/apalis_t30/apalis_t30.c
> > +#ifdef APALIS_T30_PCIE_EVALBOARD_INIT
> > +#define PEX_PERST_N	TEGRA_GPIO(S, 7) /* Apalis GPIO7 */
> > +#define RESET_MOCI_CTRL	TEGRA_GPIO(I, 4)
> > +#endif /* APALIS_T30_PCIE_EVALBOARD_INIT */
> 
> Shouldn't that be a CONFIG_xxx option (defined in Kconfig) rather
> than 
> something new added to the old-style config header?

Yes, of course. Excuse my nostalgia (;-p).

> > +void tegra_pcie_board_port_reset(void *port)
> > +{
> > +	int index = tegra_pcie_port_index_of_port(port);
> > +	if (index == 2) { /* I210 Gigabit Ethernet Controller (On-
> > module) */
> > +		tegra_pcie_port_reset(port);
> 
> I think it'd read better if the } were here rather than wrapping it
> onto 
> the else line; a special case where ifdefs are involved.

Agreed.

> > +#ifdef APALIS_T30_PCIE_EVALBOARD_INIT
> > +	} else if (index == 1) { /* Apalis PCIe */
> > +		/*
> > +		 * As port 0 and 1 share the same RESET_MOCI only
> > assert it once
> > +		 * for both ports below to avoid loosing the
> > previously brought
> > +		 * up port again.
> > +		 */
> 
> How do you know that port 0 gets reset first then port 1?

I of course know from looking at resp. driver but agreed this is kind
of an internal implementation thing which may change in the future
which would break this.

> Also, how do 
> you know that the user isn't going to initialize PCIe multiple times
> and 
> expect the HW to get reset when they do?

Good question. However after having it implemented as requested below
keeping status and such it turns out there is no easy way to ever re-
initialise at least not with nowadays driver model in place (e.g. see
DM_FLAG_ACTIVATED in device_probe() of drivers/core/device.c). Or did I
miss anything?

> This HW design seems fragile,

Agreed, however it is kind of the typical case when there are certain
HW chip erratas which the board designers decide not to fix in hardware
but rather relying on a software workaround.
 
> but I suppose it's rather difficult to change already-shipped HW:-)
> To 
> address some of the issues, does it make sense to keep state in this 
> function and do the reset the first time either index 0 or 1 is
> reset, 
> and not the second time, so this code doesn't care about the order? 

Yes, I actually implemented it that way now but as mentioned above I
don't think there is any easy way to ever cause any re-enumeration.

> To 
> account for re-initialization, you could perhaps do the reset every
> even 
> (second) time the function is called for index 0 or 1, not just the
> first.

Yes, that's exactly how the upcoming v2 does it.

> Aside from that, this series seems fine.

Thanks, Stephen.

Cheers

Marcel