Date: Wed, 26 Jun 2013 17:53:20 -0700 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Hans Petter Selasky <hps@bitfrost.no> Cc: arm@freebsd.org, usb@freebsd.org Subject: Re: Beaglebone USB driver (Mentor Graphics OTG) Message-ID: <0927BB4C-6917-408D-B102-AB98F72314B6@bluezbox.com> In-Reply-To: <51611A7B.2010105@bitfrost.no> References: <51608AA4.2020804@bluezbox.com> <51611A7B.2010105@bitfrost.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-04-07, at 12:04 AM, Hans Petter Selasky <hps@bitfrost.no> wrote: > On 04/06/13 22:50, Oleksandr Tymoshenko wrote: >> Hello, >>=20 >> This is first iteration of Host Mode support for Mentor Graphics >> OTG USB controller. I tested it by building kernel with USB memory >> stick mounted as /usr/obj, resulting kernel was bootable and worked = fine. >> I reused some ideas (mostly for channel-management) from >> DWT OTG driver. >>=20 >> Some pieces are still missing: >> - Support for SPLIT transactions, I don not have high speed hub >> right now to test it, but implementing it should be really >> straighforward. >> - Isochronous transfers. I do not have hardware to test this. Does >> anybody have any suggestion about simple use case? >> - Control Data OUT transaction >> - Wrapper for atmel HW has not ben synced with new core logic = requirements >> yet >>=20 >> Please review and test. I tested it only with gcc-built kernel/world. >> Now when >> first iteration is finished I'm going to update all my boards to new >> world order >> (clang/EABI) and re-test this stuff. >>=20 >> Patch: >> http://people.freebsd.org/~gonzo/arm/patches/beaglebone-musb.diff >=20 > Hi, >=20 > Looks like you've got the grasp of the USB controller stuff :-) >=20 > Some comments: >=20 > 1) Use DPRINTFN(-1, ...) instead of printf() for all printf() that are = not part of boot dmesg. >=20 > + break; > + default: > + td->transfer_type =3D 0; > + printf("Invalid USB speed: %d\n", = speed); > + break; > + } >=20 >=20 > 2) You should implement if HOST mode, support for SUSPEND and RESUME. = See EHCI driver. Basically what you need is: >=20 > a) USB transfers are stopped/paused. I know there is a hack you need = if the host transfer cancel hangs, and that is to write a dummy device = address and wait for the USB transfer to error out after 250 us max. >=20 > b) switch on USB suspend signalling. >=20 >=20 > At resume: >=20 > c) do resume signalling, similar to EHCI/UHCI I think. >=20 > d) switch on channel tokens. >=20 > case UHF_PORT_SUSPEND: > + if (sc->sc_mode =3D=3D MUSB2_HOST_MODE) > + printf("TODO: Set UHF_PORT_SUSPEND\n"); > + break; >=20 >=20 >=20 > 3) Make sure that channels are not generating tokens if they are = aborted / cancelled / timedout. This can not be verified using a USB = mass storage device. Verify this by connecting a USB serial adapter. Try = to open/close /dev/cuaU0. Make sure it does not loose any bytes and that = channel cancel does not hang forever. Thanks for review. Took me quite some time to get back=20 to the driver but here is updated version that addresses some=20 of the issues you've mentioned: = http://people.freebsd.org/~gonzo/arm/patches/beaglebone-usb-20130626.diff It fixes several bugs, adds proper SPLIT transactions support and=20 suspend/resume signalling. I tested it with urtwn-based WiFi chip, mass storage device, USB keyboard connected directly and using=20 high-speed hub. Suspend/resume is not 100% complete though. I can use USB serial=20 port adapter if it's suspended/resumed unconnected. But it stuck if I do=20= the test while connected. Is it the right way to test it?=20 On the related note: can somebody suggest budget USB protocol analyzer with support for high-speed bus?=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0927BB4C-6917-408D-B102-AB98F72314B6>