From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: avorontsov@ru.mvista.com
Cc: linux-fbdev-devel@lists.sourceforge.net, adaplas@gmail.com,
Krzysztof Helt <krzysztof.h1@poczta.fm>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Paul Mackerras <paulus@samba.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Date: Thu, 21 Feb 2008 07:38:40 +1100 [thread overview]
Message-ID: <1203539920.10422.13.camel@pasglop> (raw)
In-Reply-To: <20080220121818.GA20836@localhost.localdomain>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: avorontsov@ru.mvista.com
Cc: Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Clemens Koller <clemens.koller@anagramm.de>,
linux-fbdev-devel@lists.sourceforge.net, adaplas@gmail.com,
Krzysztof Helt <krzysztof.h1@poczta.fm>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Date: Thu, 21 Feb 2008 07:38:40 +1100 [thread overview]
Message-ID: <1203539920.10422.13.camel@pasglop> (raw)
In-Reply-To: <20080220121818.GA20836@localhost.localdomain>
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.
next prev parent reply other threads:[~2008-02-20 20:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 15:44 [PATCH 1/2] fb: add support for foreign endianness Anton Vorontsov
2008-02-05 19:07 ` Anton Vorontsov
2008-02-15 6:49 ` Andrew Morton
2008-02-15 6:49 ` Andrew Morton
2008-02-15 6:49 ` Andrew Morton
2008-02-15 16:45 ` Anton Vorontsov
2008-02-15 16:45 ` Anton Vorontsov
2008-02-17 9:44 ` Geert Uytterhoeven
2008-02-17 9:44 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2008-02-17 9:44 ` Geert Uytterhoeven
2008-02-18 7:18 ` Krzysztof Helt
2008-02-18 7:18 ` [Linux-fbdev-devel] " Krzysztof Helt
2008-02-18 7:18 ` Krzysztof Helt
2008-02-18 17:30 ` Valdis.Kletnieks
2008-02-18 17:30 ` [Linux-fbdev-devel] " Valdis.Kletnieks
2008-02-18 17:30 ` Valdis.Kletnieks
2008-02-18 17:37 ` Anton Vorontsov
2008-02-18 17:37 ` [Linux-fbdev-devel] " Anton Vorontsov
2008-02-18 17:37 ` Anton Vorontsov
2008-02-18 23:35 ` Clemens Koller
2008-02-18 23:35 ` Clemens Koller
2008-02-19 0:35 ` Benjamin Herrenschmidt
2008-02-19 0:35 ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2008-02-19 11:27 ` Clemens Koller
2008-02-19 12:05 ` Andrew Morton
2008-02-19 12:05 ` [Linux-fbdev-devel] " Andrew Morton
2008-02-19 12:05 ` Andrew Morton
2008-02-19 12:22 ` Clemens Koller
2008-02-19 12:22 ` Clemens Koller
2008-02-20 0:47 ` Valdis.Kletnieks
2008-02-20 0:47 ` Valdis.Kletnieks
2008-02-20 0:50 ` Benjamin Herrenschmidt
2008-02-20 0:50 ` Benjamin Herrenschmidt
2008-02-20 0:56 ` Paul Mackerras
2008-02-20 0:56 ` Paul Mackerras
2008-02-20 12:18 ` Anton Vorontsov
2008-02-20 12:18 ` Anton Vorontsov
2008-02-20 20:38 ` Benjamin Herrenschmidt [this message]
2008-02-20 20:38 ` Benjamin Herrenschmidt
2008-02-21 4:59 ` Paul Mackerras
2008-02-21 4:59 ` Paul Mackerras
2008-02-20 15:43 ` Clemens Koller
2008-02-20 15:43 ` [Linux-fbdev-devel] " Clemens Koller
2008-02-20 15:43 ` Clemens Koller
2008-02-16 11:49 ` Benjamin Herrenschmidt
2008-02-16 11:49 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1203539920.10422.13.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=adaplas@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=avorontsov@ru.mvista.com \
--cc=geert@linux-m68k.org \
--cc=krzysztof.h1@poczta.fm \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.