The following 3 patches add support big-endian OHCI implementations.
This is version 2 of these patches. They have been cleaned up
from the original and include support for all known quirks of
these two big-endian OHCI implementations. Thanks to Sylvain
Munaut <[EMAIL PROTECTED]> for the idea to consolidate the
ending-switching logic in the big_endian() macro.
These patches have been tested on IBM's stb04xxx and Freescale's
MPC52xx processors. They have also been tested on an x86-based
system to verify that behavior on existing little-endian
implementations hasn't changed.
I have successfully tested this code on x86 and ppc systems with
the following USB devices: cascaded hubs, keyboard, mouse,
soundblaster audio, pegasus ethernet, pl2303 serial, flash storage,
cdrw.
The patches were implemented with C macros and inline functions
so that little-endian-only systems incur no runtime penalty.
Similarly for big-endian-only systems. A runtime switch is
only needed when both little-endian and big-endian controllers
are in use on the same system.
Patches 1 and 2 are logically one entity. I split them out
because Patch 1 is relatively small and contains the logic
changes that require significant analysis. Patch 2 is larger,
but consists almost entirely of simple transforms and thus
requires minimal analysis. Patch 1 stands on it's own and
can be tested separately if desired.
Patch 1 Replace little-endian-only constants in ohci.h with
cpu-native constants, so that they can be converted
to little-endian or big-endian depending on the OHCI
controller being used.
Patch 2 This is the bulk of the patch and adds support to the
OHCI code for big-endian controllers while maintaining
the existing support for little-endian controllers.
This is done primarily by applying the following transforms
when dealing with controller data:
ohci_readl(p) --> ohci_read(ohci, p)
writel(v, p) --> ohci_writel(ohci, v, p)
cpu_to_le16(v) --> cpu_to_ohci16(ohci, v)
cpu_to_le16p(v) --> cpu_to_ohci16p(ohci, v)
cpu_to_le32(v) --> cpu_to_ohci32(ohci, v)
cpu_to_le32p(v) --> cpu_to_ohci32p(ohci, v)
le16_to_cpu(v) --> ohci16_to_cpu(ohci, v)
le16_to_cpup(v) --> ohci16_to_cpup(ohci, v)
le32_to_cpu(v) --> ohci32_to_cpu(ohci, v)
le32_to_cpup(v) --> ohci32_to_cpup(ohci, v)
The new functions devolve to the original leXX forms if
the platform doesn't support big-endian ohci controllers.
They take on the beXX forms when only big-endian controllers
are supported.
A bit in the flags field of struct ohci_hcd, OHCI_BIG_ENDIAN,
enables the the transformed functions to support both big-endian
and little-endian controllers at runtime, when needed.
Patch 3 Adds support for the ohci controllers found on the IBM STB04xxx
and Freescale MPC52xx embedded chips. In addition to the
low level hcd support added in drivers/usb/host/ohci-ocp.c,
it contains code for 2 quirks of these OHCI implementations.
Quirk 1: The IBM and Freescale implementations differ on half
of the 32-bit hcca->frame_no field contains the frame number.
I created an inline ohci_frame_no function to centralize the
handling of this quirk.
Quirk 2: On both big-endian controllers, the order that the
hardware accesses the td->hwPSW is strange. The problem is
that while td->hwPSW is an array of u16, the OHCI spec
(incorrectly, IMHO) describes it as an array of u32, with
each element containing 2 u16 fields in little endian order.
IBM and Freescale implemented according to the spec and the
result is an array of big-endian u16 elements which the OHCI
hardware uses in this order: hwPSW[1], hwPSW[0], hwPSW[3],
hwPSW[2], etc. Since we only use one of the hwPSW array
elements, we need to allocate two because the hardware
accesses hwPSW[1]. I centralized the handling of this
quirk in the ohci_hwPSW function.
I would like to get these patches into the linux-2.6 tree soon.
I think they are ready now, since I've been using them for a while.
I'd appreciate others trying it out as they are able, so we can gain
confidence that these patches don't break anything.
Note that another of my patches to avoid having the OHCI controller
DMA to/from stack variables is also needed for operation on ppc 4xx
and BOOKE processors, including the stb04xxx. The DMA patch is
independent of these patches and is needed for both little-endian
and big-endian controllers on non-cache-consistent processors.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
