On Wed, 2008-10-01 at 11:46 +0200, Carsten Schlote wrote: > > > The framebuffer use-case is currently the only one, where such a > hardware-swapper could be really useful. But still the drivers would > have to know about this feature, it would require query/set macros/fcts > for endian translation modes in the kernel, ... - in short it causes > lots of extra overhead. And for framebuffers the need for such hard-ware > swappers can be eleminated by using the right framebuffer mode.
Actually, fb's are -the- case where it's really necessary to have endian swappers when they sit on PCI due to the way byte lanes are swapped on a PCI host bridge on a BE platform, if you want to keep the same pixel order as an x86 which is usually not only all that cards support, while still having SW use native order which is usually all that the X server supports :-) > I fear, that such hard-wired 'magic' swapping is the source and reason > for some of my current problems. I wouldn't be surprised. The worst case I've seen is HW engineers trying to be too smart for their own good and swapping the byte lanes of >8 bits data stream fifo's such as IDE (yeah, it makes the IDE ID block more directly readable, at the expense of swapping all the data effectively preventing the use of DMA unless you are fine with a custom on-disk format incompatible with everything else). Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
