On Mon, Mar 25, 2013 at 11:14:15PM +0100, Rafael J. Wysocki wrote: > On Monday, March 25, 2013 02:35:37 PM Sarah Sharp wrote: > > Alan, > > > > Is there a way to disable runtime PM for a PCI host controller, but > > still allow the system to suspend/hibernate? > > It should be. Just write "on" to the controller's power/control file in > sysfs.
And what's the equivalent function call? We want to disable it within the xHCI driver. Sarah Sharp > > On Fri, Mar 22, 2013 at 06:33:26PM +0000, Cortes, Alexis wrote: > > > Hi Tony, > > > > > > Well, considering the circumstances, the only issue I see here is that > > > the system won't be able to wake on a device connect if the port to which > > > the device was connected enters in compliance mode (I might add that > > > compliance mode is not a 100% of the times failure), however I haven't > > > tested this scenario before. > > > > > > However I think that this problem doesn't worth to disable > > > suspend/hibernate, but this is my opinion. I wonder if there's a way to > > > re-work this scenario. > > > > > > Best Regards, > > > Alexis Cortes. > > > > > > -----Original Message----- > > > From: Tony Camuso [mailto:tcam...@redhat.com] > > > Sent: Friday, March 22, 2013 11:44 AM > > > To: Cortes, Alexis > > > Cc: Sarah Sharp; Alan Stern; 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 03/14/2013 05:42 PM, Alexis R. Cortes wrote: > > > > 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. > > > > > > > > > > Alexis, > > > > > > Does this mean that systems having this chip should not use > > > hibernate/suspend? > > > > > > -- > > > 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 > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
