On Fri, 14 May 2004, Herbert Xu wrote: > I beg to differ here. No driver should ever dead-lock just because > the interrupts stop flowing for whatever reason.
You're right, of course. The thing is, the UHCI driver needs so many changes, a couple of which are fairly fundamental, that I'm reluctant to work on something like this knowing that it will have to be redone when the other changes are made. > On Fri, May 14, 2004 at 07:52:00AM +1000, herbert wrote: > > > > Why is the delay necessary? > > Right, I suppose you were referring to the DMA buffer still under > control of the hardware. You got it. > I'll add a timer in that case. > > BTW, what guarantees that the dequeue function can't called after the > ISR is invoked but before the schedule_lock is taken? If that can happen > then wouldn't it free the DMA buffer that's in use as well? Nothing guarantees it! That's one of the other things that needs to be fixed. The way I eventually want it to work is that there will be a list of urbp's that have been removed from the schedule and are waiting for the hardware to let them go (like we have now) together with a record of the frame number at the time they were removed. There will also be another list, of urbp's that have been removed and are no longer in use by the hardware. At various strategic times (like when an URB is dequeued) the driver will read the current frame number, and if it is different from the previously recorded value then everything on the first list will be placed on the second list. There are a few extra details to take care of, such as what to do when the controller is suspended, but you get the idea. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
