[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1203539920.10422.13.camel@pasglop>
Date: Thu, 21 Feb 2008 07:38:40 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: avorontsov@...mvista.com
Cc: Paul Mackerras <paulus@...ba.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Clemens Koller <clemens.koller@...gramm.de>,
linux-fbdev-devel@...ts.sourceforge.net, adaplas@...il.com,
Krzysztof Helt <krzysztof.h1@...zta.fm>,
linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign
endianness
On Wed, 2008-02-20 at 15:18 +0300, Anton Vorontsov wrote:
> On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
> > Andrew Morton writes:
> >
> > > Bizarrely, the original author of the patch (Anton) has fallen off the cc.
> > > Could whoever did that please thwap himself?
> > >
> > > Anyway, my head is now officially spinning. Did anyone actually have a
> > > reason why we shouldn't proceed with Anton's patch?
> >
> > I was wondering if it would be sufficient to provide alternative
> > versions of fb_readl, fb_writel etc. that do byte-swapping.
>
> This is of course viable alternative. And I was considering this, but
> later I abandoned the idea: that way we'll end up doing math in the
> native endianness and then converting it to the foreign. This feels
> ugly in contrast when we can do the right math in the first place, per
> framebuffer.
Also, the type of swap to do in fb_readl/writel would have to depend
on the bit depth which is kind of ugly.
> > That
> > would mean that all framebuffers would have to have the same
> > endianness,
>
> Yup, another downside of changing the code to fix some narrow
> problem. Plus, this means things will break if/when we'll attach
> PCI video card into the MPC8360E-RDK.
Right.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists