Hi Balbi, On 04/04/16 11:46, Felipe Balbi wrote: > > Hi, > > Felipe Ferreri Tonello <e...@felipetonello.com> writes: >>>> On 30/03/16 13:33, Michal Nazarewicz wrote: >>>>> On Wed, Mar 30 2016, Felipe Balbi wrote: >>>>>> a USB packet, right. that's correct. But a struct usb_request can >>>>>> point to whatever size buffer it wants and UDC is required to split >>>>>> that into wMaxPacketSize transfers. >>>>> >>>>> D’oh. Of course. Disregard all my comments on the patch (except for >>>>> Ack). >>>>> >>>> >>>> I didn't really get it. Does that mean that if buflen is multiple of >>>> wMaxPacketSize, the UDC driver should fit as many [DATA] packets into >>>> one usb_request and call complete() or it will always call complete() on >>>> each [DATA] packet, thus not requiring buflen at all? >>>> >>>> Does that mean that we can still use buflen and this patch is still >>>> valid? (besides the endianess issue that was addressed on v2) >>> >>> if you have e.g. 2048 bytes of data to transfer and wMaxPacketSize is >>> e.g. 256 bytes, the UDC controller is required to do whatever it needs >>> to do to transfer 2048 bytes (or less if there's a short packet). >>> >>> You don't need to break these 2048 bytes into several requests yourself, >>> the UDC is required to do that for the gadget. >> >> Right, what about OUT endpoints? > > also applicable >
Ok, so I will make few tests here and resend a v3 probably with buflen still. -- Felipe
0x92698E6A.asc
Description: application/pgp-keys
