Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

Hi Rafael

On 6/24/19 4:24 AM, Rafael J. Wysocki wrote:
> 
> On Saturday, May 25, 2019 7:31:20 AM CEST Robert R. Howell wrote:
>>
>>...
>>...
>>
>> I've finally managed to complete a reasonable set of tests on my T100TA 
>> using your
>> 2nd patch from above, and on a 5.1.4 based kernel with ONLY this patch 
>> applied I can
>> successfully suspend and hibernate the system.
> 
> Sorry for the long delay.
> 
> I haven't dropped this issue on the floor, I hope that you are still able to 
> follow up here.
> 
> Can you please test the appended patch instead of the previous one?
> 
> I have found some inconsistencies in the handling of hibernation in the ACPI 
> PM domain
> and the LPSS driver that should be covered by this patch.
> 
> ---
> ...
> ...

I did just try your June 24 patch on my ASUS T100TA, but unfortunately, unlike 
the earlier version
of your patch, this version does NOT fix the hibernation problem.  I applied 
just this patch to a 
5.2-rc6 kernel,  and once again I'm seeing the 
 "i2c_designware 80860F41:01  controller timed out" 
errors on resume from hibernate. As before the internal sound output fails 
after hibernate/resume 
because of these timeouts.

Suspend (rather than hibernate) DOES work OK.  On the first resume from either 
suspend or hibernate 
I DO still see, as with the previous patch, an "i2c_designware 80860F41:00: 
Transfer while suspended" 
error, but also as before, that error alone doesn't seem fatal because with 
just suspend/resume 
I do NOT get subsequent "controller timed out" errors and sound continues to 
work.

While I haven't tested the May version of your patch (yet) with 5.2-rc6, I did 
test it a couple weeks ago 
with 5.2-rc4 and hibernate/resume did still work with that combination.  So 
most likely the problem is the 
new patch rather than some other change in the kernel since my May tests.

I've attached dmesg output from the hibernate/resume attempt using 5.2-rc6 and 
your new patch.

Bob Howell

[  173.119967] PM: hibernation entry
[  173.568856] Filesystems sync: 0.109 seconds
[  173.568867] Freezing user space processes ... (elapsed 0.006 seconds) done.
[  173.575501] OOM killer disabled.
[  173.575602] PM: Marking nosave pages: [mem 0x-0x0fff]
[  173.575608] PM: Marking nosave pages: [mem 0x0008f000-0x0008]
[  173.575612] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
[  173.575621] PM: Marking nosave pages: [mem 0x2000-0x200f]
[  173.575638] PM: Marking nosave pages: [mem 0x78cf5000-0x79badfff]
[  173.575831] PM: Marking nosave pages: [mem 0x79bc9000-0x79bc9fff]
[  173.575835] PM: Marking nosave pages: [mem 0x79bcb000-0x79bcbfff]
[  173.575839] PM: Marking nosave pages: [mem 0x79d41000-0x79ff8fff]
[  173.575877] PM: Basic memory bitmaps created
[  173.575879] PM: Preallocating image memory... done (allocated 171204 pages)
[  182.809636] PM: Allocated 684816 kbytes in 9.23 seconds (74.19 MB/s)
[  182.809638] Freezing remaining freezable tasks ... (elapsed 0.780 seconds) 
done.
[  185.130057] Disabling non-boot CPUs ...
[  185.133208] smpboot: CPU 1 is now offline
[  185.137135] smpboot: CPU 2 is now offline
[  185.141733] smpboot: CPU 3 is now offline
[  185.142870] PM: Creating hibernation image:
[  185.386747] PM: Need to copy 162306 pages
[  185.386763] PM: Normal pages needed: 162306 + 1024, available pages: 332540
[  185.144025] Enabling non-boot CPUs ...
[  185.144401] x86: Booting SMP configuration:
[  185.144409] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  185.146671] CPU1 is up
[  185.147042] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  185.149320] CPU2 is up
[  185.149678] smpboot: Booting Node 0 Processor 3 APIC 0x6
[  185.152237] CPU3 is up
[  185.240385] byt_gpio INT33FC:02: restored pin 16 conf0 0x2603cc01
[  185.301425] i2c_designware 80860F41:01: timeout in disabling adapter
[  185.371784] usb usb1: root hub lost power or was reset
[  185.371800] usb usb2: root hub lost power or was reset
[  185.450066] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[  185.453341] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[  185.456714] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[  185.463740] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[  185.712824] usb 1-3: reset full-speed USB device number 2 using xhci_hcd
[  185.939966] PM: Basic memory bitmaps freed
[  185.939976] OOM killer enabled.
[  185.939980] Restarting tasks ... done.
[  185.967541] i2c_designware 80860F41:01: timeout waiting for bus ready
[  185.967558] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[  185.973293] PM: hibernation exit
[  185.990033] i2c_designware 80860F41:01: timeout waiting for bus ready
[  186.012593] i2c_designware 80860F41:01: timeout waiting for bus ready
[  186.035154] i2c_designware 80860F41:01: timeout waiting for bus ready
[  186.057546] i2c_designware 80860F41:01: timeout waiting for bus ready
[  186.079936] i2c_designware 80860F41:01: timeout waiting for bus ready
[  186.102763] i2c_designware 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Rafael J. Wysocki]

On Monday, June 24, 2019 12:51:33 PM CEST Hans de Goede wrote:
> Hi Rafael,
> 
> 
> 
> > Sorry for the long delay.
> > 
> > I haven't dropped this issue on the floor, I hope that you are still able 
> > to follow up here.
> > 
> > Can you please test the appended patch instead of the previous one?
> > 
> > I have found some inconsistencies in the handling of hibernation in the 
> > ACPI PM domain
> > and the LPSS driver that should be covered by this patch.
> 
> I know this is just a testing patch for now, but still I've given it
> a quick look, some comments inline.
> 
> > ---
> >   drivers/acpi/acpi_lpss.c |   63 
> > +++
> >   drivers/acpi/device_pm.c |   30 --
> >   include/linux/acpi.h |4 ++
> >   3 files changed, 79 insertions(+), 18 deletions(-)
> > 
> > Index: linux-pm/drivers/acpi/device_pm.c
> > ===
> > --- linux-pm.orig/drivers/acpi/device_pm.c
> > +++ linux-pm/drivers/acpi/device_pm.c
> > @@ -1171,6 +1171,32 @@ int acpi_subsys_thaw_noirq(struct device
> > return pm_generic_thaw_noirq(dev);
> >   }
> >   EXPORT_SYMBOL_GPL(acpi_subsys_thaw_noirq);
> > +
> > +/**
> > + * acpi_subsys_restore_noirq - Run the device driver's "noirq" restore 
> > callback.
> > + * @dev: Device to handle.
> > + */
> > +int acpi_subsys_restore_noirq(struct device *dev)
> > +{
> > +   /* This is analogous to what acpi_subsys_resune_noirq() does. */
> > +   if (dev_pm_smart_suspend_and_suspended(dev))
> > +   pm_runtime_set_active(dev);
> > +
> > +   return pm_generic_restore_noirq(dev);
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_subsys_restore_noirq);
> > +
> > +/**
> > + * acpi_subsys_restore_early - Restore device using ACPI.
> > + * @dev: Device to restore.
> > + */
> > +int acpi_subsys_restore_early(struct device *dev)
> > +{
> > +   int ret = acpi_dev_resume(dev);
> > +   return ret ? ret : pm_generic_restore_early(dev);
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_subsys_restore_early);
> > +
> >   #endif /* CONFIG_PM_SLEEP */
> >   
> >   static struct dev_pm_domain acpi_general_pm_domain = {
> > @@ -1192,8 +1218,8 @@ static struct dev_pm_domain acpi_general
> > .poweroff = acpi_subsys_suspend,
> > .poweroff_late = acpi_subsys_suspend_late,
> > .poweroff_noirq = acpi_subsys_suspend_noirq,
> > -   .restore_noirq = acpi_subsys_resume_noirq,
> > -   .restore_early = acpi_subsys_resume_early,
> > +   .restore_noirq = acpi_subsys_restore_noirq,
> > +   .restore_early = acpi_subsys_restore_early,
> >   #endif
> > },
> >   };
> > Index: linux-pm/drivers/acpi/acpi_lpss.c
> > ===
> > --- linux-pm.orig/drivers/acpi/acpi_lpss.c
> > +++ linux-pm/drivers/acpi/acpi_lpss.c
> > @@ -1069,36 +1069,67 @@ static int acpi_lpss_suspend_noirq(struc
> > return acpi_subsys_suspend_noirq(dev);
> >   }
> >   
> > -static int acpi_lpss_do_resume_early(struct device *dev)
> > +static int acpi_lpss_resume_noirq(struct device *dev)
> >   {
> > -   int ret = acpi_lpss_resume(dev);
> > +   struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> > +
> > +   /* Follow acpi_subsys_resune_noirq(). */
> > +   if (dev_pm_may_skip_resume(dev))
> > +   return 0;
> > +
> > +   if (dev_pm_smart_suspend_and_suspended(dev))
> > +   pm_runtime_set_active(dev);
> >   
> > -   return ret ? ret : pm_generic_resume_early(dev);
> > +   if (pdata->dev_desc->resume_from_noirq) {
> > +   int ret = acpi_lpss_resume(dev);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> > +   return pm_generic_resume_noirq(dev);
> >   }
> 
> Hmm, normally acpi_lpss_resume runs at resume_early time, AFAIK
> the order of resume callbacks calling is: resume_noirq, resume_early, resume
> 
> So normally our call order is:
> 
> ---noirq-phase---
> pm_generic_resume_noirq()
> ---early-phase---
> acpi_lpss_resume()
> pm_generic_resume_early()
> 
> My patch adding the resume_from_noirq flag, move the calling of
> acpi_lpss_resume() to the resume_noirq phase (if the flag is
> set) but kept the generic order, so the call order with the
> flag set currently is:
> 
> ---noirq-phase---
> pm_generic_resume_noirq()
> acpi_lpss_resume()
> ---early-phase---
> pm_generic_resume_early()
> 
> So the order of the 3 calls relative to each other did not change.
> 
> You are changing this to:
> 
> ---noirq-phase---
> acpi_lpss_resume()
> pm_generic_resume_noirq()
> ---early-phase---
> pm_generic_resume_early()
> 
> So now when the flag is set acpi_lpss_resume() runs before
> pm_generic_resume_noirq(). Is this intentional ?

Kind of yes, but this is two patches in one. :-)

The ordering change should really be a separate patch IMO.

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hi Rafael,




Sorry for the long delay.

I haven't dropped this issue on the floor, I hope that you are still able to 
follow up here.

Can you please test the appended patch instead of the previous one?

I have found some inconsistencies in the handling of hibernation in the ACPI PM 
domain
and the LPSS driver that should be covered by this patch.


I know this is just a testing patch for now, but still I've given it
a quick look, some comments inline.


---
  drivers/acpi/acpi_lpss.c |   63 
+++
  drivers/acpi/device_pm.c |   30 --
  include/linux/acpi.h |4 ++
  3 files changed, 79 insertions(+), 18 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -1171,6 +1171,32 @@ int acpi_subsys_thaw_noirq(struct device
return pm_generic_thaw_noirq(dev);
  }
  EXPORT_SYMBOL_GPL(acpi_subsys_thaw_noirq);
+
+/**
+ * acpi_subsys_restore_noirq - Run the device driver's "noirq" restore 
callback.
+ * @dev: Device to handle.
+ */
+int acpi_subsys_restore_noirq(struct device *dev)
+{
+   /* This is analogous to what acpi_subsys_resune_noirq() does. */
+   if (dev_pm_smart_suspend_and_suspended(dev))
+   pm_runtime_set_active(dev);
+
+   return pm_generic_restore_noirq(dev);
+}
+EXPORT_SYMBOL_GPL(acpi_subsys_restore_noirq);
+
+/**
+ * acpi_subsys_restore_early - Restore device using ACPI.
+ * @dev: Device to restore.
+ */
+int acpi_subsys_restore_early(struct device *dev)
+{
+   int ret = acpi_dev_resume(dev);
+   return ret ? ret : pm_generic_restore_early(dev);
+}
+EXPORT_SYMBOL_GPL(acpi_subsys_restore_early);
+
  #endif /* CONFIG_PM_SLEEP */
  
  static struct dev_pm_domain acpi_general_pm_domain = {

@@ -1192,8 +1218,8 @@ static struct dev_pm_domain acpi_general
.poweroff = acpi_subsys_suspend,
.poweroff_late = acpi_subsys_suspend_late,
.poweroff_noirq = acpi_subsys_suspend_noirq,
-   .restore_noirq = acpi_subsys_resume_noirq,
-   .restore_early = acpi_subsys_resume_early,
+   .restore_noirq = acpi_subsys_restore_noirq,
+   .restore_early = acpi_subsys_restore_early,
  #endif
},
  };
Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -1069,36 +1069,67 @@ static int acpi_lpss_suspend_noirq(struc
return acpi_subsys_suspend_noirq(dev);
  }
  
-static int acpi_lpss_do_resume_early(struct device *dev)

+static int acpi_lpss_resume_noirq(struct device *dev)
  {
-   int ret = acpi_lpss_resume(dev);
+   struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+
+   /* Follow acpi_subsys_resune_noirq(). */
+   if (dev_pm_may_skip_resume(dev))
+   return 0;
+
+   if (dev_pm_smart_suspend_and_suspended(dev))
+   pm_runtime_set_active(dev);
  
-	return ret ? ret : pm_generic_resume_early(dev);

+   if (pdata->dev_desc->resume_from_noirq) {
+   int ret = acpi_lpss_resume(dev);
+   if (ret)
+   return ret;
+   }
+
+   return pm_generic_resume_noirq(dev);
  }


Hmm, normally acpi_lpss_resume runs at resume_early time, AFAIK
the order of resume callbacks calling is: resume_noirq, resume_early, resume

So normally our call order is:

---noirq-phase---
pm_generic_resume_noirq()
---early-phase---
acpi_lpss_resume()
pm_generic_resume_early()

My patch adding the resume_from_noirq flag, move the calling of
acpi_lpss_resume() to the resume_noirq phase (if the flag is
set) but kept the generic order, so the call order with the
flag set currently is:

---noirq-phase---
pm_generic_resume_noirq()
acpi_lpss_resume()
---early-phase---
pm_generic_resume_early()

So the order of the 3 calls relative to each other did not change.

You are changing this to:

---noirq-phase---
acpi_lpss_resume()
pm_generic_resume_noirq()
---early-phase---
pm_generic_resume_early()

So now when the flag is set acpi_lpss_resume() runs before
pm_generic_resume_noirq(). Is this intentional ?

Regards,

Hans




  
  static int acpi_lpss_resume_early(struct device *dev)

  {
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
  
-	if (pdata->dev_desc->resume_from_noirq)

-   return 0;
+   if (!pdata->dev_desc->resume_from_noirq) {
+   int ret = acpi_lpss_resume(dev);
+   if (ret)
+   return ret;
+   }
  
-	return acpi_lpss_do_resume_early(dev);

+   return pm_generic_resume_early(dev);
  }
  
-static int acpi_lpss_resume_noirq(struct device *dev)

+static int acpi_lpss_restore_noirq(struct device *dev)
  {
struct lpss_private_data *pdata = 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Rafael J. Wysocki]

On Saturday, May 25, 2019 7:31:20 AM CEST Robert R. Howell wrote:
> On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:
> > 
> > On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
> >> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
> >>
> >>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  
> >>> wrote:
> 
>  On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >
> > On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  
> > wrote:
> >>
> >> On 4/18/19 5:42 AM, Hans de Goede wrote:
> >>
>  On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >
> > Hmm, interesting so you have hibernation working on a T100TA
> > (with 5.0 + 02e45646d53b reverted), right ?
> >
> >>
> >>
> >> I've managed to find a way around the i2c_designware timeout issues
> >> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> >> which was added in the 02e45646d53b commit.
> >>
> >> To test that I've started with a 5.1-rc5 kernel, applied your recent 
> >> patch
> >> to acpi_lpss.c, then apply the following patch of mine, removing
> >> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
> >> other patches as well but those are not related to the i2c-designware 
> >> or
> >> acpi issues addressed here.)
> >>
> >> On a resume from hibernation I still see one error:
> >>   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while 
> >> suspended"
> >> but I no longer get the i2c_designware timeouts, and audio does now 
> >> work
> >> after the resume.
> >>
> >> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> >> hardware, but perhaps this will give you a clue as to what is going
> >> wrong with hibernate/resume on the T100TA's.
> >
> > What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >
> 
>  I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>  DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
>  DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>  after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>  then the timeouts go away.
> >>>
> >>> OK, thanks!
> >>>
> >>> Is non-hibernation system suspend affected too?
> >>
> >> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
> >> applied
> >> but without any changes to i2c-designware-platdrv.c, so the
> >> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and 
> >> DPM_FLAG_LEAVE_SUSPENDED flags
> >> are all set.
> >>
> >> Suspend does work OK, and after resume I do NOT get any of the crippling
> >> i2c_designware timeout errors which cause sound to fail after hibernate.  
> >> I DO see one
> >>   "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
> >> error on resume, just as I do on hibernate.  I've attached a portion of 
> >> dmesg below.
> >> The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs
> >> intermittently on these machines, but doesn't seem related to the other 
> >> issues.
> >> I had one test run when it was absent but the rest of the messages were the
> >> same -- but then kept getting that unknown key error on all my later tries.
> >>
> >> I did notice the "2sidle" in the following rather than "shallow" or 
> >> "deep".  A
> >> cat of /sys/power/state shows "freeze mem disk" but a
> >> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow 
> >> and deep
> >> are not enabled for this system.  I did check the input power (or really 
> >> current)
> >> as it went into suspend and the micro-usb power input drops from about
> >> 0.5 amps to 0.05 amps.  But clearly a lot of devices are still active, as 
> >> movement
> >> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend.  That 
> >> presumably is
> >> why suspend doesn't trigger the same i2c_designware problems as hibernate.
> >>
> >> Let me know if I can do any other tests.
> > 
> > Can you please check if the appended patch makes the hibernate issue go 
> > away for you, without any other changes?
> > 
> > ---
> >  drivers/pci/pci-driver.c |   36 ++--
> >  1 file changed, 10 insertions(+), 26 deletions(-)
> > 
> > Index: linux-pm/drivers/pci/pci-driver.c
> > ===
> > --- linux-pm.orig/drivers/pci/pci-driver.c
> > +++ linux-pm/drivers/pci/pci-driver.c
> > @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> > }
> > 
> > /*
> > -* This used to be done in pci_pm_prepare() for all devices and some
> > -* drivers may depend on it, so do it here.  Ideally, 
> > runtime-suspended
> > -* devices should not be touched during freeze/thaw transitions,
> > -* however.
> > +* Resume all runtime-suspended devices before creating a snapshot
> > +* image of system 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:
> 
> On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>
>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:

 On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>
> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  
> wrote:
>>
>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>
 On 4/8/19 2:16 AM, Hans de Goede wrote:>
>
> Hmm, interesting so you have hibernation working on a T100TA
> (with 5.0 + 02e45646d53b reverted), right ?
>
>>
>>
>> I've managed to find a way around the i2c_designware timeout issues
>> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>> which was added in the 02e45646d53b commit.
>>
>> To test that I've started with a 5.1-rc5 kernel, applied your recent 
>> patch
>> to acpi_lpss.c, then apply the following patch of mine, removing
>> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
>> other patches as well but those are not related to the i2c-designware or
>> acpi issues addressed here.)
>>
>> On a resume from hibernation I still see one error:
>>   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>> but I no longer get the i2c_designware timeouts, and audio does now work
>> after the resume.
>>
>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>> hardware, but perhaps this will give you a clue as to what is going
>> wrong with hibernate/resume on the T100TA's.
>
> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>

 I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
 DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
 DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
 after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
 then the timeouts go away.
>>>
>>> OK, thanks!
>>>
>>> Is non-hibernation system suspend affected too?
>>
>> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
>> applied
>> but without any changes to i2c-designware-platdrv.c, so the
>> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED 
>> flags
>> are all set.
>>
>> Suspend does work OK, and after resume I do NOT get any of the crippling
>> i2c_designware timeout errors which cause sound to fail after hibernate.  I 
>> DO see one
>>   "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
>> error on resume, just as I do on hibernate.  I've attached a portion of 
>> dmesg below.
>> The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs
>> intermittently on these machines, but doesn't seem related to the other 
>> issues.
>> I had one test run when it was absent but the rest of the messages were the
>> same -- but then kept getting that unknown key error on all my later tries.
>>
>> I did notice the "2sidle" in the following rather than "shallow" or "deep".  
>> A
>> cat of /sys/power/state shows "freeze mem disk" but a
>> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow 
>> and deep
>> are not enabled for this system.  I did check the input power (or really 
>> current)
>> as it went into suspend and the micro-usb power input drops from about
>> 0.5 amps to 0.05 amps.  But clearly a lot of devices are still active, as 
>> movement
>> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend.  That 
>> presumably is
>> why suspend doesn't trigger the same i2c_designware problems as hibernate.
>>
>> Let me know if I can do any other tests.
> 
> Can you please check if the appended patch makes the hibernate issue go away 
> for you, without any other changes?
> 
> ---
>  drivers/pci/pci-driver.c |   36 ++--
>  1 file changed, 10 insertions(+), 26 deletions(-)
> 
> Index: linux-pm/drivers/pci/pci-driver.c
> ===
> --- linux-pm.orig/drivers/pci/pci-driver.c
> +++ linux-pm/drivers/pci/pci-driver.c
> @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> }
> 
> /*
> -* This used to be done in pci_pm_prepare() for all devices and some
> -* drivers may depend on it, so do it here.  Ideally, 
> runtime-suspended
> -* devices should not be touched during freeze/thaw transitions,
> -* however.
> +* Resume all runtime-suspended devices before creating a snapshot
> +* image of system memory, because the restore kernel generally cannot
> +* be expected to always handle them consistently and pci_pm_restore()
> +* always leaves them as "active", so ensure that the state saved in 
> the
> +* image will always be consistent with that.
>  */
> -   if 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Rafael J. Wysocki]

On Thursday, May 16, 2019 6:35:40 PM CEST Robert R. Howell wrote:
> Hi Rafael
> 
> 
> On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:
> 
> > On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
> >> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
> >>
> >>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  
> >>> wrote:
> 
>  On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >
> > On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  
> > wrote:
> >>
> >> On 4/18/19 5:42 AM, Hans de Goede wrote:
> >>
>  On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >
> > Hmm, interesting so you have hibernation working on a T100TA
> > (with 5.0 + 02e45646d53b reverted), right ?
> >
> >>
> >>
> >> I've managed to find a way around the i2c_designware timeout issues
> >> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> >> which was added in the 02e45646d53b commit.
> >>
> >> To test that I've started with a 5.1-rc5 kernel, applied your recent 
> >> patch
> >> to acpi_lpss.c, then apply the following patch of mine, removing
> >> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
> >> other patches as well but those are not related to the i2c-designware 
> >> or
> >> acpi issues addressed here.)
> >>
> >> On a resume from hibernation I still see one error:
> >>   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while 
> >> suspended"
> >> but I no longer get the i2c_designware timeouts, and audio does now 
> >> work
> >> after the resume.
> >>
> >> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> >> hardware, but perhaps this will give you a clue as to what is going
> >> wrong with hibernate/resume on the T100TA's.
> >
> > What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >
> 
>  I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>  DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
>  DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>  after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>  then the timeouts go away.
> >>>
> >>> OK, thanks!
> >>>
> >>> Is non-hibernation system suspend affected too?
> >>
> >> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
> >> applied
> >> but without any changes to i2c-designware-platdrv.c, so the
> >> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and 
> >> DPM_FLAG_LEAVE_SUSPENDED flags
> >> are all set.
> >>
> >> Suspend does work OK, and after resume I do NOT get any of the crippling
> >> i2c_designware timeout errors which cause sound to fail after hibernate.  
> >> I DO see one
> >>   "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
> >> error on resume, just as I do on hibernate.  I've attached a portion of 
> >> dmesg below.
> >> The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs
> >> intermittently on these machines, but doesn't seem related to the other 
> >> issues.
> >> I had one test run when it was absent but the rest of the messages were the
> >> same -- but then kept getting that unknown key error on all my later tries.
> >>
> >> I did notice the "2sidle" in the following rather than "shallow" or 
> >> "deep".  A
> >> cat of /sys/power/state shows "freeze mem disk" but a
> >> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow 
> >> and deep
> >> are not enabled for this system.  I did check the input power (or really 
> >> current)
> >> as it went into suspend and the micro-usb power input drops from about
> >> 0.5 amps to 0.05 amps.  But clearly a lot of devices are still active, as 
> >> movement
> >> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend.  That 
> >> presumably is
> >> why suspend doesn't trigger the same i2c_designware problems as hibernate.
> >>
> >> Let me know if I can do any other tests.
> > 
> > Can you please check if the appended patch makes the hibernate issue go 
> > away for you, without any other changes?
> > 
> > ---
> >  drivers/pci/pci-driver.c |   36 ++--
> >  1 file changed, 10 insertions(+), 26 deletions(-)
> > 
> > Index: linux-pm/drivers/pci/pci-driver.c
> > ===
> > --- linux-pm.orig/drivers/pci/pci-driver.c
> > +++ linux-pm/drivers/pci/pci-driver.c
> > @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> > }
> > 
> > /*
> > -* This used to be done in pci_pm_prepare() for all devices and some
> > -* drivers may depend on it, so do it here.  Ideally, 
> > runtime-suspended
> > -* devices should not be touched during freeze/thaw transitions,
> > -* however.
> > +* Resume all runtime-suspended devices before creating a snapshot
> > +* 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

Hi Rafael


On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:

> On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>
>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:

 On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>
> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  
> wrote:
>>
>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>
 On 4/8/19 2:16 AM, Hans de Goede wrote:>
>
> Hmm, interesting so you have hibernation working on a T100TA
> (with 5.0 + 02e45646d53b reverted), right ?
>
>>
>>
>> I've managed to find a way around the i2c_designware timeout issues
>> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>> which was added in the 02e45646d53b commit.
>>
>> To test that I've started with a 5.1-rc5 kernel, applied your recent 
>> patch
>> to acpi_lpss.c, then apply the following patch of mine, removing
>> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
>> other patches as well but those are not related to the i2c-designware or
>> acpi issues addressed here.)
>>
>> On a resume from hibernation I still see one error:
>>   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>> but I no longer get the i2c_designware timeouts, and audio does now work
>> after the resume.
>>
>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>> hardware, but perhaps this will give you a clue as to what is going
>> wrong with hibernate/resume on the T100TA's.
>
> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>

 I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
 DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
 DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
 after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
 then the timeouts go away.
>>>
>>> OK, thanks!
>>>
>>> Is non-hibernation system suspend affected too?
>>
>> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
>> applied
>> but without any changes to i2c-designware-platdrv.c, so the
>> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED 
>> flags
>> are all set.
>>
>> Suspend does work OK, and after resume I do NOT get any of the crippling
>> i2c_designware timeout errors which cause sound to fail after hibernate.  I 
>> DO see one
>>   "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
>> error on resume, just as I do on hibernate.  I've attached a portion of 
>> dmesg below.
>> The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs
>> intermittently on these machines, but doesn't seem related to the other 
>> issues.
>> I had one test run when it was absent but the rest of the messages were the
>> same -- but then kept getting that unknown key error on all my later tries.
>>
>> I did notice the "2sidle" in the following rather than "shallow" or "deep".  
>> A
>> cat of /sys/power/state shows "freeze mem disk" but a
>> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow 
>> and deep
>> are not enabled for this system.  I did check the input power (or really 
>> current)
>> as it went into suspend and the micro-usb power input drops from about
>> 0.5 amps to 0.05 amps.  But clearly a lot of devices are still active, as 
>> movement
>> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend.  That 
>> presumably is
>> why suspend doesn't trigger the same i2c_designware problems as hibernate.
>>
>> Let me know if I can do any other tests.
> 
> Can you please check if the appended patch makes the hibernate issue go away 
> for you, without any other changes?
> 
> ---
>  drivers/pci/pci-driver.c |   36 ++--
>  1 file changed, 10 insertions(+), 26 deletions(-)
> 
> Index: linux-pm/drivers/pci/pci-driver.c
> ===
> --- linux-pm.orig/drivers/pci/pci-driver.c
> +++ linux-pm/drivers/pci/pci-driver.c
> @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> }
> 
> /*
> -* This used to be done in pci_pm_prepare() for all devices and some
> -* drivers may depend on it, so do it here.  Ideally, 
> runtime-suspended
> -* devices should not be touched during freeze/thaw transitions,
> -* however.
> +* Resume all runtime-suspended devices before creating a snapshot
> +* image of system memory, because the restore kernel generally cannot
> +* be expected to always handle them consistently and pci_pm_restore()
> +* always leaves them as "active", so ensure that the state saved in 
> the
> +* image will always be consistent with that.
>  */
> -   if 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

Hi Hans

On 5/13/19 2:41 AM, Hans de Goede wrote:

> 
> Hi Robert,
> 
> On 09-05-19 20:09, Robert R. Howell wrote:
>> Hi Hans
>>
>> On 5/9/19 2:50 AM, Hans de Goede wrote:
>>
>>>
>>> Hi,
>>>
>>> On 09-05-19 06:24, Robert R. Howell wrote:
 On 4/30/19 8:39 AM, Hans de Goede wrote:
>
>>
>
> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" 
> error
> on suspend/resume on my own T100TA and I could not reproduce this.
>
> Can you try without the BT keyboard paired and waking up from suspend 
> using the
> tablet part's power-button ?
>
> Also do you still have the scripts to rmmod some modules before suspend ?
>

 The T100TA keyboard is actually a hardwired connection rather than 
 Bluetooth but I
 did physically disconnect the keyboard, and also unpaired all the actual 
 Bluetooth
 devices (such as the mouse) and then powered down the T100TA bluetooth 
 adapter.
 When I suspend, then resume using the tablet power button, I still get the
 i2c_dw_xfererror error during the resume.  But whatever causes this error 
 isn't fatal,
 in the sense that after resume the sound and other i2c functions do still 
 work OK.

 While I always get this i2c_dw_xfer error on resume from suspend or 
 hibernation on the T100TA,
 I also have a T100TAM and curiously, it NEVER shows that error -- although 
 all the
 other suspend and hibernate behavior seems similar.  I'm not sure if the 
 following could
 be the difference, but the T100TA uses an i2c connected ATML1000 
 touchscreen controller
 while the T100TAM uses an i2c connected SIS0817 touchscreen controller.  
 Other than that
 the hardware seems almost identical.
>>>
>>> I've been testing on an actual T100TA, with the ATML1000 touchscreen 
>>> controller.
>>>
>>> Maybe it is a difference in BIOS version, my T100TA is running the latest 
>>> BIOS, what
>>> is the output of:
>>>
>>> cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
>>>
>> On the T100TA which shows the i2c_dw_xfer error the above cat reports:
>> T100TA.307
>> 05/09/2014
>>
>> while the T100TA which does NOT show the i2c_dw_xfer error reports:
>> T100TAM.205
>> 07/25/2014
>>>
>>> Also do you perhaps have a microsd card inserted?  (I'm trying to figure 
>>> out the
>>> different between our setups so that I can hopefully reproduce the issue 
>>> myself).
>>>
>> I do have a microsd card inserted in both the T100TA and the T100TAM.
> 
> Ah, ok I already suspected that and I think that is the difference between our
> 2 setups. I will try to reproduce the suspend/resume problem again with a 
> microsd
> card inserted and mounted.
> 
 Regarding scripts, while I do still need a systemd hibernate script which 
 removes the
 brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I 
 no longer need
 any script for suspend.
>>>
>>> Ok, so you are not doing any rmmod-s on suspend, right?
>>>
>> Correct -- I am NOT using a script and am not doing any explicit rmmod's on 
>> suspend, just on hibernate.
>>> Regards,
>>>
>>> Hans
>>
>> All my previous tests were done using a 5.1.0-rc5, 5.1.0-rc3, or earlier 
>> kernel.
>> But I just compiled the released 5.1.0 kernel and the behavior has changed 
>> for the T100TA,
>> resulting in a different i2c error and a call trace.  (I still continue to 
>> NOT see any
>> suspend/resume errors on the T100TAM.)
> 
> This is expected we changed / improved the code generating the:
> "i2c_designware 80860F41:00: Transfer while suspended"
> 
> Warning to include a trace, so that we know which code initiated the transfer,
> which, as more or less expected, is the ACPI subsystem, like some power_on 
> (_PS0)
> or off (_PS3) method.
> 
>> Note that for all the tests described in this message I'm applying your patch
>> regarding .poweroff_noirq and .restore_noirq, and I'm applying my own patch 
>> removing the
>> DPM_FLAG_SMART_SUSPEND flag.  I haven't yet tried to explore varying those 
>> patches
>> for the 5.1.0 release as I did for the earlier rc's, as described in 
>> previous messages.
> 
> Hmm, for future testing please leave out the patch removing the 
> DPM_FLAG_SMART_SUSPEND
> flag. Usually when asking you to test something we assume you are using a 
> pristine kernel.
> What does that patch attempt to fix and what happens during suspend/resume 
> without it ?
> 
Removing the DPM_FLAG_SMART_SUSPEND fixes an i2c_designware timeout on the 
T100TA and TAM systems 
when resuming from hibernation.  That's detailed in an earlier message of mine 
in this thread, and also 
is quoted more completely in a reply I'm about to send to Rafael.  From a 
usability perspective the
resume-from-hibernate i2c_designware timeout errors were more serious, since 
they disabled sound 
till I rebooted, while the suspend/resume "Transfer while suspended" error was 
just a minor 
annoyance in the 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Rafael J. Wysocki]

On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
> 
> > On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:
> >>
> >> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >>>
> >>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  
> >>> wrote:
> 
>  On 4/18/19 5:42 AM, Hans de Goede wrote:
> 
> >> On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >>>
> >>> Hmm, interesting so you have hibernation working on a T100TA
> >>> (with 5.0 + 02e45646d53b reverted), right ?
> >>>
> 
> 
>  I've managed to find a way around the i2c_designware timeout issues
>  on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>  which was added in the 02e45646d53b commit.
> 
>  To test that I've started with a 5.1-rc5 kernel, applied your recent 
>  patch
>  to acpi_lpss.c, then apply the following patch of mine, removing
>  DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
>  other patches as well but those are not related to the i2c-designware or
>  acpi issues addressed here.)
> 
>  On a resume from hibernation I still see one error:
>    "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>  but I no longer get the i2c_designware timeouts, and audio does now work
>  after the resume.
> 
>  Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>  hardware, but perhaps this will give you a clue as to what is going
>  wrong with hibernate/resume on the T100TA's.
> >>>
> >>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >>>
> >>
> >> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
> >> DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
> >> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
> >> after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
> >> then the timeouts go away.
> > 
> > OK, thanks!
> > 
> > Is non-hibernation system suspend affected too?
> 
> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
> applied 
> but without any changes to i2c-designware-platdrv.c, so the 
> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED 
> flags 
> are all set.  
> 
> Suspend does work OK, and after resume I do NOT get any of the crippling 
> i2c_designware timeout errors which cause sound to fail after hibernate.  I 
> DO see one 
>   "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
> error on resume, just as I do on hibernate.  I've attached a portion of dmesg 
> below.
> The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs 
> intermittently on these machines, but doesn't seem related to the other 
> issues.  
> I had one test run when it was absent but the rest of the messages were the 
> same -- but then kept getting that unknown key error on all my later tries.
> 
> I did notice the "2sidle" in the following rather than "shallow" or "deep".  A
> cat of /sys/power/state shows "freeze mem disk" but a
> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow 
> and deep 
> are not enabled for this system.  I did check the input power (or really 
> current) 
> as it went into suspend and the micro-usb power input drops from about 
> 0.5 amps to 0.05 amps.  But clearly a lot of devices are still active, as 
> movement 
> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend.  That 
> presumably is 
> why suspend doesn't trigger the same i2c_designware problems as hibernate.
> 
> Let me know if I can do any other tests.

Can you please check if the appended patch makes the hibernate issue go away 
for you, without any other changes?

---
 drivers/pci/pci-driver.c |   36 ++--
 1 file changed, 10 insertions(+), 26 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
}
 
/*
-* This used to be done in pci_pm_prepare() for all devices and some
-* drivers may depend on it, so do it here.  Ideally, runtime-suspended
-* devices should not be touched during freeze/thaw transitions,
-* however.
+* Resume all runtime-suspended devices before creating a snapshot
+* image of system memory, because the restore kernel generally cannot
+* be expected to always handle them consistently and pci_pm_restore()
+* always leaves them as "active", so ensure that the state saved in the
+* image will always be consistent with that.
 */
-   if (!dev_pm_smart_suspend_and_suspended(dev)) {
-   pm_runtime_resume(dev);
-   pci_dev->state_saved = false;
-   }
+   

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hi,

On 5/9/19 8:09 PM, Robert R. Howell wrote:

Hi Hans

On 5/9/19 2:50 AM, Hans de Goede wrote:



Hi,

On 09-05-19 06:24, Robert R. Howell wrote:

On 4/30/19 8:39 AM, Hans de Goede wrote:






I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
on suspend/resume on my own T100TA and I could not reproduce this.

Can you try without the BT keyboard paired and waking up from suspend using the
tablet part's power-button ?

Also do you still have the scripts to rmmod some modules before suspend ?



The T100TA keyboard is actually a hardwired connection rather than Bluetooth 
but I
did physically disconnect the keyboard, and also unpaired all the actual 
Bluetooth
devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
When I suspend, then resume using the tablet power button, I still get the
i2c_dw_xfererror error during the resume.  But whatever causes this error isn't 
fatal,
in the sense that after resume the sound and other i2c functions do still work 
OK.

While I always get this i2c_dw_xfer error on resume from suspend or hibernation 
on the T100TA,
I also have a T100TAM and curiously, it NEVER shows that error -- although all 
the
other suspend and hibernate behavior seems similar.  I'm not sure if the 
following could
be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen 
controller
while the T100TAM uses an i2c connected SIS0817 touchscreen controller.  Other 
than that
the hardware seems almost identical.


I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.

Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, 
what
is the output of:

cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date


On the T100TA which shows the i2c_dw_xfer error the above cat reports:
T100TA.307
05/09/2014


My T100TA has version T100TA.314, date 08/13/2015


while the T100TA which does NOT show the i2c_dw_xfer error reports:
T100TAM.205
07/25/2014


Also do you perhaps have a microsd card inserted?  (I'm trying to figure out the
different between our setups so that I can hopefully reproduce the issue 
myself).


I do have a microsd card inserted in both the T100TA and the T100TAM.


Ok, so I tried reproducing the suspend/resume problem on my T100TA with a 
microsd
inserted and mounted and I still cannot reproduce the problem. So either you are
hitting a BIOS bug which since has been fixed, or the suspend/resume
problem is caused by you removing the DPM_FLAG_SMART_SUSPEND flag.

Regards,

Hans

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hi Robert,

On 09-05-19 20:09, Robert R. Howell wrote:

Hi Hans

On 5/9/19 2:50 AM, Hans de Goede wrote:



Hi,

On 09-05-19 06:24, Robert R. Howell wrote:

On 4/30/19 8:39 AM, Hans de Goede wrote:






I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
on suspend/resume on my own T100TA and I could not reproduce this.

Can you try without the BT keyboard paired and waking up from suspend using the
tablet part's power-button ?

Also do you still have the scripts to rmmod some modules before suspend ?



The T100TA keyboard is actually a hardwired connection rather than Bluetooth 
but I
did physically disconnect the keyboard, and also unpaired all the actual 
Bluetooth
devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
When I suspend, then resume using the tablet power button, I still get the
i2c_dw_xfererror error during the resume.  But whatever causes this error isn't 
fatal,
in the sense that after resume the sound and other i2c functions do still work 
OK.

While I always get this i2c_dw_xfer error on resume from suspend or hibernation 
on the T100TA,
I also have a T100TAM and curiously, it NEVER shows that error -- although all 
the
other suspend and hibernate behavior seems similar.  I'm not sure if the 
following could
be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen 
controller
while the T100TAM uses an i2c connected SIS0817 touchscreen controller.  Other 
than that
the hardware seems almost identical.


I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.

Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, 
what
is the output of:

cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date


On the T100TA which shows the i2c_dw_xfer error the above cat reports:
T100TA.307
05/09/2014

while the T100TA which does NOT show the i2c_dw_xfer error reports:
T100TAM.205
07/25/2014


Also do you perhaps have a microsd card inserted?  (I'm trying to figure out the
different between our setups so that I can hopefully reproduce the issue 
myself).


I do have a microsd card inserted in both the T100TA and the T100TAM.


Ah, ok I already suspected that and I think that is the difference between our
2 setups. I will try to reproduce the suspend/resume problem again with a 
microsd
card inserted and mounted.


Regarding scripts, while I do still need a systemd hibernate script which 
removes the
brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no 
longer need
any script for suspend.


Ok, so you are not doing any rmmod-s on suspend, right?


Correct -- I am NOT using a script and am not doing any explicit rmmod's on 
suspend, just on hibernate.

Regards,

Hans


All my previous tests were done using a 5.1.0-rc5, 5.1.0-rc3, or earlier kernel.
But I just compiled the released 5.1.0 kernel and the behavior has changed for 
the T100TA,
resulting in a different i2c error and a call trace.  (I still continue to NOT 
see any
suspend/resume errors on the T100TAM.)


This is expected we changed / improved the code generating the:
"i2c_designware 80860F41:00: Transfer while suspended"

Warning to include a trace, so that we know which code initiated the transfer,
which, as more or less expected, is the ACPI subsystem, like some power_on 
(_PS0)
or off (_PS3) method.


Note that for all the tests described in this message I'm applying your patch
regarding .poweroff_noirq and .restore_noirq, and I'm applying my own patch 
removing the
DPM_FLAG_SMART_SUSPEND flag.  I haven't yet tried to explore varying those 
patches
for the 5.1.0 release as I did for the earlier rc's, as described in previous 
messages.


Hmm, for future testing please leave out the patch removing the 
DPM_FLAG_SMART_SUSPEND
flag. Usually when asking you to test something we assume you are using a 
pristine kernel.
What does that patch attempt to fix and what happens during suspend/resume 
without it ?

Regards,

Hans

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

Hi Hans

On 5/9/19 2:50 AM, Hans de Goede wrote:

> 
> Hi,
> 
> On 09-05-19 06:24, Robert R. Howell wrote:
>> On 4/30/19 8:39 AM, Hans de Goede wrote:
>>>

>>>
>>> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" 
>>> error
>>> on suspend/resume on my own T100TA and I could not reproduce this.
>>>
>>> Can you try without the BT keyboard paired and waking up from suspend using 
>>> the
>>> tablet part's power-button ?
>>>
>>> Also do you still have the scripts to rmmod some modules before suspend ?
>>>
>>
>> The T100TA keyboard is actually a hardwired connection rather than Bluetooth 
>> but I
>> did physically disconnect the keyboard, and also unpaired all the actual 
>> Bluetooth
>> devices (such as the mouse) and then powered down the T100TA bluetooth 
>> adapter.
>> When I suspend, then resume using the tablet power button, I still get the
>> i2c_dw_xfererror error during the resume.  But whatever causes this error 
>> isn't fatal,
>> in the sense that after resume the sound and other i2c functions do still 
>> work OK.
>>
>> While I always get this i2c_dw_xfer error on resume from suspend or 
>> hibernation on the T100TA,
>> I also have a T100TAM and curiously, it NEVER shows that error -- although 
>> all the
>> other suspend and hibernate behavior seems similar.  I'm not sure if the 
>> following could
>> be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen 
>> controller
>> while the T100TAM uses an i2c connected SIS0817 touchscreen controller.  
>> Other than that
>> the hardware seems almost identical.
> 
> I've been testing on an actual T100TA, with the ATML1000 touchscreen 
> controller.
> 
> Maybe it is a difference in BIOS version, my T100TA is running the latest 
> BIOS, what
> is the output of:
> 
> cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
> 
On the T100TA which shows the i2c_dw_xfer error the above cat reports:
T100TA.307
05/09/2014

while the T100TA which does NOT show the i2c_dw_xfer error reports:
T100TAM.205
07/25/2014
> 
> Also do you perhaps have a microsd card inserted?  (I'm trying to figure out 
> the
> different between our setups so that I can hopefully reproduce the issue 
> myself).
>
I do have a microsd card inserted in both the T100TA and the T100TAM.
> 
>> Regarding scripts, while I do still need a systemd hibernate script which 
>> removes the
>> brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no 
>> longer need
>> any script for suspend.
> 
> Ok, so you are not doing any rmmod-s on suspend, right?
> 
Correct -- I am NOT using a script and am not doing any explicit rmmod's on 
suspend, just on hibernate.
> Regards,
> 
> Hans

All my previous tests were done using a 5.1.0-rc5, 5.1.0-rc3, or earlier 
kernel.  
But I just compiled the released 5.1.0 kernel and the behavior has changed for 
the T100TA,
resulting in a different i2c error and a call trace.  (I still continue to NOT 
see any 
suspend/resume errors on the T100TAM.)

Note that for all the tests described in this message I'm applying your patch 
regarding .poweroff_noirq and .restore_noirq, and I'm applying my own patch 
removing the 
DPM_FLAG_SMART_SUSPEND flag.  I haven't yet tried to explore varying those 
patches 
for the 5.1.0 release as I did for the earlier rc's, as described in previous 
messages.

On the 5.1.0-rc5 and earlier kernels running on the T100TA I consistently get 
the 
 "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
error on every resume from suspend, but I've never seen the errors I'm about 
to report for the new release kernel.  I've rebooted my T100TA using 5.1.0-rc5 
several times to confirm that old behavior is still true.

With my newly compiled 5.1.0 release on the T100TA I now see a different i2c 
error on 
the very first suspend/resume cycle after booting.  However subsequent 
suspend/resume 
cycles do not show any errors, neither the one seen on the first cycle, nor the 
i2c_dw_xfer errors seen under 5.1.0-rc5.  I've rebooted a number of times to 
see if the 
behavior is consistent, and it always seems to follow the pattern of the error 
and 
call trace on just the first suspend/resume cycle.  

Obviously something has changed in the relevant code between 5.1.0-rc5 and 
5.1.0 release.  
Since the behavior it is consistent, if the following dmesg output isn't enough 
to sort 
that out I can try building the intermediate rc6 and rc7, or run a more 
detailed bisect.  
But because this new error results in a call trace, perhaps that will be enough 
to determine 
what is going wrong.

Once again, let me know if I can do any further tests, or if you want a full 
copy of 
the (earlier parts of the) dmesg output.

Bob

--- dmesg output from a T100TA running 5.1.0 (released) where the first 
suspend/resume cycle results 
--- in an "i2c_designware 80860F41:00: Transfer while suspended" error but 
subsequent cycles work OK.  

[   35.818537] Bluetooth: RFCOMM ver 1.11
[   

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hi,

On 09-05-19 06:24, Robert R. Howell wrote:

On 4/30/19 8:39 AM, Hans de Goede wrote:


Hi,

On 4/25/19 6:38 PM, Robert R. Howell wrote:

On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:


On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:


On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:


On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  wrote:


On 4/18/19 5:42 AM, Hans de Goede wrote:


On 4/8/19 2:16 AM, Hans de Goede wrote:>


Hmm, interesting so you have hibernation working on a T100TA
(with 5.0 + 02e45646d53b reverted), right ?




I've managed to find a way around the i2c_designware timeout issues
on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
which was added in the 02e45646d53b commit.

To test that I've started with a 5.1-rc5 kernel, applied your recent patch
to acpi_lpss.c, then apply the following patch of mine, removing
DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
other patches as well but those are not related to the i2c-designware or
acpi issues addressed here.)

On a resume from hibernation I still see one error:
    "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
but I no longer get the i2c_designware timeouts, and audio does now work
after the resume.

Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
hardware, but perhaps this will give you a clue as to what is going
wrong with hibernate/resume on the T100TA's.


What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?



I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
then the timeouts go away.


OK, thanks!

Is non-hibernation system suspend affected too?


I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
applied
but without any changes to i2c-designware-platdrv.c, so the
DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED 
flags
are all set.

Suspend does work OK, and after resume I do NOT get any of the crippling
i2c_designware timeout errors which cause sound to fail after hibernate.  I DO 
see one
    "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
error on resume, just as I do on hibernate.  I've attached a portion of dmesg 
below.
The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs
intermittently on these machines, but doesn't seem related to the other issues.
I had one test run when it was absent but the rest of the messages were the
same -- but then kept getting that unknown key error on all my later tries.


I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
on suspend/resume on my own T100TA and I could not reproduce this.

Can you try without the BT keyboard paired and waking up from suspend using the
tablet part's power-button ?

Also do you still have the scripts to rmmod some modules before suspend ?



The T100TA keyboard is actually a hardwired connection rather than Bluetooth 
but I
did physically disconnect the keyboard, and also unpaired all the actual 
Bluetooth
devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
When I suspend, then resume using the tablet power button, I still get the
i2c_dw_xfererror error during the resume.  But whatever causes this error isn't 
fatal,
in the sense that after resume the sound and other i2c functions do still work 
OK.

While I always get this i2c_dw_xfer error on resume from suspend or hibernation 
on the T100TA,
I also have a T100TAM and curiously, it NEVER shows that error -- although all 
the
other suspend and hibernate behavior seems similar.  I'm not sure if the 
following could
be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen 
controller
while the T100TAM uses an i2c connected SIS0817 touchscreen controller.  Other 
than that
the hardware seems almost identical.


I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.

Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, 
what
is the output of:

cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date

?

Also do you perhaps have a microsd card inserted?  (I'm trying to figure out the
different between our setups so that I can hopefully reproduce the issue 
myself).



Regarding scripts, while I do still need a systemd hibernate script which 
removes the
brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no 
longer need
any script for suspend.


Ok, so you are not doing any rmmod-s on suspend, right?

Regards,

Hans

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/30/19 8:39 AM, Hans de Goede wrote:
> 
> Hi,
> 
> On 4/25/19 6:38 PM, Robert R. Howell wrote:
>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>
>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:

 On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>
> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  
> wrote:
>>
>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>
 On 4/8/19 2:16 AM, Hans de Goede wrote:>
>
> Hmm, interesting so you have hibernation working on a T100TA
> (with 5.0 + 02e45646d53b reverted), right ?
>
>>
>>
>> I've managed to find a way around the i2c_designware timeout issues
>> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>> which was added in the 02e45646d53b commit.
>>
>> To test that I've started with a 5.1-rc5 kernel, applied your recent 
>> patch
>> to acpi_lpss.c, then apply the following patch of mine, removing
>> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
>> other patches as well but those are not related to the i2c-designware or
>> acpi issues addressed here.)
>>
>> On a resume from hibernation I still see one error:
>>    "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>> but I no longer get the i2c_designware timeouts, and audio does now work
>> after the resume.
>>
>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>> hardware, but perhaps this will give you a clue as to what is going
>> wrong with hibernate/resume on the T100TA's.
>
> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>

 I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
 DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
 DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
 after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
 then the timeouts go away.
>>>
>>> OK, thanks!
>>>
>>> Is non-hibernation system suspend affected too?
>>
>> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
>> applied
>> but without any changes to i2c-designware-platdrv.c, so the
>> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED 
>> flags
>> are all set.
>>
>> Suspend does work OK, and after resume I do NOT get any of the crippling
>> i2c_designware timeout errors which cause sound to fail after hibernate.  I 
>> DO see one
>>    "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
>> error on resume, just as I do on hibernate.  I've attached a portion of 
>> dmesg below.
>> The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs
>> intermittently on these machines, but doesn't seem related to the other 
>> issues.
>> I had one test run when it was absent but the rest of the messages were the
>> same -- but then kept getting that unknown key error on all my later tries.
> 
> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" 
> error
> on suspend/resume on my own T100TA and I could not reproduce this.
> 
> Can you try without the BT keyboard paired and waking up from suspend using 
> the
> tablet part's power-button ?
> 
> Also do you still have the scripts to rmmod some modules before suspend ?
> 

The T100TA keyboard is actually a hardwired connection rather than Bluetooth 
but I
did physically disconnect the keyboard, and also unpaired all the actual 
Bluetooth 
devices (such as the mouse) and then powered down the T100TA bluetooth adapter. 
When I suspend, then resume using the tablet power button, I still get the 
i2c_dw_xfererror error during the resume.  But whatever causes this error isn't 
fatal, 
in the sense that after resume the sound and other i2c functions do still work 
OK.

While I always get this i2c_dw_xfer error on resume from suspend or hibernation 
on the T100TA, 
I also have a T100TAM and curiously, it NEVER shows that error -- although all 
the 
other suspend and hibernate behavior seems similar.  I'm not sure if the 
following could 
be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen 
controller 
while the T100TAM uses an i2c connected SIS0817 touchscreen controller.  Other 
than that 
the hardware seems almost identical.

Regarding scripts, while I do still need a systemd hibernate script which 
removes the 
brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no 
longer need 
any script for suspend.

>> I did notice the "2sidle" in the following rather than "shallow" or "deep".  
>> A
>> cat of /sys/power/state shows "freeze mem disk" but a
>> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow 
>> and deep
>> are not enabled for this system.  I did check the input power (or really 
>> current)
>> as it went into suspend and the micro-usb power input drops from about
>> 0.5 amps to 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hi,

On 4/25/19 6:38 PM, Robert R. Howell wrote:

On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:


On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:


On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:


On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  wrote:


On 4/18/19 5:42 AM, Hans de Goede wrote:


On 4/8/19 2:16 AM, Hans de Goede wrote:>


Hmm, interesting so you have hibernation working on a T100TA
(with 5.0 + 02e45646d53b reverted), right ?




I've managed to find a way around the i2c_designware timeout issues
on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
which was added in the 02e45646d53b commit.

To test that I've started with a 5.1-rc5 kernel, applied your recent patch
to acpi_lpss.c, then apply the following patch of mine, removing
DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
other patches as well but those are not related to the i2c-designware or
acpi issues addressed here.)

On a resume from hibernation I still see one error:
   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
but I no longer get the i2c_designware timeouts, and audio does now work
after the resume.

Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
hardware, but perhaps this will give you a clue as to what is going
wrong with hibernate/resume on the T100TA's.


What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?



I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
then the timeouts go away.


OK, thanks!

Is non-hibernation system suspend affected too?


I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
applied
but without any changes to i2c-designware-platdrv.c, so the
DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED 
flags
are all set.

Suspend does work OK, and after resume I do NOT get any of the crippling
i2c_designware timeout errors which cause sound to fail after hibernate.  I DO 
see one
   "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
error on resume, just as I do on hibernate.  I've attached a portion of dmesg 
below.
The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs
intermittently on these machines, but doesn't seem related to the other issues.
I had one test run when it was absent but the rest of the messages were the
same -- but then kept getting that unknown key error on all my later tries.


I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
on suspend/resume on my own T100TA and I could not reproduce this.

Can you try without the BT keyboard paired and waking up from suspend using the
tablet part's power-button ?

Also do you still have the scripts to rmmod some modules before suspend ?


I did notice the "2sidle" in the following rather than "shallow" or "deep".  A
cat of /sys/power/state shows "freeze mem disk" but a
cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and 
deep
are not enabled for this system.  I did check the input power (or really 
current)
as it went into suspend and the micro-usb power input drops from about
0.5 amps to 0.05 amps.  But clearly a lot of devices are still active, as 
movement
of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend.  That 
presumably is
why suspend doesn't trigger the same i2c_designware problems as hibernate.


s2idle is the normal / expected suspend condition on these tablet devices.

As for how much energy is consumed during suspend, the device should use
S0i3 and then you should get ok (so not great, but also not too much) power
consumption during suspend:

[root@dhcp-43-189 ~]# cat /sys/kernel/debug/pmc_atom/sleep_state
S0IR Residency: 156256us
S0I1 Residency: 3968us
S0I2 Residency: 0us
S0I3 Residency: 70557440us
S0   Residency: 11826052384us

After being suspended for a couple of seconds, you should see a significant
(large) value in S0I3 like above.

Regards,

Hans








Let me know if I can do any other tests.

Bob Howell

DMESG OUTPUT ON SUSPEND--
[   71.791495] NET: Registered protocol family 38
[   73.150736] input: MX Anywhere 2 Keyboard as 
/devices/virtual/misc/uhid/0005:046D:B013.0005/input/input24
[   73.156612] input: MX Anywhere 2 Mouse as 
/devices/virtual/misc/uhid/0005:046D:B013.0005/input/input25
[   73.159504] hid-generic 0005:046D:B013.0005: input,hidraw4: BLUETOOTH HID 
v0.07 Keyboard [MX Anywhere 2] on 74:D0:2B:DF:77:E9
[  102.719170] asus_wmi: Unknown key 79 pressed
[  102.897214] asus_wmi: Unknown key 79 pressed
[  104.298409] PM: suspend entry (s2idle)
[  104.298414] PM: Syncing filesystems ... done.
[  105.410883] Freezing user space processes ... (elapsed 0.002 seconds) done.
[  105.413556] OOM killer disabled.
[  105.413558] Freezing 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:

> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:
>>
>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>>>
>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  wrote:

 On 4/18/19 5:42 AM, Hans de Goede wrote:

>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>
>>> Hmm, interesting so you have hibernation working on a T100TA
>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>


 I've managed to find a way around the i2c_designware timeout issues
 on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
 which was added in the 02e45646d53b commit.

 To test that I've started with a 5.1-rc5 kernel, applied your recent patch
 to acpi_lpss.c, then apply the following patch of mine, removing
 DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
 other patches as well but those are not related to the i2c-designware or
 acpi issues addressed here.)

 On a resume from hibernation I still see one error:
   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
 but I no longer get the i2c_designware timeouts, and audio does now work
 after the resume.

 Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
 hardware, but perhaps this will give you a clue as to what is going
 wrong with hibernate/resume on the T100TA's.
>>>
>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>>>
>>
>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>> DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>> after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>> then the timeouts go away.
> 
> OK, thanks!
> 
> Is non-hibernation system suspend affected too?

I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch 
applied 
but without any changes to i2c-designware-platdrv.c, so the 
DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED 
flags 
are all set.  

Suspend does work OK, and after resume I do NOT get any of the crippling 
i2c_designware timeout errors which cause sound to fail after hibernate.  I DO 
see one 
  "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
error on resume, just as I do on hibernate.  I've attached a portion of dmesg 
below.
The "asus_wmi:  Unknown key 79 pressed" error is a glitch which occurs 
intermittently on these machines, but doesn't seem related to the other issues. 
 
I had one test run when it was absent but the rest of the messages were the 
same -- but then kept getting that unknown key error on all my later tries.

I did notice the "2sidle" in the following rather than "shallow" or "deep".  A
cat of /sys/power/state shows "freeze mem disk" but a
cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and 
deep 
are not enabled for this system.  I did check the input power (or really 
current) 
as it went into suspend and the micro-usb power input drops from about 
0.5 amps to 0.05 amps.  But clearly a lot of devices are still active, as 
movement 
of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend.  That 
presumably is 
why suspend doesn't trigger the same i2c_designware problems as hibernate.

Let me know if I can do any other tests.

Bob Howell

DMESG OUTPUT ON SUSPEND--
[   71.791495] NET: Registered protocol family 38
[   73.150736] input: MX Anywhere 2 Keyboard as 
/devices/virtual/misc/uhid/0005:046D:B013.0005/input/input24
[   73.156612] input: MX Anywhere 2 Mouse as 
/devices/virtual/misc/uhid/0005:046D:B013.0005/input/input25
[   73.159504] hid-generic 0005:046D:B013.0005: input,hidraw4: BLUETOOTH HID 
v0.07 Keyboard [MX Anywhere 2] on 74:D0:2B:DF:77:E9
[  102.719170] asus_wmi: Unknown key 79 pressed
[  102.897214] asus_wmi: Unknown key 79 pressed
[  104.298409] PM: suspend entry (s2idle)
[  104.298414] PM: Syncing filesystems ... done.
[  105.410883] Freezing user space processes ... (elapsed 0.002 seconds) done.
[  105.413556] OOM killer disabled.
[  105.413558] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[  123.353720] i2c_designware 80860F41:00: Error i2c_dw_xfer call while 
suspended
[  123.635028] ACPI: button: The lid device is not compliant to SW_LID.
[  124.086421] OOM killer enabled.
[  124.086491] Restarting tasks ... done.
[  124.120647] PM: suspend exit
[  124.939566] asus_wmi: Unknown key 79 pressed

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Rafael J. Wysocki]

On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell  wrote:
>
> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >
> > On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  wrote:
> >>
> >> On 4/18/19 5:42 AM, Hans de Goede wrote:
> >>
>  On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >
> > Hmm, interesting so you have hibernation working on a T100TA
> > (with 5.0 + 02e45646d53b reverted), right ?
> >
> >>
> >>
> >> I've managed to find a way around the i2c_designware timeout issues
> >> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> >> which was added in the 02e45646d53b commit.
> >>
> >> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
> >> to acpi_lpss.c, then apply the following patch of mine, removing
> >> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
> >> other patches as well but those are not related to the i2c-designware or
> >> acpi issues addressed here.)
> >>
> >> On a resume from hibernation I still see one error:
> >>   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
> >> but I no longer get the i2c_designware timeouts, and audio does now work
> >> after the resume.
> >>
> >> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> >> hardware, but perhaps this will give you a clue as to what is going
> >> wrong with hibernate/resume on the T100TA's.
> >
> > What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >
>
> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
> DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop
> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
> after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
> then the timeouts go away.

OK, thanks!

Is non-hibernation system suspend affected too?

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> 
> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  wrote:
>>
>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>
 On 4/8/19 2:16 AM, Hans de Goede wrote:>
>
> Hmm, interesting so you have hibernation working on a T100TA
> (with 5.0 + 02e45646d53b reverted), right ?
>
>>
>>
>> I've managed to find a way around the i2c_designware timeout issues
>> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>> which was added in the 02e45646d53b commit.
>>
>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>> to acpi_lpss.c, then apply the following patch of mine, removing
>> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
>> other patches as well but those are not related to the i2c-designware or
>> acpi issues addressed here.)
>>
>> On a resume from hibernation I still see one error:
>>   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>> but I no longer get the i2c_designware timeouts, and audio does now work
>> after the resume.
>>
>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>> hardware, but perhaps this will give you a clue as to what is going
>> wrong with hibernate/resume on the T100TA's.
> 
> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> 

I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just 
DPM_FLAG_SMART_SUSPEND, and dropping both flags.  When I just drop 
DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts 
after the resume.  If I drop just DPM_FLAG_SMART_SUSPEND or drop both, 
then the timeouts go away.

Bob Howell

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Rafael J. Wysocki]

On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell  wrote:
>
> On 4/18/19 5:42 AM, Hans de Goede wrote:
>
> >> On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >>>
> >>> Hmm, interesting so you have hibernation working on a T100TA
> >>> (with 5.0 + 02e45646d53b reverted), right ?
> >>>
>
> > Still since my patch is regressing things for you I will try to
> > take a look at this and see if I can reproduce and come up with
> > a fix. But this is not going to be a high priority thing for me to
> > work on.
> >
> > In the mean time I've gone ahead and submitted my version of the
> > fix for the problem Kai-Heng was seeing, since that does not seem
> > to make your problem worse; and it will be good to get that problem
> > fixed.
> >
> > Regards,
> >
> > Hans
> >
>
> I've managed to find a way around the i2c_designware timeout issues
> on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> which was added in the 02e45646d53b commit.
>
> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
> to acpi_lpss.c, then apply the following patch of mine, removing
> DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some
> other patches as well but those are not related to the i2c-designware or
> acpi issues addressed here.)
>
> On a resume from hibernation I still see one error:
>   "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
> but I no longer get the i2c_designware timeouts, and audio does now work
> after the resume.
>
> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> hardware, but perhaps this will give you a clue as to what is going
> wrong with hibernate/resume on the T100TA's.

What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/18/19 5:42 AM, Hans de Goede wrote:

>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>
>>> Hmm, interesting so you have hibernation working on a T100TA
>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>

> Still since my patch is regressing things for you I will try to
> take a look at this and see if I can reproduce and come up with
> a fix. But this is not going to be a high priority thing for me to
> work on.
> 
> In the mean time I've gone ahead and submitted my version of the
> fix for the problem Kai-Heng was seeing, since that does not seem
> to make your problem worse; and it will be good to get that problem
> fixed.
> 
> Regards,
> 
> Hans
> 

I've managed to find a way around the i2c_designware timeout issues
on the T100TA's.  The key is to NOT set DPM_FLAG_SMART_SUSPEND,
which was added in the 02e45646d53b commit.

To test that I've started with a 5.1-rc5 kernel, applied your recent patch
to acpi_lpss.c, then apply the following patch of mine, removing 
DPM_FLAG_SMART_SUSPEND.  (For the T100 hardware I need to apply some 
other patches as well but those are not related to the i2c-designware or 
acpi issues addressed here.)  

On a resume from hibernation I still see one error:
  "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
but I no longer get the i2c_designware timeouts, and audio does now work
after the resume.

Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other 
hardware, but perhaps this will give you a clue as to what is going
wrong with hibernate/resume on the T100TA's.

With the above now working I've also experimented with my systemd
hibernate script and at least in limited testing I only need to
remove the brcmfmac and hci_uart drivers before hibernate.
I no longer need to remove sound drivers or the other ones shown in 
my earlier script.  Without more testing I'm not sure at what point
in kernel development those other driver removals stopped being necessary.

Let me know if I can do any other tests to help.

Bob Howell



---
diff -uprN linux_original/drivers/i2c/busses/i2c-designware-platdrv.c 
linux/drivers/i2c/busses/i2c-designware-platdrv.c
--- linux_original/drivers/i2c/busses/i2c-designware-platdrv.c  2019-04-14 
16:17:41.0 -0600
+++ linux/drivers/i2c/busses/i2c-designware-platdrv.c   2019-04-18 
22:45:58.836246889 -0600
@@ -367,7 +367,6 @@ static int dw_i2c_plat_probe(struct plat

dev_pm_set_driver_flags(>dev,
DPM_FLAG_SMART_PREPARE |
-   DPM_FLAG_SMART_SUSPEND |
DPM_FLAG_LEAVE_SUSPENDED);

/* The code below assumes runtime PM to be disabled. */
---

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hello Robert,

On 11-04-19 21:50, Robert R. Howell wrote:

On 4/8/19 2:16 AM, Hans de Goede wrote:>


Hmm, interesting so you have hibernation working on a T100TA
(with 5.0 + 02e45646d53b reverted), right ?


Hi Hans and Kai-Heng

First, apologies for how long it took me to reply to both your inquiries.
In trying to answer them I discovered some inconsistencies in how the T100TA was
behaving on different hibernation attempts and I've been trying to sort those 
out.
I haven't been completely successful in that, but here's a brief summary.

Yes I do have hibernation working (at least most of the time) on a T100TA,
with 5.0 + 02e45646d53b reverted (more about that below), and with a systemd
hibernate script also described below.

Trying to be more quantitative about "most of the time" is in part want I've 
been
testing the last few days.  I just finished a cycle of 20 hibernates/resumes
which were all successful at least in the sense that after resume internal
sound was working, along with all the other critical functions I care about
(WiFi, Bluetooth, etc.).  However I have occasionally (perhaps 1 in 10 times)
seen something go wrong with sound on resume and the only way to get it
working again was to a full reboot.  During the successful cycles I also
sometimes see i2c_designware or intel_sst_acpi error messages but they
don't seem to indicate an unrecoverable failure.  I was hoping to sort out
what errors I was seen on the occasions where sound was lost till a reboot,
but those are rare enough I haven't been able to sort out the difference
between those and the "recoverable" errors.

Regarding the revert of 02e45646d53b, there were some code changes in
adjacent lines so a simple revert wouldn't apply cleanly to 5.0.0
but the changes were small enough that I was able to manually "merge"
the revert and the 5.0.0 changes.  I have posted a patch file under
Bugzilla: 
showing what I actually did to revert 02e45646d53b for 5.0.0.  As I mentioned
in an earlier message, I have NOT been able to produce a working revert of
02e45646d53b for the 5.1-rc3 kernel.

To make hibernation work on the T100 I also had to create a script
/usr/lib/systemd/system-sleep/t100_hibernate.sh which unloads various drivers
(including sound) before hibernate, then restarts them afterwords.  I've 
inserted
it below.  I'm not certain all the steps in it are still necessary, but the
intermittent failures make it very difficult to determine what is absolutely 
essential.

-t100_hibernate.sh  systemd script---
#!/bin/bash
echo "Hibernate script $1 $2"
[ $2 != 'hibernate' ] && exit 0

case $1 in
 pre)
 echo "Going to $2..."
 /sbin/modprobe -r brcmfmac
 /sbin/modprobe -r hci_uart
 /sbin/modprobe -r battery
 /sbin/modprobe -r hid_multitouch
 /usr/bin/killall pulseaudio
 /sbin/modprobe -r snd_soc_sst_bytcr_rt5640
 /sbin/modprobe -r snd_soc_rt5640
 /sbin/modprobe -r snd_soc_sst_acpi
 ;;
 post)
 echo "Waking from $2..."
 /sbin/modprobe brcmfmac
 /sbin/modprobe hci_uart
 /sbin/modprobe battery
 /sbin/modprobe hid_multitouch
 # Just load the following and it will pull in other snd modules
 /sbin/modprobe snd_soc_sst_acpi
 /usr/sbin/service NetworkManager restart
 /usr/sbin/service wpa_supplicant restart
 # The above is usually enough but occasionally sound doesn't come up 
properly
 # and doing the following seems to restore it in those cases.
 /usr/bin/killall pulseaudio
 /usr/sbin/rmmod snd_soc_sst_bytcr_rt5640
 /usr/sbin/rmmod snd_soc_rt5640
 /usr/sbin modprobe snd_soc_rt5640
 /usr/sbin modprobe snd_soc_sst_bytcr_rt5640
 ;;
esac
-end of script---

I'll send a second message with the system logs which Kai-Heng requested,
with his patch applied to 5.1-rc3.


Ok, so you have hibernation sort of working, with a bunch of hacks.

This is exactly why I usually do not spend any time on trying to get
hibernation to work.

Still since my patch is regressing things for you I will try to
take a look at this and see if I can reproduce and come up with
a fix. But this is not going to be a high priority thing for me to
work on.

In the mean time I've gone ahead and submitted my version of the
fix for the problem Kai-Heng was seeing, since that does not seem
to make your problem worse; and it will be good to get that problem
fixed.

Regards,

Hans

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/7/19 9:44 PM, Kai Heng Feng wrote:
> at 4:58 AM, Robert R. Howell  wrote:
> 
>>> On 03-04-19 07:43, Kai-Heng Feng wrote:
 i2c-designware-platdrv fails to work after the system restored from
 hibernation:
>> I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel,
>> instead of what I had
>> been doing previously, which was reverting commit 02e45646d53b.  I tested
>> it on an ASUS T100TA
>> and unfortunately with both kernels after resume from hibernation I still
>> get errors like those
>> listed below, and sound no longer works.  I also tried applying the patch
>> from Kai-Heng Feng
>> (instead of Hans' patch or my revert) on both kernels and again in both
>> cases I get these same errors.
> 
> 
> Is it possible to attach full dmesg? Thanks.
> 
> Kai-Heng

As I mentioned in my reply, to Hans' message, apologies again for how 
long it took me to reply to both your inquiries.  Besides the 
inconsistency in testing the usually successful hibernation 
under 5.0.0 (with my fixes), I had some strange inconsistencies in 
generating dmesg output with your patch, which I've been trying to understand.  

The following was generated using the 5.1-rc3 kernel with your patch applied.

What I have attached are two versions of dmesg -- one before I hibernate 
the machine, and one after I resume.  The reason for attaching two 
is that on resume the system log is spammed with a message which 
repeats every few microseconds and causes everything before it started 
to scroll out of the message buffers.  Therefore I don't have a record 
of the hibernation itself, and I don't have a record of what transpires on 
resume before the one error starts spamming the log.

I originally thought I had recorded a version which avoided the spamming 
but repeated attempts to recreate that have failed and I've slowly concluded 
in that one test I must somehow have had booted a different test kernel 
rather than the one with your patch.  But even that is a little uncertain.

Besides the versions I've attached I've also tried using the "initcall_debug"  
option but that log is MUCH longer and because of the spamming issue I don't 
think it provides any more information.

Let me know if I can do any further tests.

Bob Howell

--Start of dmesg log before hibernation 
[0.00] Linux version 5.1.0-rc3-rrh-t100-3 (rhow...@vanguard.uwyo.edu) 
(gcc version 7.4.0 (SUSE Linux)) #1 SMP PREEMPT Thu Apr 4 23:05:15 MDT 2019
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.1.0-rc3-rrh-t100-3 
root=UUID=6bbccbe6-887d-402e-8f62-0b068702b0f3 
resume=/dev/disk/by-id/mmc-SEM64G_0xd0225f8a-part5 reboot=pci,force 
clocksource=tsc modprobe.blacklist=mt9m114 systemd.gpt_auto=0 splash=silent 
quiet showopts no_console_suspend
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008efff] usable
[0.00] BIOS-e820: [mem 0x0008f000-0x0008] ACPI NVS
[0.00] BIOS-e820: [mem 0x0009-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x200f] reserved
[0.00] BIOS-e820: [mem 0x2010-0x78cf4fff] usable
[0.00] BIOS-e820: [mem 0x78cf5000-0x78d24fff] reserved
[0.00] BIOS-e820: [mem 0x78d25000-0x78d53fff] ACPI data
[0.00] BIOS-e820: [mem 0x78d54000-0x7933efff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7933f000-0x79b5cfff] reserved
[0.00] BIOS-e820: [mem 0x79b5d000-0x79badfff] type 20
[0.00] BIOS-e820: [mem 0x79bae000-0x79bc8fff] usable
[0.00] BIOS-e820: [mem 0x79bc9000-0x79bc9fff] reserved
[0.00] BIOS-e820: [mem 0x79bca000-0x79bcafff] usable
[0.00] BIOS-e820: [mem 0x79bcb000-0x79bcbfff] reserved
[0.00] BIOS-e820: [mem 0x79bcc000-0x79d40fff] usable
[0.00] BIOS-e820: [mem 0x79d41000-0x79ff8fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79ff9000-0x79ff] usable
[0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xffc0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI=0x78d53000  ACPI 2.0=0x78d53014  ESRT=0x78d24000  
SMBIOS=0x79bcb390 
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.307 
05/09/2014
[0.00] tsc: Detected 1333.000 MHz processor
[0.30] e820: 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/8/19 2:16 AM, Hans de Goede wrote:> 
> 
> Hmm, interesting so you have hibernation working on a T100TA
> (with 5.0 + 02e45646d53b reverted), right ?
> 
Hi Hans and Kai-Heng

First, apologies for how long it took me to reply to both your inquiries.  
In trying to answer them I discovered some inconsistencies in how the T100TA 
was 
behaving on different hibernation attempts and I've been trying to sort those 
out.  
I haven't been completely successful in that, but here's a brief summary.

Yes I do have hibernation working (at least most of the time) on a T100TA, 
with 5.0 + 02e45646d53b reverted (more about that below), and with a systemd 
hibernate script also described below.

Trying to be more quantitative about "most of the time" is in part want I've 
been 
testing the last few days.  I just finished a cycle of 20 hibernates/resumes 
which were all successful at least in the sense that after resume internal 
sound was working, along with all the other critical functions I care about 
(WiFi, Bluetooth, etc.).  However I have occasionally (perhaps 1 in 10 times) 
seen something go wrong with sound on resume and the only way to get it 
working again was to a full reboot.  During the successful cycles I also 
sometimes see i2c_designware or intel_sst_acpi error messages but they 
don't seem to indicate an unrecoverable failure.  I was hoping to sort out 
what errors I was seen on the occasions where sound was lost till a reboot, 
but those are rare enough I haven't been able to sort out the difference 
between those and the "recoverable" errors.

Regarding the revert of 02e45646d53b, there were some code changes in 
adjacent lines so a simple revert wouldn't apply cleanly to 5.0.0 
but the changes were small enough that I was able to manually "merge" 
the revert and the 5.0.0 changes.  I have posted a patch file under
Bugzilla: 
showing what I actually did to revert 02e45646d53b for 5.0.0.  As I mentioned 
in an earlier message, I have NOT been able to produce a working revert of 
02e45646d53b for the 5.1-rc3 kernel.

To make hibernation work on the T100 I also had to create a script  
/usr/lib/systemd/system-sleep/t100_hibernate.sh which unloads various drivers 
(including sound) before hibernate, then restarts them afterwords.  I've 
inserted 
it below.  I'm not certain all the steps in it are still necessary, but the 
intermittent failures make it very difficult to determine what is absolutely 
essential.

-t100_hibernate.sh  systemd script---
#!/bin/bash
echo "Hibernate script $1 $2"
[ $2 != 'hibernate' ] && exit 0

case $1 in
pre)
echo "Going to $2..."
/sbin/modprobe -r brcmfmac
/sbin/modprobe -r hci_uart
/sbin/modprobe -r battery
/sbin/modprobe -r hid_multitouch
/usr/bin/killall pulseaudio
/sbin/modprobe -r snd_soc_sst_bytcr_rt5640
/sbin/modprobe -r snd_soc_rt5640
/sbin/modprobe -r snd_soc_sst_acpi
;;
post)
echo "Waking from $2..."
/sbin/modprobe brcmfmac
/sbin/modprobe hci_uart
/sbin/modprobe battery
/sbin/modprobe hid_multitouch
# Just load the following and it will pull in other snd modules
/sbin/modprobe snd_soc_sst_acpi
/usr/sbin/service NetworkManager restart
/usr/sbin/service wpa_supplicant restart
# The above is usually enough but occasionally sound doesn't come up 
properly
# and doing the following seems to restore it in those cases.
/usr/bin/killall pulseaudio
/usr/sbin/rmmod snd_soc_sst_bytcr_rt5640
/usr/sbin/rmmod snd_soc_rt5640
/usr/sbin modprobe snd_soc_rt5640
/usr/sbin modprobe snd_soc_sst_bytcr_rt5640
;;
esac
-end of script---

I'll send a second message with the system logs which Kai-Heng requested,
with his patch applied to 5.1-rc3.

Bob Howell

> I must admit I never try hibernation myself, in experience it tends to
> have more issues then regular suspend/resume and there are already enough
> other issues to worry about on Bay and Cherry Trail based devices.
> 
> But if it works on the T100TA and 02e45646d53b broke it then I will
> try to fix this, I've a T100TA myself. Currently my T100TA is at my
> local hackerspace, so I will not have access to it until coming Friday.
> 
> Regards,
> 
> Hans
> 

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hi,

On 07-04-19 22:58, Robert R. Howell wrote:

On 4/3/19 2:54 AM, Hans de Goede wrote:



Hi,

On 03-04-19 07:43, Kai-Heng Feng wrote:

i2c-designware-platdrv fails to work after the system restored from
hibernation:
[ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 
0x

Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
doesn't gets called by acpi_lpss_resume_early(), and this causes the
issue.


...


The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
so I think it would be better to do this instead to fix this problem:

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 1e2a10a06b9d..cf768608437e 100644

...

If people affected by the problem can give my version of the fix a test,
then that would be great.

Regards,

Hans


I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel, instead 
of what I had
been doing previously, which was reverting commit 02e45646d53b.  I tested it on 
an ASUS T100TA
and unfortunately with both kernels after resume from hibernation I still get 
errors like those
listed below, and sound no longer works.  I also tried applying the patch from 
Kai-Heng Feng
(instead of Hans' patch or my revert) on both kernels and again in both cases I 
get these same errors.

In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem is 
fixed.  Because
of changes in adjacent code in 5.1-rc3, I haven't yet found a way to merge the 
new code
and the 02e45646d53b revert without causing worse problems. But that's probably 
because
I don't really understand the details of that code.

[  120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[  120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
[  121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
.
[  132.782634] i2c_designware 80860F41:01: controller timed out
[  133.806538] i2c_designware 80860F41:01: controller timed out
[  134.830991] i2c_designware 80860F41:01: controller timed out
[  135.855183] i2c_designware 80860F41:01: controller timed out

Let me know if I can do any other testing to help.


Hmm, interesting so you have hibernation working on a T100TA
(with 5.0 + 02e45646d53b reverted), right ?

I must admit I never try hibernation myself, in experience it tends to
have more issues then regular suspend/resume and there are already enough
other issues to worry about on Bay and Cherry Trail based devices.

But if it works on the T100TA and 02e45646d53b broke it then I will
try to fix this, I've a T100TA myself. Currently my T100TA is at my
local hackerspace, so I will not have access to it until coming Friday.

Regards,

Hans

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Kai Heng Feng]

at 4:58 AM, Robert R. Howell  wrote:


On 4/3/19 2:54 AM, Hans de Goede wrote:


Hi,

On 03-04-19 07:43, Kai-Heng Feng wrote:

i2c-designware-platdrv fails to work after the system restored from
hibernation:
[ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component  
type: 0x


Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
doesn't gets called by acpi_lpss_resume_early(), and this causes the
issue.

...

The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
so I think it would be better to do this instead to fix this problem:

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 1e2a10a06b9d..cf768608437e 100644

...

If people affected by the problem can give my version of the fix a test,
then that would be great.

Regards,

Hans


I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel,  
instead of what I had
been doing previously, which was reverting commit 02e45646d53b.  I tested  
it on an ASUS T100TA
and unfortunately with both kernels after resume from hibernation I still  
get errors like those
listed below, and sound no longer works.  I also tried applying the patch  
from Kai-Heng Feng
(instead of Hans' patch or my revert) on both kernels and again in both  
cases I get these same errors.


Hmm, Hans’ works for me, as acpi_lpss_resume_noirq() calls  
acpi_lpss_do_resume_early() for S4.




In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem  
is fixed.  Because
of changes in adjacent code in 5.1-rc3, I haven't yet found a way to  
merge the new code
and the 02e45646d53b revert without causing worse problems. But that's  
probably because

I don't really understand the details of that code.

[  120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[  120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
[  121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
.
[  132.782634] i2c_designware 80860F41:01: controller timed out
[  133.806538] i2c_designware 80860F41:01: controller timed out
[  134.830991] i2c_designware 80860F41:01: controller timed out
[  135.855183] i2c_designware 80860F41:01: controller timed out

Let me know if I can do any other testing to help.


Is it possible to attach full dmesg? Thanks.

Kai-Heng



Bob Howell

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Robert R. Howell]

On 4/3/19 2:54 AM, Hans de Goede wrote:

> 
> Hi,
> 
> On 03-04-19 07:43, Kai-Heng Feng wrote:
>> i2c-designware-platdrv fails to work after the system restored from
>> hibernation:
>> [ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 
>> 0x
>>
>> Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
>> resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
>> on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
>> doesn't gets called by acpi_lpss_resume_early(), and this causes the
>> issue.
>>
...
> 
> The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
> so I think it would be better to do this instead to fix this problem:
> 
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 1e2a10a06b9d..cf768608437e 100644
...
> If people affected by the problem can give my version of the fix a test,
> then that would be great.
> 
> Regards,
> 
> Hans

I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel, instead 
of what I had 
been doing previously, which was reverting commit 02e45646d53b.  I tested it on 
an ASUS T100TA 
and unfortunately with both kernels after resume from hibernation I still get 
errors like those 
listed below, and sound no longer works.  I also tried applying the patch from 
Kai-Heng Feng 
(instead of Hans' patch or my revert) on both kernels and again in both cases I 
get these same errors.

In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem is 
fixed.  Because 
of changes in adjacent code in 5.1-rc3, I haven't yet found a way to merge the 
new code 
and the 02e45646d53b revert without causing worse problems. But that's probably 
because 
I don't really understand the details of that code.

[  120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[  120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
[  120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
[  121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
.
[  132.782634] i2c_designware 80860F41:01: controller timed out
[  133.806538] i2c_designware 80860F41:01: controller timed out
[  134.830991] i2c_designware 80860F41:01: controller timed out
[  135.855183] i2c_designware 80860F41:01: controller timed out

Let me know if I can do any other testing to help.

Bob Howell

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Hans de Goede]

Hi,

On 03-04-19 07:43, Kai-Heng Feng wrote:

i2c-designware-platdrv fails to work after the system restored from
hibernation:
[ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 
0x

Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
doesn't gets called by acpi_lpss_resume_early(), and this causes the
issue.

Introduce acpi_lpss_{poweroff_late,restore_early}() to make sure
driver's own poweroff_late and restore_early get called.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139
Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from 
resume_noirq")
Signed-off-by: Kai-Heng Feng 


The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
so I think it would be better to do this instead to fix this problem:

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 1e2a10a06b9d..cf768608437e 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -1142,8 +1142,8 @@ static struct dev_pm_domain acpi_lpss_pm_domain = {
.thaw_noirq = acpi_subsys_thaw_noirq,
.poweroff = acpi_subsys_suspend,
.poweroff_late = acpi_lpss_suspend_late,
-   .poweroff_noirq = acpi_subsys_suspend_noirq,
-   .restore_noirq = acpi_subsys_resume_noirq,
+   .poweroff_noirq = acpi_lpss_suspend_noirq,
+   .restore_noirq = acpi_lpss_resume_noirq,
.restore_early = acpi_lpss_resume_early,
 #endif
.runtime_suspend = acpi_lpss_runtime_suspend,

Then the i2c controllers on platforms with the resume_from_noirq
flag set for them will be ready for use while the PCI subsystem
runs the _PS0 / _PS3 methods of PCI devices which may use the
i2c controllers (which is what commit 48402cee6889 set out to fix
in the first place).

If people affected by the problem can give my version of the fix a test,
then that would be great.

Regards,

Hans





---
  drivers/acpi/acpi_lpss.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 1e2a10a06b9d..49aef186d73d 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -1058,6 +1058,11 @@ static int acpi_lpss_suspend_late(struct device *dev)
return acpi_lpss_do_suspend_late(dev);
  }
  
+static int acpi_lpss_poweroff_late(struct device *dev)

+{
+   return acpi_lpss_do_suspend_late(dev);
+}
+
  static int acpi_lpss_suspend_noirq(struct device *dev)
  {
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
@@ -1089,6 +1094,11 @@ static int acpi_lpss_resume_early(struct device *dev)
return acpi_lpss_do_resume_early(dev);
  }
  
+static int acpi_lpss_restore_early(struct device *dev)

+{
+   return acpi_lpss_do_resume_early(dev);
+}
+
  static int acpi_lpss_resume_noirq(struct device *dev)
  {
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
@@ -1141,10 +1151,10 @@ static struct dev_pm_domain acpi_lpss_pm_domain = {
.freeze_noirq = acpi_subsys_freeze_noirq,
.thaw_noirq = acpi_subsys_thaw_noirq,
.poweroff = acpi_subsys_suspend,
-   .poweroff_late = acpi_lpss_suspend_late,
+   .poweroff_late = acpi_lpss_poweroff_late,
.poweroff_noirq = acpi_subsys_suspend_noirq,
.restore_noirq = acpi_subsys_resume_noirq,
-   .restore_early = acpi_lpss_resume_early,
+   .restore_early = acpi_lpss_restore_early,
  #endif
.runtime_suspend = acpi_lpss_runtime_suspend,
.runtime_resume = acpi_lpss_runtime_resume,

Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[Jarkko Nikula]

On 4/3/19 8:43 AM, Kai-Heng Feng wrote:

i2c-designware-platdrv fails to work after the system restored from
hibernation:
[ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 
0x

Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
doesn't gets called by acpi_lpss_resume_early(), and this causes the
issue.

Introduce acpi_lpss_{poweroff_late,restore_early}() to make sure
driver's own poweroff_late and restore_early get called.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139
Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from 
resume_noirq")
Signed-off-by: Kai-Heng Feng 
---
  drivers/acpi/acpi_lpss.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

On a BSW/CHT machine I have I see the warnings below at commit 
48402cee6889 after resuming from hibernation but I2C bus itself is 
working so obviously I tested only S3 when I gave the tested by.


This patch is fixing that so here's my tested by to this patch:

Tested-by: Jarkko Nikula 

But let's wait confirmation from Hans since he has machines and test 
cases where issues from shared I2C bus have shown up.


[  261.472892] [ cut here ]
[  261.473361] 808622C1:03 already disabled
[  261.473688] WARNING: CPU: 0 PID: 149 at drivers/clk/clk.c:828 
clk_core_disable+0xca/0x210
[  261.473688] Modules linked in: hid_multitouch hid_generic i2c_hid 
iTCO_wdt atkbd libps2 intel_rapl coretemp aesni_intel aes_x86_64 
crypto_simd glue_helper intel_cstate i915 i2c_i801 intel_gtt 
i2c_algo_bit lpc_ich drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops drm battery tpm_tis i8042 serio i2c_designware_platform 
video i2c_designware_core tpm_tis_core tpm pinctrl_cherryview button 
rng_core ac i2c_dev i2c_core loop

[  261.473688] CPU: 0 PID: 149 Comm: kworker/0:2 Not tainted 4.19.0-rc3+ #8
[  261.473688] Workqueue: pm pm_runtime_work
[  261.473688] RIP: 0010:clk_core_disable+0xca/0x210
[  261.473688] Code: ff ff ff 48 8b 33 48 c7 c7 c3 09 e5 81 e8 98 02 c5 
ff 0f 0b 5b 41 5c 41 5d 5d c3 48 8b 33 48 c7 c7 ae 09 e5 81 e8 80 02 c5 
ff <0f> 0b e9 60 ff ff ff 65 8b 05 f8 84 c0 7e 89 c0 48 0f a3 05 ae 56

[  261.473688] RSP: :c95ebc58 EFLAGS: 00010082
[  261.473688] RAX:  RBX: 880179d02100 RCX: 
0006
[  261.473688] RDX: 0007 RSI:  RDI: 
88017ba156d0
[  261.473688] RBP: c95ebc70 R08:  R09: 
0001
[  261.473688] R10: 0004 R11:  R12: 
880179d02100
[  261.473688] R13: 880179d31948 R14: 813b6030 R15: 
0008
[  261.473688] FS:  () GS:88017ba0() 
knlGS:

[  261.473688] CS:  0010 DS:  ES:  CR0: 80050033
[  261.473688] CR2: 570a34bc CR3: 0001758df000 CR4: 
001006f0

[  261.473688] Call Trace:
[  261.473688]  clk_core_disable_lock+0x1a/0x30
[  261.473688]  clk_disable+0x1a/0x20
[  261.473688]  i2c_dw_prepare_clk+0x25/0x60 [i2c_designware_core]
[  261.473688]  ? i2c_dw_disable+0xd/0x40 [i2c_designware_core]
[  261.473688]  dw_i2c_plat_suspend+0x2e/0x40 [i2c_designware_platform]
[  261.473688]  pm_generic_runtime_suspend+0x2c/0x30
[  261.473688]  acpi_lpss_runtime_suspend+0xd/0x30
[  261.473688]  __rpm_callback+0x75/0x1c0
[  261.473688]  ? acpi_lpss_suspend+0x1b0/0x1b0
[  261.473688]  rpm_callback+0x1f/0x80
[  261.473688]  ? acpi_lpss_suspend+0x1b0/0x1b0
[  261.473688]  rpm_suspend+0x143/0x6b0
[  261.473688]  rpm_idle+0x106/0x3c0
[  261.473688]  pm_runtime_work+0x7b/0xc0
[  261.473688]  process_one_work+0x206/0x5a0
[  261.473688]  worker_thread+0x3f/0x3a0
[  261.473688]  kthread+0x126/0x140
[  261.473688]  ? process_one_work+0x5a0/0x5a0
[  261.473688]  ? kthread_park+0x80/0x80
[  261.473688]  ret_from_fork+0x3a/0x50
[  261.473688] irq event stamp: 1506
[  261.473688] hardirqs last  enabled at (1505): [] 
_raw_spin_unlock_irq+0x27/0x40
[  261.473688] hardirqs last disabled at (1506): [] 
clk_enable_lock+0xd/0xa0
[  261.473688] softirqs last  enabled at (1310): [] 
__do_softirq+0x285/0x464
[  261.473688] softirqs last disabled at (1303): [] 
irq_exit+0x9d/0xd0

[  261.473688] ---[ end trace b9e91dac2ca18298 ]---
[  261.509646] done.
[  261.513366] PM: hibernation exit
[  261.530737] [ cut here ]
[  261.531249] 808622C1:03 already unprepared
[  261.531629] WARNING: CPU: 0 PID: 149 at drivers/clk/clk.c:687 
clk_core_unprepare+0x1aa/0x2e0
[  261.532253] Modules linked in: hid_multitouch hid_generic i2c_hid 
iTCO_wdt atkbd libps2 intel_rapl coretemp aesni_intel aes_x86_64 
crypto_simd glue_helper intel_cstate i915 i2c_i801 intel_gtt 
i2c_algo_bit lpc_ich drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops drm battery tpm_tis i8042 serio