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.
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. Hope this helps. Best Regards, Alexis Cortes. -----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
