AFAIK PCI is endian-independent. (I think I saw that in a post
from Martin Mares recently?) It is only that 99.999% of the PCI
devices out there are PC-centric and little endian.
Stop living by the law of specifications, and look to reality for the
real answers :-) The point to be taken is that since %99.999 of all
PCI devices are little endian, is any "hey we support this thing in
big endian on PCI" really worth it?
Anyway... one question. Who does the byte swapping, the host CPU
or the peripheral?
If the answer is 'host CPU', then my response is I can write clean
code that is faster because it takes advantage of big endian
peripheral support.
Nope, the host CPU does it, but at _ZERO_ cost. You have two ways
usually to get it done:
1) Load/Store instruction attributes:
ldxa [%src] ASI_PL, %reg
stxa %reg, [%dest]
ldxa [%src], %reg
stxa %reg, [%dest] ASI_PL
Those two examples, on UltraSparc, load from little endian and
store to big endian, and vice versa. It can even be done in this
way for UltraSparc's high-bandwidth 64-byte block loads and
stores.
2) MMU translations (again, this is on the 'host CPU'). Then it is
completely transparent to the actual load or store instruction, and
thus no special attributes are needed.
I think a lot of confusion about "PCI access" on big endian systems
stems from the fact that most people do not understand that the HW
people putting together big endian CPU systems with PCI have put this
nice infrastructure in place.
It seems to me that, with the amount of video data being
transferred to a hi-res video card, a lot of byte swapping is
avoided by the host CPU. Is this incorrect? (I don't have a big
endian machine to test my assertions)
One can get full bandwidth, in and out of the frame buffer, in any
endianness you so desire from any endianness you so desire. There is
no issue.
The kernel need not this bloat, trust me.
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/