Dell XPS13 9360 - 1,000ms acpi_pm_finish()

Dell XPS13 9360 - 1,000ms acpi_pm_finish()

[Len Brown]

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,
 };

Re: Dell XPS13 9360 - 1,000ms acpi_pm_finish()

[Rafael J. Wysocki]

On Wed, Nov 29, 2017 at 7:06 AM, Len Brown <lenb@kernel.org> 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

RE: Dell XPS13 9360 - 1,000ms acpi_pm_finish()

[Zhang, Rui]

> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Wednesday, November 29, 2017 10:35 PM
> To: Len Brown <lenb@kernel.org>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; linux acpi <linux-
> acpi@vger.kernel.org>
> Subject: Re: Dell XPS13 9360 - 1,000ms acpi_pm_finish()
> 
> On Wed, Nov 29, 2017 at 7:06 AM, Len Brown <lenb@kernel.org> 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)
> >
How long does acpi_pm_finish() take in 4.12 kernel?
It's good to know how much the reverted EC busy_polling mechanism can improve on this case.

Thanks,
rui
> > 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@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: Dell XPS13 9360 - 1,000ms acpi_pm_finish()

[Len Brown]

> How long does acpi_pm_finish() take in 4.12 kernel?
> It's good to know how much the reverted EC busy_polling mechanism can improve on this case.

4.12.0 acpi_pm_finish() takes on the order of 40ms (it varies somewhat),
which is about the same speed as when this hack patch is applied.

This is compared to over 1,100ms in current 4.14.