In message: <[EMAIL PROTECTED]>
Rafal Jaworowski <[EMAIL PROTECTED]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
