On 23.11.2020 15.54, Hans de Goede wrote:

Hi,

On 11/11/20 3:31 PM, Mika Westerberg wrote:

quoted

On Wed, Nov 11, 2020 at 12:27:32PM +0100, Hans de Goede wrote:

quoted

Hi,

On 11/10/20 6:25 PM, Mika Westerberg wrote:

quoted

On Tue, Nov 10, 2020 at 04:02:33PM +0000, Limonciello, Mario wrote:

quoted

quoted

On Tue, Nov 10, 2020 at 11:57:07AM +0100, Bastien Nocera wrote:

quoted

Hey,

systemd has been shipping this script to enable auto-suspend on a
number of USB and PCI devices:

https://github.com/systemd/systemd/blob/master/tools/chromiumos/gen_autosuspen
d_rules.py

quoted

The problem here is twofold. First, the list of devices is updated from
ChromeOS, and the original list obviously won't be updated by ChromeOS
developers unless a device listed exists in a ChromeBook computer,
which means a number of devices that do support autosuspend aren't
listed.

The other problem is that this list needs to exist at all, and that it
doesn't seem possible for device driver developers (at various levels
of the stack) to opt-in to auto-suspend when all the variants of the
device (or at least detectable ones) support auto-suspend.

A driver can say they support autosuspend today, but I think you are
concerned about the devices that are controlled by class-compliant
drivers, right?  And for those, no, we can't do this in the kernel as
there are just too many broken devices out there.

I guess what Bastien is getting at is for newer devices supported by class
drivers rather than having to store an allowlist in udev rules, can we set
the allowlist in the kernel instead.  Then distributions that either don't
use systemd or don't regularly update udev rules from systemd can take
advantage of better defaults on modern hardware.

The one item that stood out to me in that rules file was 8086:a0ed.
It's listed as "Volteer XHCI", but that same device ID is actually present
in an XPS 9310 in front of me as well and used by the xhci-pci kernel module.

Given we're effectively ending up with the combination of runtime PM turned
on by udev rules, do we need something like this for that ID:

https://github.com/torvalds/linux/commit/6a7c533d4a1854f54901a065d8c672e890400d8a

@Mika Westerberg should 8086:a0ed be quirked like the TCSS xHCI too?

I think this one is the TGL PCH xHCI. The quirk currently for xHCI
controllers that are part of the TCSS (Type-C SubSystem) where it is
important to put all devices into low power mode whenever possible,
otherwise it keeps the whole block on.

Note that there are currently some IDs missing from the xHCIs which
are part of the TCSS too. At least the id for the xHCI in the thunderbolt
controller on the Lenovo T14 gen 1 is missing. I started a discussion
about extending the kernel quirk list for this vs switching to hwdb
a while a go:

https://lore.kernel.org/linux-usb/b8b21ba3-0a8a-ff54-5e12-cf8960651086@redhat.com/ (local)

The conclusion back then was to switch to hwdb, but I never got around to this.

The reason I've added these to the xHCI driver is that it works even if
you are running some really small userspace (like busybox). Also for the
xHCI in TCSS we know for sure that it fully supports D3cold.

(The one you refer above is actually mistake from my side as I never
 tested Alpine Ridge LP controller which I think this is).

Ok, so I'll submit a patch adding the 15c1 product-id for the
INTEL_ALPINE_RIDGE_LP_2C_XHCI controller to the list of ids for which we
set the XHCI_DEFAULT_PM_RUNTIME_ALLOW quirk. To fix the much too high
idle-power consumption problem on devices with this Alpine Ridge variant.

Thanks

quoted

quoted

quoted

Typically we haven't done that for PCH side xHCI controllers though, but
I don't see why not if it works that is. Adding Mathias to comment more
on that since he is the xHCI maintainer.

If we are also going to enable this for the non TCSS Intel XHCI controllers,
maybe just uncondtionally enable it for all Intel XHCI controllers, or
if necessary do a deny-list for some older models and enable it for anything
not on the deny-list (so all newer models). That should avoid the game of
whack-a-mole which we will have with this otherwise.

This is really up to Mathias to decide. I'm fine either way :)

Ok, Matthias what do you think about this?

I don't think we are ready to enable runtime pm as default for all Intel xHCI controllers.
The risk of xHCI not waking up when user plugs a mouse/keyboard, making the system unusable
just seems too high compared to the powersaving benefit.

The powersaving benefit from autosuspending the TCSS xHCI is a lot better, and we, (Mika mostly)
has been able to verify they work.

So I propose we for now continue adding TCSS xHCI controllers to the allowlist in kernel.
For others I think a userspace allow/denylist makes sense.

Long term goal would be default allow for all, with short denylist in kernel.

Thanks
Mathias