On Thursday 02 July 2009 17:37:08 Laurent Pinchart wrote: > Hi David, > > On Friday 19 June 2009 14:28:14 David Brownell wrote: > > On Friday 08 May 2009, Laurent Pinchart wrote: > > > Hi everybody, > > > > > > the USB composite gadget framework currently handles EP0 control > > > requests sent to endpoints (bRequestType[4..0] == USB_RECIP_ENDPOINT) > > > down to the current configuration EP0 request handler. Composite > > > drivers thus need to parse the request and call the appropriate > > > function handlers, making functions not self- contained. > > > > > > It should be possible to maintain an association between functions and > > > endpoints for each configuration, much like we already maintain an > > > association between functions and interfaces. > > > > Ideally something less pricey than an array of function pointers, > > indexed by endpoint ... :) > > > > A per-function bitmap would suffice, and it's not like those calls > > are on critical paths. Though I suppose the code to walk those > > bitmaps is likely to take as much space as the array-of-pointers. ;) > > As the USB specification limits the number of endpoints to 32 (16 IN and > 16 OUT), this would cost 128 bytes on a 32 bit architecture (256 bytes on a > 64 bit architecture). The bitmap would take 4 (8) bytes, but would need to > be stored in the function instead of the configuration. If we assume the > device has two functions, function pointers have a data overhead of 120 > (240) bytes. Given the amount of code required to walk the bitmaps, this > might indeed be an overkill, but here you are :-) Could you please review > the following patch (based on 2.6.31-rc1) ? [snip] And obviously I forgot to include a very important part of the patch, which is the update of the per-function bitmap when allocating/deallocating an endpoint :-/ I'll resubmit a new patch soon. Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
