On Fri, Dec 21, 2012 at 11:53:40AM -0500, Alan Stern wrote: > On Fri, 21 Dec 2012, Greg KH wrote: > > > On Fri, Dec 21, 2012 at 01:21:18PM +0800, Peter Chen wrote: > > > On Thu, Dec 20, 2012 at 08:55:33PM -0800, Greg KH wrote: > > > > On Fri, Dec 21, 2012 at 12:28:38PM +0800, Peter Chen wrote: > > > > > On Tue, Dec 18, 2012 at 11:11:15AM -0500, Alan Stern wrote: > > > > > > I suggest that we remove the CONFIG_USB_SUSPEND option, starting in > > > > > > 3.9. Practically everyone enables it, and the amount of code it > > > > > > protects is fairly small (just portions of usbcore, nothing in the > > > > > > drivers). > > > > > > > > > > > > Basically, if people don't want their kernels to save power then > > > > > > they > > > > > > should turn off CONFIG_PM. > > > > > > > > > > > > Objections, anyone? > > > > > Sorry, I may not agree with this due to below reasons: > > > > > > > > > > - Some customers wants system PM, but do not want usb runtime power > > > > > management, such as Car Navigation System. They want system > > > > > responds fast after user press power on key, but they don't care > > > > > usb power during runtime. > > > > > > > > What is "fast"? And you can always explicitly keep the device away by > > > > writing to the proper sysfs file, right? > > > I mean system suspend/resume. > > > > That's totally different and is not relevant here. > > Actually it is slightly relevant. When CONFIG_USB_SUSPEND is enabled, > during system suspend we go through the whole USB device tree and > explicitly suspend each device (and we do the opposite during system > resume). Without CONFIG_USB_SUSPEND, only the root hubs are suspended > explicitly -- this is what the USB spec calls a "global" suspend. It > doesn't work for USB-3 buses, but I assume Peter is referring only to > USB-2. > > Even though the suspend and resume activities are carried out in > multiple threads in parallel, it seems reasonable that a "global" > approach would take less time. In theory we should be able to use > "global" approach for system sleeps even with CONFIG_USB_SUSPEND > enabled. I trust this would answer Peter's objection.
Thanks, Alan. Clear now. > > > > > So you need to get this working properly for your devices, what's wrong > > > > with that? :) > > > > > > Yes, we can debug that but it needs some efforts. Maybe for alpha release > > > we only add basic USB function, for beta release we will add usb > > > suspend/resume > > > function. Then, at next release, we will add USB runtime PM. > > > I just want to say keep CONFIG_USB_SUSPEND can give users more choices > > > no matter debug, development or final product procedure. > > This ought to be irrelevant, because you can effectively turn off > runtime PM in userspace whenever you need to. Or you can turn it off > by default for all USB devices by making a one-line change to the > kernel source (initialize usb_autosuspend_delay to -1 in > drivers/usb/core/usb.c). This was one of my concerns that in case the user wants to stop USB runtime PM at all (Even don't want the first one), the solution is we can change the value of usb_autosuspend_delay. Thanks. -- Best Regards, Peter Chen -- 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
