On Mon, May 30, 2016 at 4:44 PM, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > On Mon, May 30, 2016 at 12:33:26PM +0300, Mika Westerberg wrote: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
