> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Pratyush Anand > Sent: Tuesday, May 22, 2012 6:53 AM > > On 5/22/2012 12:57 AM, Paul Zimmerman wrote: > >> From: Pratyush Anand [mailto:pratyush.anand@xxxxxx] > >> Sent: Monday, May 21, 2012 2:40 AM > >> > >> On 5/21/2012 2:46 PM, Felipe Balbi wrote: > >>> Hi, > >>> > >>> On Mon, May 21, 2012 at 02:41:13PM +0530, Pratyush Anand wrote: > >>>>>> If I call > >>>>>> dwc3_gadget_start_isoc_uf(dwc, dep, cur_uf) > >>>>>> > >>>>>> with cur_uf obtained from __dwc3_gadget_get_frame(dwc) , it does not work. > >>>>> > >>>>> I guess you have already this bug :-) > >>>>> > >>>> > >>>> even if we correct the mask, there would be issue. > >>>> So frame number from DSTS is of 14 bits. > >>>> Correct value of DSTS was 0x3C8FC. > >>>> After correction of mask it will give uf as 0x391F which is not > >>>> 0x791F coming from event->parameter. > >>> > >>> the missing bit on the mask fixes it, if you look at those numbers, > >>> 0x391f only missed bit 14, which was missing on your mask ;-) > >>> > >> > >> No.. to avoid confusion: > >> > >> At one instance: > >> event->parameters is *0x791f*. > >> DSTS is 0x3C8FC. > >> > >> Our mask is (0x3fff<< 3) = 0x1fff8 > >> (0x3C8FC& 0x1fff8) = 0x1C8FC > >> (0x1C8FC>> 3) = *0x391f* > >> > >> Also, since one has 16 bit space while other has 14 bit, so they can not > >> be same always. > > > > Hi Pratyush, > > > > You should use the value from the event, not from DSTS. The extra bits > > in the event value take into account multiple frames. > > > > But, if there is no way to get frame number other than xfernotready > event->parameter, then I see one issue. > > Consider a situation: > > -- Host wants to starts ISOC IN transfer. So it starts sending IN token > or TP. > -- Since software has not configured TRB, so core will send 0 length packet. > -- Lets say, gadget has not submitted any ep_queue. So even when > xfernotready interrupt is received , any TRB will not be programmed. > -- Now, asynchronously gadget is ready and submits ep_queue. > -- How will controller driver know that in which frame data has to be sent? That is the reason why the databook says to program the Start Transfer command to start some number of microframes in the future. It ensures that the software has enough time be ready to send packets. The sequence should go like this: - The host sends the Set Interface command that enables the isoc endpoint. - In response, the gadget driver enables the endpoint, and starts an IN transfer on the endpoint. - The DWC driver programs the TRBs and starts the transfer, with the start time some number of microframes in the future. - IN tokens from the host that arrive before the start time will be silently dropped. - When the start time has passed the device will start sending packets in response to the IN tokens. -- 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
