Re: RFC: Devices, buses and hotplug

Jeff Garzik (jgarzik@pobox.com)
Sun, 06 Jun 1999 14:42:20 -0400

"David S. Miller" wrote:
>
> Date: Sun, 06 Jun 1999 13:53:51 -0400
> From: Jeff Garzik <jgarzik@pobox.com>
>
> This is also very valuable. The newer S3 cards (and others as well)
> fully support big endian as well as little endian, and it would be nice
> to avoid the byteswapping that occurs in some current read*()
> implementations, such as on PPC (and Sparc too?).
>
> No, it is invaluable and leads to sloppy and inconsistant coding.
>
> Byte swapping happens transparently on Sparc for PCI devices, the
> normal read{b,w,l}() etc. interfaces are used for everything and it
> just works.
>
> It works because we architected Sparc to map PCI areas in the proper
> endianness.
>
> The end result is that you should not need "big endian" supporting
> PCI devices, and in fact I consider such devices silly. Little endian
> is the native PCI byte ordering, and any worthwhile architecture we
> care about has hardware facilities to make them accessible at zero
> cost (either via MMU mappings of device areas, or endianness
> attributes in the load/store instructions themselves).

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.

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.

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)

> In general, when you start seeing a lot of "knobs" in an interface, it
> starts to enter ugly territory, let's avoid ending up with a mess like
> Solaris's DDI ok? :-)

Point taken ;-)

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/