Hi Sarah, On 3/11/2013 5:20 PM, Sarah Sharp wrote: > On Mon, Mar 11, 2013 at 05:33:26PM +0000, Cortes, Alexis wrote: >> Hi Sarah, >> >> Sorry for my delayed response, I was investigating this. By 'Inactive' state you mean the Compliance mode? since SS.Inactive and Compliance are not the same. > > Yes, I mean Compliance mode. > >> When in D3hot or D3cold, the host must be able to transmit a PME whenever a device is plugged into the DS port. If a SS device is plugged into DS port and fails to make it to U0, the Port will land in Compliance or SS.Disabled. If Compliance, then there will be no PME notification. If it lands in SS.Disabled, the USB2 will be enabled and then a PME notification will be sent for USB2 connection. I just realized this. > > Then we definitely need to poll during runtime suspend, or disable > runtime PM for the PCI device all together. > Does this mean wake from S3 (system suspend) on device connect will be > broken as well, if the port fails to make it to U0 and goes into > Compliance mode? I believe so, since the timing issues caused by the hardware could make the port enter to Compliance, thus it will never reach U0. However I have never tested this scenario. Best Regards, Alexis Cortes. > Sarah Sharp > >> -----Original Message----- >> From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] >> Sent: Wednesday, March 06, 2013 3:32 PM >> To: Alan Stern; Cortes, Alexis >> Cc: Tony Camuso; linux-usb@xxxxxxxxxxxxxxx; rjw@xxxxxxx; dzickus@xxxxxxxxxx >> Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from hibernate >> >> On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote: >>> On Tue, 5 Mar 2013, Sarah Sharp wrote: >>> >>>> static void compliance_mode_recovery(unsigned long arg) { ... >>>> for (i = 0; i < xhci->num_usb3_ports; i++) { >>>> temp = xhci_readl(xhci, xhci->usb3_ports[i]); >>>> if ((temp & PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) { >>>> /* >>>> * Compliance Mode Detected. Letting USB Core >>>> * handle the Warm Reset >>>> */ >>>> >>>> What happens when the xHCI host controller goes into D3cold due to >>>> runtime PM? The port status registers will read as all f's, so we >>>> will miss any transitions to the compliance mode that happened >>>> before or during the transition to D3cold. >>>> >>>> This code probably needs to wake up the host controller and keep it >>>> from suspending until all the ports can be read. >>>> >>>> Alan, would the right way to do that be a get/put call into the >>>> runtime PM core? >>> >>> If xhci_suspend deletes the Compliance Mode Recovery timer then the >>> timer will never fire while the controller is in D3cold. The problem >>> won't arise. >> >> Alex, >> >> Can the USB 3.0 port go into the Inactive sate while the host is in D3hot or D3cold? If so, will we see a PME that will cause the USB core resume the host? I'm concerned that if we don't get a port status change event when the port goes into the Inactive state, then we won't get an interrupt if the port transitions to the Inactive state while the host is in D3. >> >> If the ports can't go into the Inactive state while the host is in D3, then I agree with Alan that it's fine to delete the timer in xhci_suspend. >> >> However, if the ports can to into the Inactive state and we won't get a PME, then we have to keep the timer running while the xHCI host is runtime suspended. >> >> Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
