Date: Mon, 6 Mar 2017 09:53:48 +0100 From: Markus Rechberger <mrechberger@gmail.com> To: freebsd-multimedia@freebsd.org, Hans Petter Selasky <hps@selasky.org> Subject: Re: What is wrong with FreeBSD and USB Support Message-ID: <CA%2BO4pC%2B1t67ODF7bkyVhcojXTLnFkS28RbFAc%2Be-tjNncogMAQ@mail.gmail.com> In-Reply-To: <CA%2BO4pC%2Bf5xzOjENKSJu_sQeaiN3XL3WiTcRQvm4vVweQ71Xtrg@mail.gmail.com> References: <CA%2BO4pCK4%2B1rE5ft4Boy_3xPdCxK31UtTQ2BYpnBUn5jxZr%2Bz_g@mail.gmail.com> <CA%2BO4pCJr5Bq-sgjzvZQB-mFRT6x7Tp3psga6f__V9Ag-=v-mhw@mail.gmail.com> <CA%2BO4pC%2Bf5xzOjENKSJu_sQeaiN3XL3WiTcRQvm4vVweQ71Xtrg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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). This is about resolving an active bug and misconception of the freebsd userspace usb API usage. Some hardware just need a lower latency. On Mon, Mar 6, 2017 at 7:05 AM, Markus Rechberger <mrechberger@gmail.com> wrote: > libusb20_dev_open() opens an USB device so that setting up USB > transfers becomes possible. The number of USB transfers can be zero > which means only control transfers are allowed. This function returns > zero on success else a LIBUSB20_ERROR value is returned. A return > value of LIBUSB20_ERROR_BUSY means that the device is already opened. > > libusb20_tr_get_pointer() will return a pointer to the allocated USB > transfer according to the pdev and tr_index arguments. This function > returns NULL in case of failure. > > what is the definition of a "tr_index"? The documentation does not > cover that anywhere, someone can only copy it from the sample sources. > Please don't expect that anyone reading the manpage will have an idea > how the FreeBSD API works, because all those items simply do not exist > with other operating systems, neither is the ep_index calculation > needed with other systems. > > uint8_t ep_index = (((addr & 0x80) / 0x40) | (addr * 4)) % (16 * 4); > uhe->bsd_xfer[0] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 0); > uhe->bsd_xfer[1] = libusb20_tr_get_pointer(dev->bsd_udev, ep_index + 1); > > So my guess is that the examples are just using 2 urb transfers and > freebsd just cannot catch up. However it is still unclear how to > correctly initiate more than 2 urb transfers by reading the > documentation. > > Markus > > On Mon, Mar 6, 2017 at 6:50 AM, Markus Rechberger <mrechberger@gmail.com> wrote: >> Hi, >> >> I got one step further it turns out that the problem is indeed the >> FreeBSD Stack, the latency is terrible causing an overflow on the >> chipside. Once that happens the transfer has to be restarted (which >> requires to toggle a register). >> Is there any way to do low latency transfers with FreeBSD? >> >> Markus >> >> On Mon, Mar 6, 2017 at 6:19 AM, Markus Rechberger <mrechberger@gmail.com> wrote: >>> Hi, >>> >>> I have been trying to port a driver to freebsd for a day now and the >>> result is quite negative. >>> >>> So my feedback about libusb20 and the FreeBSD USB Kernel Stack: >>> >>> 1. the documentation is not clear how to set up asynchronous bulk >>> transfers (please explain the architecture of this API) >>> >>> 2. the errors returned by libusb20 (and probably from the kernel) are >>> not detailed enough (in certain cases I'm able to get libusb20 unknown >>> error, to my understanding every error should have some meaning). >>> >>> 3. the FreeBSD USB Stack messes around with the transfer itself >>> damaging the entire result (eg resulting in stalled USB bulk >>> transfers). >>> >>> 4. The FreeBSD data transfer implementation itself is a disaster, I'm >>> able to transfer data at a rate of 2 MB/sec, anything higher results >>> in a stalled usb transfer?! >>> >>> 5. USB Control messages are 100% slower than with other operating >>> systems (eg. it took 14 seconds to load a driver with FreeBSD while it >>> only takes 7 seconds on other systems). >>> >>> Since I have been using USB stacks with Linux, Mac and some other >>> systems I can say that FreeBSD has the most irritating implementation >>> of all. >>> >>> So finally I wonder what is wrong with FreeBSD's USB support? >>> >>> Best Regards, >>> Markus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BO4pC%2B1t67ODF7bkyVhcojXTLnFkS28RbFAc%2Be-tjNncogMAQ>