> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Felipe Balbi > Sent: Monday, March 26, 2012 5:56 AM > > 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. Hi Felipe, Actually, Pratyush is correct here. If you look at the paragraph "Adding intervals to a transfer" in the "Isochronous Transfer Programming Model" section of the databook, it describes the circular TRB list, and says this: Assume TRB 1 represents the data for the first interval and TRB 2 represents the data for the second interval. Because IOC=1, when the core completes the first interval, it will issue an XferInProgress event which indicates to software that TRB 1 can be analyzed to retrieve the results from interval 1. TRB 1 can the be re-used to represent the data for the third interval by setting HWO=1 and issuing an Update Transfer command. So the Update Transfer command is required. The reason for this is that the core will cache a certain number of TRBs in its internal memory. If it already has a TRB in its cache, then even though the software updates that TRB and sets its HWO bit, the core won't see that unless an Update Transfer command is issued to tell it to flush its TRB cache and reload it. Now, it's possible that if the TRB list is big enough, and software stays far enough ahead of the hardware, this situation won't arise. But I don't think you can depend on that always being the case. So for reliable operation, you should issue an Update Transfer command whenever you update one or more TRBs that are part of an active transfer. -- Paul -- 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
