Re: RFC: Devices, buses and hotplug

Jeff Garzik (jgarzik@pobox.com)
Sun, 06 Jun 1999 15:21:58 -0400

"David S. Miller" wrote:
>
> Date: Sun, 06 Jun 1999 14:42:20 -0400
> From: Jeff Garzik <jgarzik@pobox.com>
>
> 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.

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...

Both Matrox and newer S3 cards, maybe others, are 100% MMIO after
wakeup, and can operate 100% without any little endian data in the
driver whatsoever (except, sometimes, in the wakeup code). The
designers of these cards specifically included some big endian
optimizations on-board.

Jeff

-
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/