On Tuesday, March 26, 2013 09:24:04 AM Sarah Sharp wrote: > On Tue, Mar 26, 2013 at 01:12:25PM +0100, Rafael J. Wysocki wrote: > > 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? > > Completely, when we find a particular PCI xHCI host. We may lose > hot-plug events otherwise.
It should be sufficient to call pm_runtime_get_sync() during .probe() and then pm_runtime_put_noidle() in .remove(). The device will be "always on" then effectively. Alternatively, you can use pm_runtime_disable() and pm_runtime_enable(), but there is a side effect that runtime PM helpers will return error codes for that device. Thanks, 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
