Introduce support for little endian PowerPC

Michel Dänzer michel at daenzer.net
Mon Oct 4 21:30:42 EST 2010


On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote: 
> On Fri, 2010-10-01 at 18:20 +0200, Michel Dänzer wrote:
> > On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: 
> > > 
> > > Now, the main reasons in practice are anything touching graphics.
> > > 
> > > There's quite a few IP cores out there for SoCs that don't have HW
> > > swappers, and -tons- of more or less ugly code that can't deal with non
> > > native pixel ordering (hell, even Xorg isn't good at it, we really only
> > > support cards that have HW swappers today).
> > 
> > That's not true. Even the radeon driver doesn't really need the HW
> > swappers anymore with KMS.
> 
> And last I looked X still pukes if you give it a pixmap in non native
> byte order but that might have been fixed.

I'm not sure what exactly you mean by that, but I'm not aware of any
such issues offhand.


> > > There's an even bigger pile of application code that deals with graphics
> > > without any regard for endianness and is essentially unfixable.
> > 
> > Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL
> > have well-defined semantics wrt endianness, allowing the drivers to
> > handle any necessary byte swapping internally, and IME the vast majority
> > of apps handle this correctly.
> 
> So why is it so hard to get any video card working on ppc ? :-)

I didn't say anything about that, just that IME it should be mostly
possible to deal with endianness within the driver stack.


Note that I'm not arguing against these changes, just pointing out some
apparent inaccuracies in the reasoning for them.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer


More information about the Linuxppc-dev mailing list