From owner-freebsd-usb@FreeBSD.ORG Fri Mar 7 15:43:08 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 E3CE71065671 for ; Fri, 7 Mar 2008 15:43:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A04538FC14 for ; Fri, 7 Mar 2008 15:43:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m27FesuN036947; Fri, 7 Mar 2008 08:40:54 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 07 Mar 2008 08:41:26 -0700 (MST) Message-Id: <20080307.084126.387194019.imp@bsdimp.com> To: raj@semihalf.com From: "M. Warner Losh" In-Reply-To: <47D1606D.3020506@semihalf.com> References: <47D15050.3010809@semihalf.com> <20080307.081502.-116098145.imp@bsdimp.com> <47D1606D.3020506@semihalf.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:43:09 -0000 In message: <47D1606D.3020506@semihalf.com> Rafal Jaworowski writes: : 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. The platform code description is good for "why it is needed." Maybe have a better "what it is" in the ehci.c/ehcivar.h code. Warner