On Mon, Mar 26, 2012 at 05:37:30PM +0530, Pratyush Anand wrote: > Hello Felipe, > > I see one scenario where I do not find dwc3 driver working correctly > for isoc IN. I just wanted to clarify > if my understanding is correct. > > 1. Gadget driver (in my case uac2 audio driver with some > modifications) submits 16 request using ep_queue in the beginning. > 2. As soon as host sends first IN token , xfernotready interrupt is received. > 3. dwc3_gadget_start_isoc starts isoc transfer and programs IOC bit in > each 8th trb (DWC3_TRB_NUM / 4). > 4. So I receive two xferinprogress interrupt against submitted (16) requests. > 5. Upon each xferinprogress interrupt reception, complete is called (8 > times) .A new request is submitted (ep_queue) each time > when complete is called. > > Till this point, I find everything correct. > > Now I do not see anyway to start isoc transfer once again for newly > added requests. dwc3_gadget_start_isoc is called only if > xfernotready is received. But If I see section 9.3.5 and 9.3.6 of dw > specs, then I should not expect a xfernotready interrupt, rather a > xferinprogress interrupt in the above scenario. > > So I must add a mechanism to call dwc3_gadget_start_isoc , also when > xferinprogress is received. > > Please let me know, if I am not correct. In case of ISOC transfers, we consume requests in a ring list fashion. There's a link TRB which points back to the beginning of the TRB array. When you queue a request again, the same TRB is used for it so there's no need to restart the transfer. Now, that hasn't been stressed enough and if you found a problem with it, please send us patches ;-) They are much welcome. -- balbi
Attachment:
signature.asc
Description: Digital signature
