Re: [PATCH] PCI/PM: Assume ports without DLL Link Active train links in 100 ms

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Wed, Aug 19, 2020 at 12:58:18PM -0400, Lyude Paul wrote:
> On Wed, 2020-08-19 at 16:06 +0300, Mika Westerberg wrote:
> > Kai-Heng Feng reported that it takes a long time (> 1 s) to resume
> > Thunderbolt-connected devices from both runtime suspend and system sleep
> > (s2idle).
> > 
> > This was because some Downstream Ports that support > 5 GT/s do not also
> > support Data Link Layer Link Active reporting.  Per PCIe r5.0 sec 6.6.1:
> > 
> >   With a Downstream Port that supports Link speeds greater than 5.0 GT/s,
> >   software must wait a minimum of 100 ms after Link training completes
> >   before sending a Configuration Request to the device immediately below
> >   that Port. Software can determine when Link training completes by polling
> >   the Data Link Layer Link Active bit or by setting up an associated
> >   interrupt (see Section 6.7.3.3).
> > 
> > Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but
> > at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel
> > JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not.
> > 
> > Previously we tried to wait for Link training to complete, but since there
> > was no DLL Link Active reporting, all we could do was wait the worst-case
> > 1000 ms, then another 100 ms.
> > 
> > Instead of using the supported speeds to determine whether to wait for Link
> > training, check whether the port supports DLL Link Active reporting.  The
> > Ports in question do not, so we'll wait only the 100 ms required for Ports
> > that support Link speeds <= 5 GT/s.
> > 
> > This of course assumes these Ports always train the Link within 100 ms even
> > if they are operating at > 5 GT/s, which is not required by the spec.
> > 
> > This version adds a special check for devices whose power management is
> > disabled by their driver (->pm_cap is set to zero). This is needed to
> > avoid regression with some NVIDIA GPUs.
> 
> Hm, I'm not entirely sure that the link training delay is specific to laptops
> with ->pm_cap set to 0, I think we should try figuring out if there's any
> laptops that match those characteristics before moving forward with this - I'll
> take a look through the test machines I've got available today

OK, thanks!