Oliver Neukum wrote:
Sure. I could see for example usb_buffer_map() as a way toAm Donnerstag, 16. Januar 2003 01:52 schrieb David Brownell:- 1..N TDs ... dependant on the specific buffer passed later, except (usually) for ISO (where i == n)What prevents you from allocating a reasonable number in the general case and as many as you may need in the iso case?What, and have _two_ code paths to debug/stabilize in the hairy hardware-specific logic ... one where you guessed right, and one where you guessed wrong?Very good point. So I'll get a 2.0 device and after that I'll code something and do benchmarks. After 2.7.0 we can discuss this again. OK ?
ensure the buffer's TDs are pre-allocated. (Except for ISO,
which has as strange buffering model.)
Were you wanting to do anything about that urb->hcpriv[]
pre-allocation? I see no reason not to do that part, and
it'd mean that the submit path won't usually need to hit the
slab pool again until after the submit completes.
- Dave
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel