On Wed, Aug 22, 2012 at 11:25:16PM +0530, Pratyush Anand wrote: > On 8/22/2012 5:01 PM, Felipe Balbi wrote: > >Hi, > > > >On Wed, Aug 22, 2012 at 02:39:50PM +0530, Pratyush Anand wrote: > >>Hi Felip, > >> > >>I am already discussing it with SNPS, but if you have observed > >>following with current code.. > >> > >>Out of two generation condition for missed isoc, only first is > >>handled with current code. > >> > >>1. when the host does not poll for all the data. > >>2. because of application-side delays that prevent all the data from > >>being transferred in programmed microframe. > >> > >>I have observed that 2nd case does not work. > >>I tried following , still it does not work. > >> > >>a. issue end transfer (dwc3_stop_active_transfer) when first missed > >>trb is observed and wait for 100 us. > >>b. Now do not issue start transfer from ep_queue (sceneario 3), > >>rather wait for xfernotready and then issue start transfer. > >> > >>I see that second start transfer is isused with sufficient future > >>frame number, but no xferinprogress is received. all TRBs remains > >>with HWO=1. :( > > > >Aha, that's a great finding :-) When you miss the ISOC, I believe you > >should make sure to reclaim all TRBs (drop the HWO bit) and then issue > >another start transfer. No ? > > > > Hummm...Not sure.. > When missed isoc is received HWO is already reset for that TRB. Yes, but what about the others ? I think you should stop them all. I have a vague memory of that being said on the databook, though I could be getting confused... > So with current code flow goes like this: > > -- I use usbtest (test 16 ISOC IN) to test this. > -- use pattern=2 & bInterval=1 in f_sourcesink > -- Now put deliberately 125 us delay in case 2 of reinit_write_data > to cause missed isoc after some time > -- When set interface is received, gadget issues 8 ep_queue > -- They all are added to dep->request_list > -- When xfernotready is received, TRBs (TRB0 to TRB7) are prepared > from request_list. start transfer is issued with TRB0. > -- When first xferinprogress is received, update xfer is issued with > TRB1 [This is wrong, it should be issued with TRB8, comment in code > is perfect that "req points to the first request where HWO changed > from 0 to 1", however it does not work that way. I will correct it.] fair enough, thanks :-) > -- anyway, this flow goes on till TRB25, and they all are transferred. > -- TRB26-30 and TRB0-TRB2 has missed isoc. When missed isoc is set, > HWO is also reset to zero by controller. > -- Now I made some modifications: when missed isoc happens, issue end > transfer. When TRB26 was cleaned, end transfer was issued. During > giveback/ep_queue of TRB26-30 & TRB0-2 new request was only added in > the request_list. So, we again have 8 new request in list. > -- Now, when 2nd xfernotready was received, again TRB0-7 are prepared > and start transfer is issued with trb0. At this moment, hwo=1 for > TRB0-7 and 0 for TRB8-30. TRB31 is linked and not touched. I expect > TRB0-7 to be transferred, but it does not happen. ok. This doesn't sound familiar at all, unfortunately :-( And I have no ideas right now of what we could do to at least get some information out of the HW. This IP has some very cool debugging features (you can read the internal queue pointers and cache states and so on) but it's not properly documented on the databook how to decode that data :-( -- balbi
Attachment:
signature.asc
Description: Digital signature
