What is wrong with FreeBSD and USB Support

[Markus Rechberger]

On Mon, Mar 6, 2017 at 11:30 AM, Hans Petter Selasky <hps at selasky.org> wrote:
> On 03/06/17 09:53, Markus Rechberger wrote:
>>
>> Just to clarify this issue it's hardware and software related.
>>
>> In the linux libusb20 wrapper there's some code in it in the bulk
>> callback function
>>
>> libusb20_tr_submit(xfer)
>> if (xfer == xfer0)
>>    xfer = xfer1
>> else
>>    xfer = xfer0
>>
>> libusb20_tr_start(xfer)
>>
>> why should someone toggle the other transfer and not the same one that
>> is returning or required to set up?
>
>
> Hi,
>
> This is to be able to setup double-buffering of USB transfers.
>
>> I would like to set up multiple requests at the same time and not only
>> 2 of them (since 2 of them are not fast enough in our case).
>
>
> Do do this correctly for a BULK endpoint, allocate two USB transfers, and
> then subdivide these two using the FreeBSD USB frames feature.
>
> Divide 1x USB transfers into 32x frames which then equals 32 transfers in
> one completion event. Linux/MacOS/Windows doesn't have this feature and
> instead they allow setting up a bunch of wMaxPacketSize sized jobs which
> then in turn generate an enormous completion event traffic, which is not
> very intelligent.

Are you sure? As from some of my signal analyzer dumps I do think that
all those systems support
multiple transfers within one completion event. I always request
multiple frames within one request on those systems and they complete
at once. And they only complete once all the buffers are filled.


>
>
>> This is about resolving an active bug and misconception of the freebsd
>> userspace usb API usage.
>> Some hardware just need a lower latency.
>
>
> --HPS