xhci-pci: Set AMD Renoir USB controller to D3 when shutdown

Message ID 20210204051850.64857-1-aaron.ma@canonical.com
State New
Headers show
Series
  • xhci-pci: Set AMD Renoir USB controller to D3 when shutdown
Related show

Commit Message

Aaron Ma Feb. 4, 2021, 5:18 a.m.
On AMD Renoir/Cezanne platforms, when set "Always on USB" to "On" in BIOS,
USB controller will consume more power than 0.03w.

Set it to D3cold when shutdown, S5 power consumption will be 0.03w lower.
The USB can charge other devices as before.
USB controller works fine after power on and reboot.

Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
 drivers/usb/host/xhci-pci.c | 8 ++++++++
 drivers/usb/host/xhci.h     | 1 +
 2 files changed, 9 insertions(+)

Comments

Aaron Ma Feb. 5, 2021, 6:45 a.m. | #1
On 2/5/21 12:27 PM, Kai-Heng Feng wrote:
> Can you please test the following patch, which should address the root cause:
> https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furquan@google.com/
> 
> It also helps another AMD laptop on S5:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935
> 

No, this patch doesn't help on ThinkPad AMD platform.

Aaron

> We don't need to put bandage on drivers one by one once the patch with
> alternative approach is in upstream.
> 
> Kai-Heng
Kai-Heng Feng Feb. 5, 2021, 6:50 a.m. | #2
On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma <aaron.ma@canonical.com> wrote:
>
>
> On 2/5/21 12:27 PM, Kai-Heng Feng wrote:
> > Can you please test the following patch, which should address the root cause:
> > https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furquan@google.com/
> >
> > It also helps another AMD laptop on S5:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935
> >
>
> No, this patch doesn't help on ThinkPad AMD platform.

Thanks for the confirmation!

Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

>
> Aaron
>
> > We don't need to put bandage on drivers one by one once the patch with
> > alternative approach is in upstream.
> >
> > Kai-Heng
Greg Kroah-Hartman Feb. 9, 2021, 8:37 a.m. | #3
On Fri, Feb 05, 2021 at 02:50:15PM +0800, Kai-Heng Feng wrote:
> On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma <aaron.ma@canonical.com> wrote:

> >

> >

> > On 2/5/21 12:27 PM, Kai-Heng Feng wrote:

> > > Can you please test the following patch, which should address the root cause:

> > > https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furquan@google.com/

> > >

> > > It also helps another AMD laptop on S5:

> > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935

> > >

> >

> > No, this patch doesn't help on ThinkPad AMD platform.

> 

> Thanks for the confirmation!

> 

> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>


Mathias, want me to take this in my tree now, or are you going to send
me more patches for 5.12-rc1?

thanks,

greg k-h
Mathias Nyman Feb. 10, 2021, 1:13 p.m. | #4
On 9.2.2021 10.37, Greg Kroah-Hartman wrote:
> On Fri, Feb 05, 2021 at 02:50:15PM +0800, Kai-Heng Feng wrote:

>> On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma <aaron.ma@canonical.com> wrote:

>>>

>>>

>>> On 2/5/21 12:27 PM, Kai-Heng Feng wrote:

>>>> Can you please test the following patch, which should address the root cause:

>>>> https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furquan@google.com/

>>>>

>>>> It also helps another AMD laptop on S5:

>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935

>>>>

>>>

>>> No, this patch doesn't help on ThinkPad AMD platform.

>>

>> Thanks for the confirmation!

>>

>> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

> 

> Mathias, want me to take this in my tree now, or are you going to send

> me more patches for 5.12-rc1?

> 


Nothing more for 5.12-rc1 from me.

Could this be a PCI quirk instead of xhci?
Maybe there is some PCI flag for this already, haven't checked yet.

We want a specific PCI device to go to PCI D3cold at PCI shutdown...

If not, then adding this to xhci is fine for me as well

Thanks
-Mathias
Greg Kroah-Hartman Feb. 11, 2021, 12:50 p.m. | #5
On Wed, Feb 10, 2021 at 03:13:30PM +0200, Mathias Nyman wrote:
> On 9.2.2021 10.37, Greg Kroah-Hartman wrote:

> > On Fri, Feb 05, 2021 at 02:50:15PM +0800, Kai-Heng Feng wrote:

> >> On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma <aaron.ma@canonical.com> wrote:

> >>>

> >>>

> >>> On 2/5/21 12:27 PM, Kai-Heng Feng wrote:

> >>>> Can you please test the following patch, which should address the root cause:

> >>>> https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furquan@google.com/

> >>>>

> >>>> It also helps another AMD laptop on S5:

> >>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935

> >>>>

> >>>

> >>> No, this patch doesn't help on ThinkPad AMD platform.

> >>

> >> Thanks for the confirmation!

> >>

> >> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

> > 

> > Mathias, want me to take this in my tree now, or are you going to send

> > me more patches for 5.12-rc1?

> > 

> 

> Nothing more for 5.12-rc1 from me.

> 

> Could this be a PCI quirk instead of xhci?

> Maybe there is some PCI flag for this already, haven't checked yet.

> 

> We want a specific PCI device to go to PCI D3cold at PCI shutdown...


There probably is.  Kay-Heng, can you look into doing that instead?

thanks,

greg k-h
Aaron Ma Feb. 19, 2021, 8:07 a.m. | #6
On 2/11/21 8:50 PM, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2021 at 03:13:30PM +0200, Mathias Nyman wrote:

>> On 9.2.2021 10.37, Greg Kroah-Hartman wrote:

>>> On Fri, Feb 05, 2021 at 02:50:15PM +0800, Kai-Heng Feng wrote:

>>>> On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma <aaron.ma@canonical.com> wrote:

>>>>>

>>>>>

>>>>> On 2/5/21 12:27 PM, Kai-Heng Feng wrote:

>>>>>> Can you please test the following patch, which should address the root cause:

>>>>>> https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furquan@google.com/

>>>>>>

>>>>>> It also helps another AMD laptop on S5:

>>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935

>>>>>>

>>>>>

>>>>> No, this patch doesn't help on ThinkPad AMD platform.

>>>>

>>>> Thanks for the confirmation!

>>>>

>>>> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

>>>

>>> Mathias, want me to take this in my tree now, or are you going to send

>>> me more patches for 5.12-rc1?

>>>

>>

>> Nothing more for 5.12-rc1 from me.

>>

>> Could this be a PCI quirk instead of xhci?

>> Maybe there is some PCI flag for this already, haven't checked yet.

>>

>> We want a specific PCI device to go to PCI D3cold at PCI shutdown...

> 

> There probably is.  Kay-Heng, can you look into doing that instead?

> 


There is no such PCI quirk, usually it calls driver to shutdown.

Regards,
Aaron

> thanks,

> 

> greg k-h

>
Kai-Heng Feng Feb. 22, 2021, 5:56 a.m. | #7
On Fri, Feb 19, 2021 at 4:07 PM Aaron Ma <aaron.ma@canonical.com> wrote:
>

>

>

> On 2/11/21 8:50 PM, Greg Kroah-Hartman wrote:

> > On Wed, Feb 10, 2021 at 03:13:30PM +0200, Mathias Nyman wrote:

> >> On 9.2.2021 10.37, Greg Kroah-Hartman wrote:

> >>> On Fri, Feb 05, 2021 at 02:50:15PM +0800, Kai-Heng Feng wrote:

> >>>> On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma <aaron.ma@canonical.com> wrote:

> >>>>>

> >>>>>

> >>>>> On 2/5/21 12:27 PM, Kai-Heng Feng wrote:

> >>>>>> Can you please test the following patch, which should address the root cause:

> >>>>>> https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furquan@google.com/

> >>>>>>

> >>>>>> It also helps another AMD laptop on S5:

> >>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935

> >>>>>>

> >>>>>

> >>>>> No, this patch doesn't help on ThinkPad AMD platform.

> >>>>

> >>>> Thanks for the confirmation!

> >>>>

> >>>> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>

> >>>

> >>> Mathias, want me to take this in my tree now, or are you going to send

> >>> me more patches for 5.12-rc1?

> >>>

> >>

> >> Nothing more for 5.12-rc1 from me.

> >>

> >> Could this be a PCI quirk instead of xhci?

> >> Maybe there is some PCI flag for this already, haven't checked yet.

> >>

> >> We want a specific PCI device to go to PCI D3cold at PCI shutdown...

> >

> > There probably is.  Kay-Heng, can you look into doing that instead?

> >

>

> There is no such PCI quirk, usually it calls driver to shutdown.


Let me work on it. There are other devices need to be in D3 for
shutdown, a generic approach across all devices will be better.

Kai-Heng

>

> Regards,

> Aaron

>

> > thanks,

> >

> > greg k-h

> >

Patch

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 84da8406d5b4..a31be1ba927f 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -62,6 +62,7 @@ 
 #define PCI_DEVICE_ID_AMD_PROMONTORYA_3			0x43ba
 #define PCI_DEVICE_ID_AMD_PROMONTORYA_2			0x43bb
 #define PCI_DEVICE_ID_AMD_PROMONTORYA_1			0x43bc
+#define PCI_DEVICE_ID_AMD_RENOIR_USB31			0x1639
 #define PCI_DEVICE_ID_ASMEDIA_1042_XHCI			0x1042
 #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI		0x1142
 #define PCI_DEVICE_ID_ASMEDIA_1142_XHCI			0x1242
@@ -171,6 +172,10 @@  static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 	if (pdev->vendor == PCI_VENDOR_ID_AMD)
 		xhci->quirks |= XHCI_TRUST_TX_LENGTH;
 
+	if (pdev->vendor == PCI_VENDOR_ID_AMD &&
+		pdev->device == PCI_DEVICE_ID_AMD_RENOIR_USB31)
+		xhci->quirks |= XHCI_SHUTDOWN_D3COLD;
+
 	if ((pdev->vendor == PCI_VENDOR_ID_AMD) &&
 		((pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_4) ||
 		(pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_3) ||
@@ -594,6 +599,9 @@  static void xhci_pci_shutdown(struct usb_hcd *hcd)
 	/* Yet another workaround for spurious wakeups at shutdown with HSW */
 	if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)
 		pci_set_power_state(pdev, PCI_D3hot);
+
+	if (xhci->quirks & XHCI_SHUTDOWN_D3COLD)
+		pci_set_power_state(pdev, PCI_D3cold);
 }
 #endif /* CONFIG_PM */
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 25e57bc9c3cc..0684193da4bd 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1883,6 +1883,7 @@  struct xhci_hcd {
 #define XHCI_SKIP_PHY_INIT	BIT_ULL(37)
 #define XHCI_DISABLE_SPARSE	BIT_ULL(38)
 #define XHCI_SG_TRB_CACHE_SIZE_QUIRK	BIT_ULL(39)
+#define XHCI_SHUTDOWN_D3COLD	BIT_ULL(40)
 
 	unsigned int		num_active_eps;
 	unsigned int		limit_active_eps;