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.
> 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.
> 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 would maintain a queue anyway. Switching on an LED is simply not
worth resuming a device in my oppinion.
> > > 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.
Yes, but it never makes sense to _mod_ a timer when the count is
elevated.
> 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.
It must not matter. Due to other interfaces you can never guarantee an
upper limit. You can and must just guarantee a lower limit.
> 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.
Regards
Oliver
-------------------------------------------------------------------------
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
