Is this the case on PPC too though? Many of the LinuxPPC machines
out there are leagues slower than UltraSparc and may not do this
sort of thing. From what I understand that is the logic behind the
'READx_WORKS' code at the beginning of drivers/video/matroxfb.c.
UltraSparc is fast enough that any sort of software byte swapping
shouldn't matter anyway...
I never got down to facts about whether it was an issue of the PPC
supporting it in HW or the PPC developers just mis-designed their
framework and now require big endian friendly devices just to work.
My intuition is the latter, I remember the PPC having HW facilities
just like I described for UltraSparc.
And if this is in fact true, see where beginning to put the device in
big endian mode gets them? Now they have this ugly dependency there,
which they could have foregone from the beginning.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/