Re: [PATCH v4 05/12] PCI: aardvark: Issue PERST via GPIO

[Rob Herring]

On Thu, Apr 30, 2020 at 10:22:45AM +0200, Pali Rohár wrote:
> On Thursday 30 April 2020 10:06:18 Pali Rohár wrote:
> > +static void advk_pcie_issue_perst(struct advk_pcie *pcie)
> > +{
> > +	u32 reg;
> > +
> > +	if (!pcie->reset_gpio)
> > +		return;
> > +
> > +	/* PERST does not work for some cards when link training is enabled */
> > +	reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
> > +	reg &= ~LINK_TRAINING_EN;
> > +	advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG);
> > +
> > +	/* 10ms delay is needed for some cards */
> > +	dev_info(&pcie->pdev->dev, "issuing PERST via reset GPIO for 10ms\n");
> > +	gpiod_set_value_cansleep(pcie->reset_gpio, 1);
> > +	usleep_range(10000, 11000);
> > +	gpiod_set_value_cansleep(pcie->reset_gpio, 0);
> > +}
> 
> Just note about delay between changing GPIO reset:
> 
> In V2 there as only 1ms, but be figured out that it is not enough for
> WLE900VX cards when they were already initialized in u-boot.
> 
> I tried to find in PCI specs if there is a defined timeout for this
> operation. I found following 3 delay definitions which could be related:
> 
> TPVPERL - PERST# must remain active at least this long after power becomes valid
> TPERST - When asserted, PERST# must remain asserted at least this long
> TPERSTCLK - PERST# must remain active at least this long after any supplied reference clock is stable
> 
> In another spec they have defined also minimal values:
> 
> TPVPERL - Power stable to PERST# inactive - Min 100 ms
> TPERST - PERST# active time - Min 100 us
> TPERSTCLK - REFCLK stable before PERST# inactive - Min 100 us
> 
> After experimenting with those Compex WLE900VX cards, I know that 100us
> delay is not enough. And I'm not sure if TPVPERL is really relevant for
> this case. I understood that TPVPERL is needed when initializing power
> again. And because delaying boot by another 100ms is does not have to be
> acceptable if there is not strict reason for it, I rather decided to
> stay with just 10ms delay.
> 
> If you know what is the correct timeout between changing GPIO reset,
> please let me know and in future I can fix/reimplement it.

I don't know, but seems like something each driver author shouldn't be 
making up.

Rob