Hi Sarah and Alan,
I am curious whether the the PME- to PME+ happening on a suspended
TI host controller could be used as some hack to signal the mis-behaving
redriver. Could such transition be used as a trigger for linux kernel to
wakeup the TI host "manually"? I am referring to step 4. of my test
in http://marc.info/?l=linux-acpi&m=136735488916468&w=3 showing the
suspended TI controller (in step 3) is not completely "dead" and at least
some part of it gets power enabled (PME+) as a result of port status change
event (mouse connect):
<quote>
4. Interestingly, if I connect a mouse to the socket to show it is "dead" there
is a tiny change in lspci:
---
lspci_vvv_initial__1c.4_and_0b:00_to_auto__mouse_attached_and_works__detached.txt
2013-04-20 01:10:06.000000000 +0200
+++
lspci_vvv_initial__1c.4_and_0b:00_to_auto__mouse_attached_and_works__detached__reattached_but_dead.txt
2013-04-20 01:10:28.000000000 +0200
@@ -491,7 +491,7 @@
Region 2: Memory at f7d10000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
- Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
+ Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME+
Capabilities: [48] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
</quote>
The suspended TI host controller was in PME- state. A mouse connect to the
xHCI port resulted in "deadly suspend" (TI host now in PME+) or maybe I could
better say it was woken up only partially (mouse gets NO power whereas the PCI
device DOES get its power ("PME+")? I used to say a deadly suspend happened
but after I realized this PME- to PME+ change I thing the situation is not that
bad for us, users.
sure, the mouse still does not get power at step 4. (mouse red light is off)
but if this PME- to PME+ could be used a a sign for the broken redriver, I wish
linux could do
echo on > /sys/bus/pci/devices/0000\:0b\:00.0/power/control
for me automatically, right?
I remember the initial posting in May 2012:
http://markmail.org/message/n3qbgspt76yyxvky
Workaround required for Texas Instruments USB3 re-driver
while I have now realized that there was an on ongoing discussion later on:
http://marc.info/?l=linux-kernel&m=134402069909506&w=2
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
I propose you add relevant URLs to the patch.
Martin
P.S.: Have Dell Vostro 3550 with likely the broken redriver but did not
physically crack the laptop, sorry.
Sarah Sharp wrote:
> Some xHCI hosts contain a "redriver" from TI that silently drops port
> status connect changes if the port slips into Compliance Mode. If the
> port slips into compliance mode while the host is in D0, there will not
> be a port status change event. If the port slips into compliance mode
> while the host is in D3, the host will not send a PME. This includes
> when the system is suspended (S3) or hibernated (S4).
>
> If this happens when the system is in S3/S4, there is nothing software
> can do. Other port status change events that would normally cause the
> host to wake the system from S3/S4 may also be lost. This includes
> remote wakeup, disconnects and connects on other ports, and overrcurrent
> events. A decision was made to _NOT_ disable system suspend/hibernate
> on these systems, since users are unlikely to enable wakeup from S3/S4
> for the xHCI host.
>
> Software can deal with this issue when the system is in S0. A work
> around was put in to poll the port status registers for Compliance Mode.
> The xHCI driver will continue to poll the registers while the host is
> runtime suspended. Unfortunately, that means we can't allow the PCI
> device to go into D3cold, because power will be removed from the host,
> and the config space will read as all Fs.
>
> Disable D3cold in the xHCI PCI runtime suspend function.
>
> This patch should be backported to kernels as old as 3.2, that
> contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
> xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
>
> Signed-off-by: Sarah Sharp <[email protected]>
> Cc: Huang Ying <[email protected]>
> Cc: [email protected]
> ---
> drivers/usb/host/xhci-pci.c | 8 ++++++++
> drivers/usb/host/xhci.c | 4 ++--
> drivers/usb/host/xhci.h | 3 +++
> 3 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 1a30c38..cc24e39 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -221,6 +221,14 @@ static void xhci_pci_remove(struct pci_dev *dev)
> static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
> {
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
> +
> + /*
> + * Systems with the TI redriver that loses port status change events
> + * need to have the registers polled during D3, so avoid D3cold.
> + */
> + if (xhci_compliance_mode_recovery_timer_quirk_check())
> + pdev->no_d3cold = true;
>
> return xhci_suspend(xhci);
> }
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index ae59119..d8f640b 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -466,7 +466,7 @@ static void compliance_mode_recovery_timer_init(struct
> xhci_hcd *xhci)
> * Systems:
> * Vendor: Hewlett-Packard -> System Models: Z420, Z620 and Z820
> */
> -static bool compliance_mode_recovery_timer_quirk_check(void)
> +bool xhci_compliance_mode_recovery_timer_quirk_check(void)
> {
> const char *dmi_product_name, *dmi_sys_vendor;
>
> @@ -517,7 +517,7 @@ int xhci_init(struct usb_hcd *hcd)
> xhci_dbg(xhci, "Finished xhci_init\n");
>
> /* Initializing Compliance Mode Recovery Data If Needed */
> - if (compliance_mode_recovery_timer_quirk_check()) {
> + if (xhci_compliance_mode_recovery_timer_quirk_check()) {
> xhci->quirks |= XHCI_COMP_MODE_QUIRK;
> compliance_mode_recovery_timer_init(xhci);
> }
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 29c978e..77600ce 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1853,4 +1853,7 @@ struct xhci_input_control_ctx
> *xhci_get_input_control_ctx(struct xhci_hcd *xhci,
> struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct
> xhci_container_ctx *ctx);
> struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct
> xhci_container_ctx *ctx, unsigned int ep_index);
>
> +/* xHCI quirks */
> +bool xhci_compliance_mode_recovery_timer_quirk_check(void);
> +
> #endif /* __LINUX_XHCI_HCD_H */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
