> > 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.
I was just being pedantic :) > > > 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. Maybe it should wait for 2.7? Right now, correctness is more important, right? > > 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. I understand. 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
