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.
> 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...)
> > If the driver used two requests instead, the pipeline would be much
> > less likely to empty out.
>
> Yes, I absolutely agree, the queue must be kept full, but in this case I
> think it is.
No, it isn't.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
