On Thu, 15 Feb 2007, Oliver Neukum wrote: > The trouble with HID is that it does input and output. I choose to queue > output if the device is supended. I don't want to deal with the case of > having active output URBs when it's time to autosuspend. > Upping the count is not an option because I cannot sleep.
This suggests that the current autosuspend API needs improvement, so that it can handle autoresume requests made in interrupt context. The API also should be able to synchronize I/O submissions done in interrupt context with device suspends (i.e., avoid the problem where usbhid submits an output URB and the device is autosuspended before the URB can complete because of a race). I haven't given these problems much thought. How do you think they should be solved? Forcing multiple drivers to maintain an output queue doesn't sound good. > > I have been considering adding a different operating mode, where the > > autosuspend timer runs all the time while the device is awake. If the > > pm_usage_cnt is > 0 then the work routine restarts the timer and tries > > again later. That would be appropriate for devices where the autosuspend > > delay is relatively long (more than a few seconds) and where the device > > gets used quite heavily at times (like a mass storage device). You would > > end up with one timer callback every minute -- or whatever the delay is -- > > instead of hundreds of mod_timer() calls every second. Would this help > > with what you are doing? > > I am afraid not. But it seems to me that you would get higher efficiency. > If you don't go to the strict scheme. Don't restart the timer if the count > is elevated. Just don't kill the timer if the count gets elevated. Ideally both schemes could be available and the driver could choose which to use. For cases where the device should remain awake as long as userspace holds the device file open, killing the timer makes sense. For cases like usb-storage, it's better to leave the timer running. There are two main disadvantages to the less-strict scheme. One is that the timing of autosuspends isn't as precise: If the timer goes off every 10 seconds, then a suspend could occur anywhere between 10 and 20 seconds after the device becomes idle. IMO this doesn't matter very much. The other disadvantage is that there will be timer callbacks occurring (at widely-spaced intervals, to be sure) as long as the device is in use. Again, this shouldn't matter very much -- since the device is in use the CPU must be busy as well, so the additional timer callbacks won't force an otherwise idle CPU to wake up. I hope. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
