On Thu, 10 Feb 2005, David Brownell wrote: > Right. Except that all the HCDs currently handle the single-URB > unlink scenarios, so it's seemed like a low priority. If I saw a > good fix (that didn't lose functionality) I'd be interested.
It's a shame the hard parts were all written before anyone decided to try simplifying things... Calling this a "fix" gives the wrong impression. It's not that anything is wrong now; it's that HC drivers could be made smaller and simpler. > For PIO based HCs (sl811-hcd, isp116x-hcd, presumably others in > the future) it's trivial. For HCs that read schedules of DMA > descriptors, it's a case of taking a given endpoint's schedule > away from the hardware first ... then it turns into the PIO case, > except that maybe the queue then needs to be given back to the HC. As you say, the drivers already do all this. It's just a matter of changing the PIO-case part of the code. Unlinking all the URBs is easier than unlinking just one and then giving the queue back to the HC. > > Now consider this. Normally a driver will want to send only one URB to > > ep0 at a time, it won't try to queue a lot of URBs. (There might be > > occasional counterexamples, but they will be relatively rare.) > > The cases that come quickly to mind are: > > - The HID driver initialization is really ugly right now, but one thing > it needs to do is issue gobs of control requests to initialize things. > > The ugly thing is that the code dates from 2.4 and it implements its > own control queuing ... a static queue, huge to handle UPS devices > although keyboards and mice are small. It's been needing a cleanup > to make it use control queueing rather than wasting a page per device > on rarely-used memory ... I didn't know that. But since the driver doesn't queue its control URBs, the change I suggested won't slow it down. If it is changed to use queuing then it would be slowed down somewhat. Probably not too much (don't these things tend to run at low speed anyway?) and not in a time-critical section. > - The "typical" case would be two different drivers happening to submit > to ep0 at the same time ... say a kernel interface driver plus either > another kernel driver, or a user mode program with usbfs. The URBs > would queue, even when each driver issues only one. (In 2.4 this was > the cause of a fair number of problems: HCDs didn't always handle > this case without oopsing.) Right. This is the case that really needs the special treatment. > - Network drivers often need to use async control transfers for things > like setting multicast filters. As with the "typical" case above, > they won't actually know (or care) that another URB is pending. > (And the slightly messy bit is that they may not be able to avoid > allocating the URB while holding a spinlock, creating a failure > path ...) I don't think this would be affected very much by the change. > - "usbtest" test 10 ... specifically designed to make sure the HCDs > do the right thing there. This has proven to be **really** good for > shaking out bugs in UDC drivers though. I'd not want to see Linux > losing the capability to drive such extended back-to-back control > queue tests. > > Now, test10 counts as "rare", although I think that using it has made > a visible improvement in the robustness of host and peripheral side > USB controller drivers. And what's interesting in the context of > what you've observed is that only test10 _needs_ queuing within the > HCD. All the others won't care. Hah! A "meta-usage"! I suppose there could be a preprocessor flag to suppress the special treatment for the ep0 queue in usbcore. You wouldn't want to use it for normal operation, but it would permit usbtest to work -- so long as there aren't any control queue tests that involve unlinking one URB while keeping others active. (Now you'll probably think "Yeah, that would be a good test!" and you'll go add it in... :-) > > The hcd glue layer will maintain its own URB queue for each > > device's ep0 (actually it already does this). It will only > > send one URB from this queue down to the HCD at a time. > > I thought about this at one point. A similar mechanism could be > used in other cases: > > - Handling malcontent devices which misbehave in the face of > control transfers while bulk transfers are pending: don't > let the HCD see that control request until the bulk transfers > finish. Not a bad idea, but how does one identify such devices without provoking a problem? > - Limiting how many TDs get tied up per queue with UHCI. > OHCI and EHCI allow many KBytes of data per TD; UHCI needs > almost one byte of TD per byte of data. (Which means it > chews up a disproportionate amount of memory for a deep > URB queue ...) One of the things on my todo list for UHCI is to limit the number of TDs allocated per endpoint. Another thing on the list is to shrink the TD structure itself. > > Now that the HCD's queue for ep0 never contains more than one > > URB, we can safely re-implement dequeuing in the HCD to make it > > cancel all the URBs queued for an endpoint. The API can remain > > the same for now, although eventually (2.7?) we may want to change > > it. > > Actually we could do this right now for everything except control > transfers (on ep0), and get most of the win. Bulk transfers are > the main use of URB queues ... originally for networking (usbnet), > and later for mass storage (usb-storage). I'm not sure what you mean here. The win is that we can remove from the HCDs all the code that takes one URB off a queue while leaving others behind. If that code has to remain (for taking care of ep0) then there's no win. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
