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.
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.]
-- 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.
Regards
Pratyush
--
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
