On 10/12/22 03:34, Mathias Nyman wrote:
On 11.10.2022 19.46, Limonciello, Mario wrote:
[Public]
-----Original Message-----
From: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
Sent: Tuesday, October 11, 2022 08:16
To: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>; Limonciello,
Mario <Mario.Limonciello@xxxxxxx>
Cc: Mathias Nyman <mathias.nyman@xxxxxxxxx>; Mehta, Sanju
<Sanju.Mehta@xxxxxxx>; Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx; linux-
kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v3] xhci-pci: Set runtime PM as default policy on
all xHC
1.2 or later devices
On 11.10.2022 8.11, Mika Westerberg wrote:
On Mon, Oct 10, 2022 at 11:00:21AM -0500, Mario Limonciello wrote:
For optimal power consumption of USB4 routers the XHCI PCIe endpoint
used for tunneling must be in D3. Historically this is accomplished
by a long list of PCIe IDs that correspond to these endpoints because
the xhci_hcd driver will not default to allowing runtime PM for all
devices.
As both AMD and Intel have released new products with new XHCI
controllers
this list continues to grow. In reviewing the XHCI specification
v1.2 on
page 607 there is already a requirement that the PCI power management
states D3hot and D3cold must be supported.
In the quirk list, use this to indicate that runtime PM should be
allowed
on XHCI controllers. The following controllers are known to be xHC
1.2 and
dropped explicitly:
* AMD Yellow Carp
* Intel Alder Lake
* Intel Meteor Lake
* Intel Raptor Lake
Suggested-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w.intel.com%2Fcontent%2Fdam%2Fwww%2Fpublic%2Fus%2Fen%2Fdocum
ents%2Ftechnical-specifications%2Fextensible-host-controler-interface-usb-
xhci.pdf&data=05%7C01%7Cmario.limonciello%40amd.com%7Cb286e9c
63e9e4c3a1a3708daab8a9b23%7C3dd8961fe4884e608e11a82d994e183d%7C0
%7C0%7C638010909687542135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
7C%7C%7C&sdata=CetIs1VuAqj8nNBoLnXaGncw6Sl4JcImYY67JpVxyjg%
3D&reserved=0
Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
Reviewed-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
Thanks, added to queue
Thanks!
For my own clarity - is this something you'll still take to 6.1, or
are you meaning
6.2 queue at this point?
Was planning on sending it to usb-next after 6.1-rc1 is out, so ending
up in 6.2
But if there's some benefit in having this already in 6.1 then I don't
object that either.
It's a blocker causing higher power consumption on some of the affected
platforms. So if you're amenable, I would like to see it for 6.1 so
these things have a better chance at passing energy certifications.
This thread originated from enabling Pink Sardine. Wherever it lands
after it's
baked for $long_enough I would like to bring it back to stable
eventually too.
If you think it's too risky for stable later on, can we do separate
set of commits
that adds and then removes the IDs for pink sardine that can go to
stable? This
would at least mirror more closely what has been done historically for
the other
USB4 products.
I think we can add this to stable. It's fine for Intel xHCI 1.2 hosts.
OK thanks.
