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.sh...@linux.intel.com] >> Sent: Wednesday, March 06, 2013 3:32 PM >> To: Alan Stern; Cortes, Alexis >> Cc: Tony Camuso; linux-usb@vger.kernel.org; r...@sisk.pl; dzic...@redhat.com >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
