On Monday, March 25, 2013 04:33:02 PM Sarah Sharp wrote: > 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.
Do you want to disable it completely or just temporarily in some cases? Rafael > > > 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
