On Di, 2018-10-09 at 10:51 +0100, Mayuresh Kulkarni wrote: > > The USB core driver has a module-param "usb_autosuspend_delay" whose default value is 2 sec. AFAIU, the PM core will wait at-least 2 sec before scheduling the suspend of this USB device. > So, if the user-space driving any of the above devices sends "new" URB request before usb_autosuspend_delay expires, the PM core will cancel suspend. This will essentially mean the device remained active and link never entered L2. Yes, but you cannot depend on that. > I could be wrong, but 2 sec seems like a pretty good time-out to me, from end user's perspective. Not really. It works well for devices with unpredictable bursts. It fails for periodic activity with known frequencies. Some storage devices have worse PM because we lack a more elaborate system. > > we had this discussion years ago. Then the majority view was that an > > application should close the device. Do we have a reason to revisit > > that decision? [..] > With all due respect, one of the possible reason for this could be, power saving on mobile/tablet platforms (running Android). These platforms usually have a single USB port. > Specifically from our point of view, these platforms are removing 3.5 mm jack and hence the only interface available for headsets is USB. That is interesting. The idea Alan mentioned is old. We already discussed it at that time. It basically boiled down to the question why user space cannot just close devices it wants to be suspended. Adding ioctl()s to change the PM count wouldn't be hard. But we need a justification. If you have one, by all means speak up. Regards Oliver
