On Wed, 10 Sep 2003, Duncan Sands wrote: > > The dma_handle actually isn't needed at all, believe it or not. > > The value is needed only at the time the TD is being linked into the > > schedule, which can be done as it is created. After that, the dma_handle > > value is available (if needed) in the link field of the previous TD or QH. > > What about the first TD? The QHs element pointer gets changed so you can't > use that.
The dma_handle for the first TD can be stored in the urbp. It doesn't need to be in the TD itself. > > Allocation and freeing of TD's isn't as much of a problem as you > > seem to think. Although shrinking them certainly won't hurt, they are > > taken from a pre-allocated pool of DMA-coherent memory. Allocation and > > freeing are thus extremely quick. > > Are you sure? Here are the worst offenders from a oprofile I did some time ago: > > vma samples % symbol name image name > ... > 000032e0 3638 7.58059 uhci_unlink_generic /uhci_hcd > 00001620 5731 11.9418 uhci_alloc_td /uhci_hcd > 00001740 6809 14.1881 uhci_remove_td /uhci_hcd > 00002740 12278 25.584 uhci_submit_common /uhci_hcd > > Notice the uhci_alloc_td? Of course it may not be the assigning of memory that > hurst, just the sheer number of TDs to be set up and linked. It's hard to tell. At any rate, I think the allocation is probably about as fast right now as it will ever get. Reducing the total amount of space needed is a separate question. > Go for it! I'm too busy with other things to do much work on UHCI at the moment. Also, I've got about 8 UHCI patches already written, all but maybe 1 or 2 cc'ed to Johannes and maybe 4 of them sent to Greg, but none have been applied yet. I don't see much point in trying to do more until that backlog is cleared up. Alan Stern ------------------------------------------------------- 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
