On Mon, May 30, 2016 at 4:44 PM, Mika Westerberg
[off-list ref] wrote:

On Mon, May 30, 2016 at 12:33:26PM +0300, Mika Westerberg wrote:

quoted

I also learned that both of these can be shortened with following
mechanisms:

 - PCIe readines notifications (6.23 in PCIe spec 3.1a)
 - ACPI _DSM method returning readines durations from  (4.6.9 in PCI
   firmware spec 3.2).

BTW, looks like the latter is already implemented in
pci_acpi_optimize_delay().

Hmm, Lukas's trace suggest a few independent problems (or optimisations):
1. Those devices are siblings, we should wake all of them in parallel
and then wait once instead of one by one.
2. Why are we waiting after _suspend at all? It seems we should only
wait before the next access. Sleeping after _suspend looks like a stop
gap measure to guarantee that no accesses take place?
3. The idle timeout is too low, there should be no suspend between
discovery and probing.
4. Even if the spec says 50ms, we might still want to have shorter
sleep times for known good devices. Thunderbolt can produce PCI
hierarchies which are 7 levels deep with 4 hp bridges on each level.
Waking all of that would take 50ms * 7 * 4 = 1400ms (not counting
upstream bridges which have the normal d3 delay).

Does TB support PCIe readines notifications?

Andreas