From owner-freebsd-arm@FreeBSD.ORG Sun Apr 7 07:17:58 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CAE2F3ED; Sun, 7 Apr 2013 07:17:58 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 65B361B84; Sun, 7 Apr 2013 07:17:58 +0000 (UTC) Received: from mail.bitfrost.no (mail.bitfrost.no [46.29.221.36]) by mta.bitpro.no (Postfix) with ESMTP id 1C72E7A21D; Sun, 7 Apr 2013 09:03:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bitfrost.no Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hanspetter) by mail.bitfrost.no (Postfix) with ESMTPSA id 8371720A72; Sun, 7 Apr 2013 09:02:58 +0200 (CEST) Message-ID: <51611A7B.2010105@bitfrost.no> Date: Sun, 07 Apr 2013 09:04:27 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S MIME-Version: 1.0 To: Oleksandr Tymoshenko Subject: Re: Beaglebone USB driver (Mentor Graphics OTG) References: <51608AA4.2020804@bluezbox.com> In-Reply-To: <51608AA4.2020804@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, usb@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 07:17:58 -0000 On 04/06/13 22:50, Oleksandr Tymoshenko wrote: > Hello, > > 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. > > 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 > > 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. > > Patch: > http://people.freebsd.org/~gonzo/arm/patches/beaglebone-musb.diff Hi, Looks like you've got the grasp of the USB controller stuff :-) Some comments: 1) Use DPRINTFN(-1, ...) instead of printf() for all printf() that are not part of boot dmesg. + break; + default: + td->transfer_type = 0; + printf("Invalid USB speed: %d\n", speed); + break; + } 2) You should implement if HOST mode, support for SUSPEND and RESUME. See EHCI driver. Basically what you need is: 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. b) switch on USB suspend signalling. At resume: c) do resume signalling, similar to EHCI/UHCI I think. d) switch on channel tokens. case UHF_PORT_SUSPEND: + if (sc->sc_mode == MUSB2_HOST_MODE) + printf("TODO: Set UHF_PORT_SUSPEND\n"); + break; 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. --HPS