On Wed, Nov 29, 2017 at 7:06 AM, Len Brown <lenb@xxxxxxxxxx> wrote: > Rafael, > > Per our discussion... > > As of Linux-4.14, acpi_pm_finish() takes over 1,000 ms on the Dell > XPS13. This routine accounts for 50% of the total resume time of this > machine. > > So I commented _WAK out of acpi_hw_legacy_wake(), and that 1000ms > became 2ms. (and the system also seemed to resume fine without _WAK, > though I didn't test it extensively) > > So I effectively pre-pended acpi_pm_finish() to acpi_pm_end() with the > hack patch below, and that seems to work fine. > > (Note that it seems that the relative ordering of enabling run-time > GPEs and invoking _WAK is already correct in acpi_hw_legacy_wake() -- > the GPEs are enabled first.) The ordering is correct, but the GPEs should be enabled before the SCI is enabled by resume_device_irqs(). Arguably, they may just be enabled as soon as the kernel gets control back as the SCI won't trigger anyway before resume_device_irqs(). > So the question becomes... How early does _WAK really need to be? On this system, apparently, it may go late in the resume path. There are systems on which moving it after the PCI resume introduced issues, which is why the default ordering is what it is IIRC (but that was bundled with the GPE stuff then, so there could be effects of that too). In any case, we may play with the ordering, but that's fragile. Or we can enable the EC polling just for the time of executing _WAK (which should avoid the thermal issues on Lenovo and similar). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
