On Monday 08 September 2003 16:30, you wrote: > On Thu, 4 Sep 2003, Duncan Sands wrote: > > Hi Alan, yes of course - sorry for the brain fart. Using one QH per > > endpoint seems like an excellent idea. I had a couple of other silly > > thoughts about TDs. At the moment they seem too big (they exceed 32 > > bytes). For a 32 byte endpoint, that means that you have to allocate more > > memory in TDs than you are transfering! > > > > Have I gone off the deep end? > > I'll have to think about this. It doesn't sound completely impractical, > at first glance.
Hi Alan, since you didn't squelch those ideas how about this even wilder one: it seems to me that for IN transfers (I am thinking bulk) it is possible to allocate no TDs whatsoever! The TDs are set up in the transfer buffer instead!! For example, suppose the size of a TD is 32 bytes and the endpoint size is 32 bytes as well. You don't put anything in the first 32 bytes of the transfer buffer. In the second 32 bytes you put a TD which points to the start of the buffer. In the third 32 byte block of the transfer buffer you put a TD which points to byte 32 of the buffer (where the first TD is) and so forth. The last (and maybe the second last if the buffer size is not a multiple of 32) TD needs to be put somewhere else, but it can live in urb_priv. The beauty of this scheme is that TDs only get overwritten when they are no longer in use by the hc - after all, if one gets overwritten then that is because (by definition) the hc has moved on to the following TD. The main problem (of course) is that some endpoints may be smaller than the size of a TD. Another problem could come from cache coherency issues. Also, some users may not expect their buffers to be scribbled on after the end of the transferred data (which could happen). There would also be an asymmetry with OUT transfers, but in a sense this asymmetry is natural: quite often you don't know how much data needs to come in, so have to set up a much bigger buffer than is actually needed, leading to massive TD allocation - this is cured by the above scheme. For an OUT transfer you always know how much to send. > > PS: My usual email address is having problems, please reply to the above > > address. > > I noticed that. Perhaps you didn't receive the test patch I sent out last > week. You can find it at > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=106269382202061&w=2 > > Also, I don't know if you ever saw the interchange I had with Johannes > back in July. Find the original messages and followups at > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=105898553709745&w=2 > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=105898697111554&w=2 Thanks for the pointers - I will try to catch up. Hopefully my email is now working (new addresses though). > My personal feeling is that a massive reworking of UHCI would help. One > QH per URB alone means pretty far-reaching changes. Another related > change would be taking much of the information that's now in the QH and > putting in the urbp instead. Since the QH would now refer to all the URBs > queued for an endpoint, it doesn't make sense to store per-URB data there. But is it worth it? Ciao, Duncan. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
