Am Freitag, 29. Juni 2007 schrieb Alan Stern:
> On Fri, 29 Jun 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > this proved harder than it looks like. I can use cdc-acm over ohci with
> > this patch. So what do you think?
>
> It tries to do an awful lot all at once. A good place to start would
> be to use separate allocation for the Iso packet structures. This
> could be a simple standalone change.
OK.
> Have you looked at Marcel's URB-allocation routine? We seem to be
> growing a whole variety of them at the moment. Maybe some of them can
> be combined.
IMHO, this is because they are two fundamental ways to use URBs.
Either you see them as describing a "packet" to be thrown away after
use or as a "pipeline" to be kept until the connection is closed. In the
latter case you want to keep all resources. Marcel's patch goes for the
first model.
> 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.
> 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.
> Do you really want to bind URBs to specific endpoints? There must be
> places where drivers use a single URB to carry out multiple functions,
> talking to different endpoints. Certainly usb-storage does that.
Yes, I want to do that. Or rather I see no sane way to otherwise determine
the maximum amount of resources needed. Driver will require changes
anyway.
> 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.
Regards
Oliver
-------------------------------------------------------------------------
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
