Messages in this thread | | | Date | Sun, 6 Jun 1999 12:34:26 -0700 | From | "David S. Miller" <> | Subject | Re: RFC: Devices, buses and hotplug |
| |
Date: Sun, 06 Jun 1999 15:21:58 -0400 From: Jeff Garzik <jgarzik@pobox.com>
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/
| |