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
