rkagan at mail.ru
Fri Apr 22 04:55:47 EDT 2005
On Fri, Apr 22, 2005 at 10:39:06AM +0200, Duncan Sands wrote:
> > AFAICS struct work_struct already includes a timer, and
> > linux/workqueue.h provides schedule_delayed_work() /
> > cancel_rearming_delayed_work() to use it, so we can switch to using
> > those instead of maintaining our own timer. I'm about to do just that
> > to cxacru.
> not for the speedtch, because the work gets scheduled by the interrupt
> endpoint completion handler also, without a delay.
schedule_delayed_work() doesn't exclude schedule_work(), does it?
> > BTW what do you think about using our own workqueue? I guess keventd
> > won't tolerate suspending for two seconds, as is possible with current
> > status polling routines both in speedtch and cxacru, which you've
> > pointed out some time ago.
> Something will need to be done, but I think we should first get what
> we have now into the kernel. We can perfect it later.
> PS: Another possibility, rather than a workqueue, is to simply only
> do asynchronous IO (i.e. don't use the _msg stuff).
Umm, I don't think "simply" is the right word here: adding a workqueue
is a matter of adding several lines of code to usbatm core, while
async IO would require splitting of submittion and completion in all
drivers, and change the concept of the now single polling function into
a full-blown state machine...
More information about the Usbatm