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
