On Fri, 29 Jun 2007, Oliver Neukum wrote: > > There's a more fundamental problem with your approach, though. You > > can't just allocate the TD's, ED's, and whatnot right alongside the > > URB. These data structures generally have to be located in > > DMA-consistent memory (or is it "DMA-coherent"? -- I can never remember > > the distinction). That's why the HCDs use DMA pools for them. > > True, but that does not prevent me from allocating them at the same _time_ > and keep them around until the URB is freed.
Yes. I just wanted to point out that the patch was wrong, since it used a single kmalloc to do everything. Or did I misread it? > > Another problem involves conflicts with disable_endpoint. HCDs use > > that callback to deallocate their endpoint data structures (EDs for > > OHCI). But if you're allocating space for the ED along with the URB or > > trying to associate the two of them somehow, you would end up in > > peculiar circumstances -- like when the endpoint has been disabled and > > its ED freed, while its URBs are all killed but still allocated and > > available for use. > > How is that different from the current situation? Perhaps the ed should > be refcounted and disable_endpoint could orphan them. It's different because now URBs are not closely bound to particular endpoints. The idea behind disable_endpoint is that the endpoint really is going away. For instance, it gets called during Set-Config requests. All URBs currently queued for that endpoint get cancelled and no more will be accepted until the endpoint is once again enabled. In practice this might not be a problem. It's just something to think about. If URBs are closely associated with endpoints, then shouldn't destroying the endpoint also do something to its URBs? I don't know... Presumably the driver would destroy those URBs anyway once the endpoint was gone. > > Perhaps a better approach, if you insist on pre-allocation, would be at > > the HCD level. There could be an HCD routine that would reserve space > > sufficient for a certain number of URBs with a certain total transfer > > length on a specific endpoint. Then that space would be available for > > any URB a driver wants to submit -- it wouldn't be coupled to a single > > URB. > > No suppose to drivers needing two URBs each and each one would get > only one of the two reserved URBs. Or you reserve 4 URBs in that case. > Then you can go to a full association anyway. I'm not sure what you mean. Why would two different drivers need URBs for the same endpoint? Endpoint 0? I'm also not sure that what I have in mind is so very different from what you're trying to do. Basically, instead of asking the HCD how much space it needs for a certain transfer length & type, simply tell the HCD to allocate the resources directly. Then you could also have the HCD allocate the URB, including the HCD-private part. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
