https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #7 from Thomas Martitz <ku...@rockbox.org> ---
I did a bisect and git reported this as the culprit:
kugel@thomas-nb:linux.git$ git bisect good
08810a4119aaebf6318f209ec5dd9828e969cba4 is the first bad commit
commit 08810a4119aaebf6318f209ec5dd9828e969cba4
Author: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Date: Wed Oct 25 14:12:29 2017 +0200
PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.
The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.
To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers. Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.
Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.
While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
:040000 040000 6f18a781ca7ee0501888a66532f0667f2926aeb1
440821a72777285dccc37d3a8254688bf4a24486 M Documentation
:040000 040000 6aaceba7f5aae9368a1e6e287a1f56cb1326adbf
557c1672f5101aeae16ce6bda4969c42dd3321bb M drivers
:040000 040000 bdc707f2a476baf517361c46ed28977cb30b6e1b
7c33fb89c953ad06a7b1c8b686d6b6a403aa509b M include
(I haven't tried reverting just this on top of 4.16 yet).
Interestingly, this commit seems to also affect my wifi. I.e. the good commits
(from the susped pov) do not have working wifi, while bad commits have working
wifi.
I'll attach a dmesg output when running on the last good commit
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
