On Thu, 15 Feb 2007, Oliver Neukum wrote: > Am Donnerstag, 15. Februar 2007 22:06 schrieb Alan Stern: > > 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 > > Yes, but I'd say that it is very hard to resume a device in interrupt.
Indeed. I guess there really is no choice but to maintain an output queue, if you want to handle this. That's the price you pay for allowing a device to autosuspend while it is held open by userspace. > > 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). > > Therefore I introduced a callback, which can use a spinlock. That particular > race I closed. Hmm... How about using your spinlock to synchronize URB submissions with the driver's suspend() method instead? That way, if an important URB is in flight you simply fail the suspend call. You can check the auto_pm flag in the usb_struct first, to avoid failing non-auto suspends. In a way, this amounts to using the already-existing suspend() method for your callback rather than introducing a new one. The usb_autosuspend_work() routine would need to check for failure of the autosuspend, but that's okay -- it needs to be rewritten anyway; it's still not quite right. > > 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. > > Yes, but it never makes sense to _mod_ a timer when the count is > elevated. It does in the usb-storage case. We raise the count whenever a I/O transfer starts, and decrement it when the transfer finishes (setting the DEVICE_BUSY flag as well). These are lightweight operations, without much overhead other than acquiring the pm_mutex. If the timer expires while an operation is in progress, usbcore sees the elevated count and restarts the timer. An autosuspend won't occur until there are two timer expirations with no I/O activity in between. You're also safe if the timer expires more than once during a single long-lived transfer. > > 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. > > In theory you could wake a second CPU using another irq source. Nothing's perfect! Forunately those callbacks will be fairly infrequent. 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
