From: Hans de Goede <hdegoede@redhat.com>
To: "Robert R. Howell" <RHowell@uwyo.edu>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"lenb@kernel.org" <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT
Date: Mon, 13 May 2019 10:41:33 +0200 [thread overview]
Message-ID: <8e5b82ce-4120-4d81-fd8c-26a16cfe3381@redhat.com> (raw)
In-Reply-To: <cc1dacb5-ef0f-61c4-6187-99ee1da55d92@uwyo.edu>
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
next prev parent reply other threads:[~2019-05-13 8:41 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 5:43 [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT Kai-Heng Feng
2019-04-03 8:33 ` Jarkko Nikula
2019-04-03 8:54 ` Hans de Goede
2019-04-07 20:58 ` Robert R. Howell
2019-04-07 20:58 ` Robert R. Howell
2019-04-08 3:44 ` Kai Heng Feng
2019-04-08 3:44 ` Kai Heng Feng
2019-04-11 19:50 ` Robert R. Howell
2019-04-11 19:50 ` Robert R. Howell
2019-04-08 8:16 ` Hans de Goede
2019-04-08 8:16 ` Hans de Goede
2019-04-11 19:50 ` Robert R. Howell
2019-04-11 19:50 ` Robert R. Howell
2019-04-18 11:42 ` Hans de Goede
2019-04-18 11:42 ` Hans de Goede
2019-04-19 22:44 ` Robert R. Howell
2019-04-19 22:44 ` Robert R. Howell
2019-04-23 8:07 ` Rafael J. Wysocki
2019-04-23 8:07 ` Rafael J. Wysocki
2019-04-23 20:03 ` Robert R. Howell
2019-04-23 20:03 ` Robert R. Howell
2019-04-24 7:20 ` Rafael J. Wysocki
2019-04-24 7:20 ` Rafael J. Wysocki
2019-04-25 16:38 ` Robert R. Howell
2019-04-25 16:38 ` Robert R. Howell
2019-04-30 14:39 ` Hans de Goede
2019-04-30 14:39 ` Hans de Goede
2019-05-09 4:24 ` Robert R. Howell
2019-05-09 8:50 ` Hans de Goede
2019-05-09 18:09 ` Robert R. Howell
2019-05-13 8:41 ` Hans de Goede [this message]
2019-05-16 16:34 ` Robert R. Howell
2019-05-14 10:10 ` Hans de Goede
2019-05-16 11:11 ` Rafael J. Wysocki
2019-05-16 16:35 ` Robert R. Howell
2019-05-16 22:42 ` Rafael J. Wysocki
2019-05-25 5:31 ` Robert R. Howell
2019-06-24 10:24 ` Rafael J. Wysocki
2019-06-24 10:51 ` Hans de Goede
2019-06-24 23:14 ` Rafael J. Wysocki
2019-06-26 18:43 ` Robert R. Howell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e5b82ce-4120-4d81-fd8c-26a16cfe3381@redhat.com \
--to=hdegoede@redhat.com \
--cc=RHowell@uwyo.edu \
--cc=kai.heng.feng@canonical.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).