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.)
So the question becomes... How early does _WAK really need to be?
thanks
Len Brown, Intel Open Source Technology Center
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 8082871b409a..f25f1874cfaf 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -495,6 +495,8 @@ static void acpi_pm_start(u32 acpi_state)
*/
static void acpi_pm_end(void)
{
+ printk("lenb: acpi_pm_finish from within acpi_pm_end\n");
+ acpi_pm_finish();
acpi_turn_off_unused_power_resources();
acpi_scan_lock_release();
/*
@@ -639,7 +641,6 @@ static const struct platform_suspend_ops
acpi_suspend_ops = {
.begin = acpi_suspend_begin,
.prepare_late = acpi_pm_prepare,
.enter = acpi_suspend_enter,
- .wake = acpi_pm_finish,
.end = acpi_pm_end,
};
--
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
