Hi,
On 25-10-2019 01:18, Pierre-Louis Bossart wrote:
On 10/24/19 4:34 PM, Rafael J. Wysocki wrote:
On Thu, Oct 24, 2019 at 11:29 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
So far on Bay Trail (BYT) we only have been adding a device_link adding
the iGPU (LNXVIDEO) device as consumer for the I2C controller for the
PMIC for I2C5, but the PMIC only uses I2C5 on BYT CR (cost reduced) on
regular BYT platforms I2C7 is used and we were not adding the device_link
sometimes causing resume ordering issues.
This commit adds LNXVIDEO -> BYT I2C7 to the lpss_device_links table,
fixing this.
Cc: stable@xxxxxxxxxxxxxxx
Thanks for these fixes, but it would be kind of nice to have Fixes:
tags for them too.
Nice, this removes the warnings I saw on Asus T100TA
[ 56.015285] i2c_designware 80860F41:00: Transfer while suspended
Thanks Hans! Feel free to take the following tag for your v2.
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>
Thanks, but I've already send out v2 (without you in the Cc since nothing was changed)
I've added your tested-by to my local version in case another revision is necessary.
Maybe an unrelated point, but with this series I now see a new message (logged only once):
[ 46.888703] ACPI: button: The lid device is not compliant to SW_LID.
Yes the iGPU _PS0 method seems to much with the LID switch status, but this is
harmless this happens on a lot of laptops. TBH I wonder if we should not just
remove this message?
Not sure what exactly this is about, but it may be linked to the fact that the power button is useless to resume and somehow I have to close/reopen the lid to force the device to resume.
The powerbutton not working is likely unrelated and TBH is a bit surprising I
do not have a T100TA at hand atm, but on the closely related T200TA it works fine.
I think your kernel .config may have some settings which cause this. Specifically
for the powerbutton to work, it must work as a GPIO-button.
Can you try:
sudo evemu-record
You should then see something like this:
Available devices:
/dev/input/event0: Lid Switch
/dev/input/event1: Sleep Button
/dev/input/event2: Asus Keyboard
/dev/input/event3: Asus Keyboard
/dev/input/event4: Asus TouchPad
/dev/input/event5: SIS0817:00 0457:1084
/dev/input/event6: Video Bus
/dev/input/event7: Asus Wireless Radio Control
/dev/input/event8: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0
/dev/input/event9: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1
/dev/input/event10: PC Speaker
/dev/input/event11: Asus WMI hotkeys
/dev/input/event12: gpio-keys
/dev/input/event13: gpio-keys
/dev/input/event14: bytcr-rt5640 Headset
Then select the second gpio-keys, so in my case I enter: "13<enter>"
Then in the output you should see:
# Event type 1 (EV_KEY)
# Event code 116 (KEY_POWER)
# Event code 125 (KEY_LEFTMETA)
# Event code 561 ((null))
Among more output, now press the powerbutton, then you should see:
E: 0.000001 0001 0074 0001 # EV_KEY / KEY_POWER 1
E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.121208 0001 0074 0000 # EV_KEY / KEY_POWER 0
E: 0.121208 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +121ms
After which the machine suspends. Then press it again and the machine should
wakeup (note it does not matter how you put it to sleep) on some devices you
may now see another power-button press for the wake-up. Note note all desktop-
environments handle the second power-button press well. Some immediately
re-suspend again, which may be what you are seeing.
I tried to fix this on the kernel side, but the wakeup press being reported is
a feature Android relies on to no immediately resuspend if woken up another way
so the input kernel folks nacked filtering out the second press. Instead I've
fixed this in userspace for gnome with this commit:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/f2ae8a3b9905cde7a9c12f78cb84689e97203380
So it could also be that this is what you are seeing. If that is the case
then a single attempt to suspend + resume via power-button + second resume
attempt with the LID should result in 2 suspends/resumes showing in dmesg
and you should see they wakeup-powerbutton press in evemu-record.
One possible fix for this would be to switch your DE to a recent GNOME.
Regards,
Hans
if it helps here are the traces for 2 cycles of suspend/resume.
[ 34.242313] PM: suspend entry (s2idle)
[ 34.246896] Filesystems sync: 0.004 seconds
[ 34.247265] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 34.249250] OOM killer disabled.
[ 34.249253] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[ 34.250195] printk: Suspending console(s) (use no_console_suspend to debug)
[ 41.251352] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 41.252948] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 41.254530] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 41.257397] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 41.586893] OOM killer enabled.
[ 41.586898] Restarting tasks ... done.
[ 41.625298] video LNXVIDEO:00: Restoring backlight state
[ 41.625718] PM: suspend exit
[ 45.162584] ax88179_178a 2-1:1.0 enx00051ba24714: ax88179 - Link status is: 1
[ 45.171220] IPv6: ADDRCONF(NETDEV_CHANGE): enx00051ba24714: link becomes ready
[ 45.400724] ACPI: button: The lid device is not compliant to SW_LID.
[ 58.478184] PM: suspend entry (s2idle)
[ 58.528882] Filesystems sync: 0.051 seconds
[ 58.529354] Freezing user space processes ... (elapsed 0.004 seconds) done.
[ 58.533708] OOM killer disabled.
[ 58.533712] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[ 58.534648] printk: Suspending console(s) (use no_console_suspend to debug)
[ 63.084134] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 63.085736] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 63.087337] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 63.090241] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 63.420651] OOM killer enabled.
[ 63.420656] Restarting tasks ... done.
[ 63.458493] video LNXVIDEO:00: Restoring backlight state
[ 63.458918] PM: suspend exit
[ 66.862343] ax88179_178a 2-1:1.0 enx00051ba24714: ax88179 - Link status is: 1
[ 66.869564] IPv6: ADDRCONF(NETDEV_CHANGE): enx00051ba24714: link becomes ready
