Stephan Feder wrote: > David Brownell wrote: > >>In the interest of de-complicating the API and code, >>I wonder how folk would react to removing the flag >>that enables bulk queuing ... doing it as needed but >>without needing an explicit request. > > ... > > Sounds good. > > But there is more: Right now there is one queue for each endpoint. That > means > > - if you submit a new URB the low level driver has to search for other > submitted URBs for the same endpoint; this can be done either in a > complex and efficient or a simple and slow way... not good.
That's why both EHCI and OHCI use a simple and efficent approach to get to any endpoint's queue head ... called array indexing! :) How an HCD gets the appropriate queue is not relevant to the high level API, but I tend to agree that slow and/or complex are adjectives to avoid. > - there is no possibility for a device driver to build a single queue > for different endpoints. Example: device sends data on endpoint 1, host > acknowledges on endpoint 2, device sends data on endpoint 1, and so on. > At the moment it's stop and go with no way to schedule in advance. > > So, define something like an usb_queue_t (an URB fifo, with URBs linked > by a link field in struct urb) as a new datatype in the usb core, opaque > to the device driver, accessible by the low level driver, and make it a > parameter to usb_submit_urb. At that point you start to get into some sort of interpretive execution engine (like the BSD-Unix APIs known to Linux users as "socket filters"). I've looked at that problem enough to decide I think it's worth staying away from in USB. It's simple enough to do the right thing in completion handlers, and hard to boil down all the relevant options (error handling being one issue, concurrency, ...) into some abstract protocol machine. Plus, most devices don't need anything complicated there. - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
