On 01/14/2014 10:02 AM, Alan Stern wrote:
On Mon, 13 Jan 2014, Alan Ott wrote:
By the way, isn't it true that f_sourcesink uses only one request for
each bulk endpoint? That would naturally lead to a delay each time the
request completes and has to be resubmitted.
That's what the comment at the top of the file says, but it doesn't
appear to be true. See source_sink_start_ep(). It seems to start by
queueing up 8 transactions. I've adjusted this number up with no effect
(currently at 64).
I don't follow your reasoning. The comment at the top of the file
says:
This just sinks bulk packets OUT to the peripheral...
which is true, and also
... this doesn't queue more than one request at a time...
which is also true for the bulk endpoints (although not for the
isochronous endpoints). At high speed, one request = 8 transactions
unless you specify a value for the buflen module parameter other than
4096.
Yes, I mistyped. I meant transfer instead of transaction above.
Maybe there's something else I'm missing.
At the end of the loop in source_sink_start_ep():
if (!is_iso)
break;
You could try removing those two lines and see what happens. (I'm not
sure why those lines are there to begin with...)
You're right. I missed those two lines at the bottom.
It looks like it goes back to b4036ccdd2ce5ec0c4f29b91312dd3cf19fc9152
when support for isochronous endpoints was added to f_sourcesink and
gadget zero. Before that patch it was bulk only and only queued one
transfer. That patch added iso and made it queue 8 transfers, but only
for iso, I suppose in an attempt to not change the existing behavior.
Is there any reason now to only queue one packet?
I'll take those out and see what happens.
Thanks Alan.
Alan.
--
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
