Both on Intel's and AMD's USB4 designs it's important that the device
link to the XHCI controller used for tunneling is able to go into D3
for appropriate low power consumption features as well as for system
suspend states such as s0i3.
Historically this is accomplished by adding to a hardcoded list in the
XHCI driver, but this requires a change for every single platform.
We have a very good proxy that it's safe to do this since the firmware
has indicated the device link needs to be made. So opt all XHCI
controllers with these device links into runtime PM.
Signed-off-by: Mario Limonciello <[email protected]>
---
drivers/thunderbolt/acpi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thunderbolt/acpi.c b/drivers/thunderbolt/acpi.c
index b1f0dc8df47cd..5ffca085a47e3 100644
--- a/drivers/thunderbolt/acpi.c
+++ b/drivers/thunderbolt/acpi.c
@@ -75,6 +75,9 @@ static acpi_status tb_acpi_add_link(acpi_handle handle, u32 level, void *data,
pci_pcie_type(pdev) == PCI_EXP_TYPE_DOWNSTREAM))) {
const struct device_link *link;
+ if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
+ pm_runtime_allow(&pdev->dev);
+
/*
* Make them both active first to make sure the NHI does
* not runtime suspend before the consumer. The
--
2.34.1
Hi Mario,
On Mon, Oct 03, 2022 at 11:12:23PM -0500, Mario Limonciello wrote:
> Both on Intel's and AMD's USB4 designs it's important that the device
> link to the XHCI controller used for tunneling is able to go into D3
> for appropriate low power consumption features as well as for system
> suspend states such as s0i3.
>
> Historically this is accomplished by adding to a hardcoded list in the
> XHCI driver, but this requires a change for every single platform.
>
> We have a very good proxy that it's safe to do this since the firmware
> has indicated the device link needs to be made. So opt all XHCI
> controllers with these device links into runtime PM.
This is good idea.
However, it misses the fact that we have FW CM as well in Intel
integrated TBT platforms (ICL, TGL and ADL) and with those you don't
have the device link (I think ADL has it for both, though) so we would
still need to keep the list in xHCI.
On 10/4/2022 00:04, Mika Westerberg wrote:
> Hi Mario,
>
> On Mon, Oct 03, 2022 at 11:12:23PM -0500, Mario Limonciello wrote:
>> Both on Intel's and AMD's USB4 designs it's important that the device
>> link to the XHCI controller used for tunneling is able to go into D3
>> for appropriate low power consumption features as well as for system
>> suspend states such as s0i3.
>>
>> Historically this is accomplished by adding to a hardcoded list in the
>> XHCI driver, but this requires a change for every single platform.
>>
>> We have a very good proxy that it's safe to do this since the firmware
>> has indicated the device link needs to be made. So opt all XHCI
>> controllers with these device links into runtime PM.
>
> This is good idea.
>
> However, it misses the fact that we have FW CM as well in Intel
> integrated TBT platforms (ICL, TGL and ADL) and with those you don't
> have the device link (I think ADL has it for both, though) so we would
> still need to keep the list in xHCI.
Can you double check the firmware for ADL for me whether it has it for
both? I'll respin the series and drop at least the ICL and TGL reverts
from patch 2.
On Tue, Oct 04, 2022 at 06:38:47AM -0500, Limonciello, Mario wrote:
> On 10/4/2022 00:04, Mika Westerberg wrote:
> > Hi Mario,
> >
> > On Mon, Oct 03, 2022 at 11:12:23PM -0500, Mario Limonciello wrote:
> > > Both on Intel's and AMD's USB4 designs it's important that the device
> > > link to the XHCI controller used for tunneling is able to go into D3
> > > for appropriate low power consumption features as well as for system
> > > suspend states such as s0i3.
> > >
> > > Historically this is accomplished by adding to a hardcoded list in the
> > > XHCI driver, but this requires a change for every single platform.
> > >
> > > We have a very good proxy that it's safe to do this since the firmware
> > > has indicated the device link needs to be made. So opt all XHCI
> > > controllers with these device links into runtime PM.
> >
> > This is good idea.
> >
> > However, it misses the fact that we have FW CM as well in Intel
> > integrated TBT platforms (ICL, TGL and ADL) and with those you don't
> > have the device link (I think ADL has it for both, though) so we would
> > still need to keep the list in xHCI.
>
> Can you double check the firmware for ADL for me whether it has it for both?
> I'll respin the series and drop at least the ICL and TGL reverts from patch
Yes, ADL has it for both.
While doing that, I wonder if it would be easier to understand (and
follow) if all this is done in the xHCI side? It can also look for the
property and unblock runtime PM based on that.