From owner-freebsd-usb@FreeBSD.ORG Fri Mar 7 15:34:05 2008 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB581065670 for ; Fri, 7 Mar 2008 15:34:05 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id AE9FA8FC30 for ; Fri, 7 Mar 2008 15:34:05 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id m27FY1js023237; Fri, 7 Mar 2008 08:34:03 -0700 Received: from localhost (unknown [127.0.0.1]) by mail.semihalf.com (Postfix) with ESMTP id AE1C0143CA; Fri, 7 Mar 2008 16:44:06 +0100 (CET) Received: from mail.semihalf.com ([127.0.0.1]) by localhost (mail.semihalf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03149-03; Fri, 7 Mar 2008 16:44:05 +0100 (CET) Message-ID: <47D1606D.3020506@semihalf.com> Date: Fri, 07 Mar 2008 16:34:05 +0100 From: Rafal Jaworowski MIME-Version: 1.0 To: "M. Warner Losh" References: <47D15050.3010809@semihalf.com> <20080307.081502.-116098145.imp@bsdimp.com> In-Reply-To: <20080307.081502.-116098145.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at semihalf.com Cc: usb@freebsd.org Subject: Re: Workarounds in generic EHCI code X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 15:34:05 -0000 M. Warner Losh wrote: > : I'd like to hear comments on the proper way of handling non-standard behaviour > : of a host controller when a workaround needs to be aplied at the shared code > : level. In the following I followed an example of existing VIA/ATI chip workaround: > : > : http://people.freebsd.org/~raj/patches/misc/usb-workarounds.diff > : > : The respective flags are potentially set in platform-specific attachment > : driver code, which knows if they apply etc. > : > : Does anybody see a better way to handle such cases? > > This seems fine, but... > > +#define EHCI_SCFLG_USBMODEBUG 0x0003 /* workaround for Marvell 88F5281 chipsets */ > +#define EHCI_SCFLG_FORCESPEED 0x0004 /* workaround for Marvell chipsets */ > +#define EHCI_SCFLG_NORESTERM 0x0005 /* don't terminate reset sequence on Marvell chipsets */ > > Two comments. '3' isn't a bit, so those values need to change. Ah, sure, thanks. > Second, I'd make the descriptions a little better. The first two > aren't very helpful... > I have more detailed descriptions in the platform code that sets this, e.g. /* * Workaround for Marvell 88F5281 integrated EHCI controller: reset of * the EHCI core clears the USBMODE register, which sets the core in * an undefined state (neither host nor agent), so it needs to be set * again for proper operation. * * Refer to errata document (p. 5.24 GL USB-2) for details. */ But maybe it really better fits in the ehic.c/ehcivar.h.. I'll try to improve this. Rafal