Re: [PATCH v3] xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices

[Mario Limonciello <mario.limonciello@amd.com>]

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@linux.intel.com>
>>> Sent: Tuesday, October 11, 2022 08:16
>>> To: Mika Westerberg <mika.westerberg@linux.intel.com>; Limonciello,
>>> Mario <Mario.Limonciello@amd.com>
>>> Cc: Mathias Nyman <mathias.nyman@intel.com>; Mehta, Sanju
>>> <Sanju.Mehta@amd.com>; Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org>; linux-usb@vger.kernel.org; linux-
>>> kernel@vger.kernel.org
>>> 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@linux.intel.com>
>>>>> 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&amp;data=05%7C01%7Cmario.limonciello%40amd.com%7Cb286e9c
>>> 63e9e4c3a1a3708daab8a9b23%7C3dd8961fe4884e608e11a82d994e183d%7C0
>>> %7C0%7C638010909687542135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
>>> 7C%7C%7C&amp;sdata=CetIs1VuAqj8nNBoLnXaGncw6Sl4JcImYY67JpVxyjg%
>>> 3D&amp;reserved=0
>>>>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>>>>
>>>> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>>>
>>> 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.