From owner-freebsd-multimedia@freebsd.org Mon Mar 6 08:53:49 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 705F6CFB4C6 for ; Mon, 6 Mar 2017 08:53:49 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA2811A4 for ; Mon, 6 Mar 2017 08:53:49 +0000 (UTC) (envelope-from mrechberger@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id y76so11445203qkb.0 for ; Mon, 06 Mar 2017 00:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/jtFLFOoeqEOlZcdaJZ94vF1ODWXI6m2YyRCGj5I9dY=; b=XOgQ2PLsV77+8nIOIpLvu7g+5kPpoVISa29ROztZRIYv0d9Mpgg11LxAhYsollWS4O OOpt/QtZ4qQgoQ6Yn+ZXjANZAN+Qz6Sm+8PCjzXWF12jAFkG1VbqJsDiFGqv1jZv11iM oQjxjYK1IxoRyn3wGIIAxG16WOA1wl39jPNikoAF3zZK84RH/BA98VMgMsA7mdKEgyne hvern3dkj9vQV6uDGEpOhWbyTo0QljXgZKm/1OeF7DncdCOouFcFJH+2x7GlUJfiIRlP W0xJGbJ3I4jFxWB6uA7ft565HWqxiXI1pakZi4ld3ysOo3WfocXt1AcvF7YNCSJY7mhn 7QHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/jtFLFOoeqEOlZcdaJZ94vF1ODWXI6m2YyRCGj5I9dY=; b=bRLXfu+ICzOITsMy3RMINC5H5L0czRuyb2EmnYDLSjxGY0f8D3WxV5D7ARzavFoi+S LnOis2owa0F/HQUfblYUClW2oMllb7jJ2AdrqW+NQZaE98f54Qv6SA5Sw7Pk4GiaTP69 tNRST1VdLKA/Qwee2oyxEAZY1S5PglTWlHDaNeBp4IiYPokds2rM98PCw+MmAAWRicFV qqUikNBq93mhS7g2W60Qs1N/64xchBBVTrEmnhPQ45i1GtzVwmU5TaxapOCcJlhxh/DH ZD3fw7yExsRiOM4qW0ypnIFty+m4TM+GCC0av+doOELtDP8VBKrHQQxXNJMLKckssVoN DR2Q== X-Gm-Message-State: AMke39mfM54cHLwbBo+ZmAY/8209Vz+r/CN1cCkqAl1LJCsazk7yM0ezBKK69Hlxd/fiwCJpevhulpACBdnzbA== X-Received: by 10.237.50.6 with SMTP id y6mr14688248qtd.115.1488790428386; Mon, 06 Mar 2017 00:53:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.114 with HTTP; Mon, 6 Mar 2017 00:53:48 -0800 (PST) In-Reply-To: References: From: Markus Rechberger Date: Mon, 6 Mar 2017 09:53:48 +0100 Message-ID: Subject: Re: What is wrong with FreeBSD and USB Support To: freebsd-multimedia@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 08:53:49 -0000 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 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 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 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