Am Freitag, 29. Juni 2007 schrieb Alan Stern:
> 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?
Yes, it used one allocation for the urb, the parts private to the hcd _driver_
and the pointers to the tds used in the hcd driver.
The data structures for use of the host controller chip still come from
dma pools. They are just allocated at the same time as the urb.
> > > 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...
It should make them fail. But what is new about that?
> 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.
OK, yes I see. That is equivalent and perhaps more elegant.
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
