Workarounds in generic EHCI code
Rafal Jaworowski
raj at semihalf.com
Fri Mar 7 15:34:05 UTC 2008
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
More information about the freebsd-usb
mailing list