LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Krzysztof Helt <krzysztof.h1@poczta.fm>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	avorontsov@ru.mvista.com, linuxppc-dev@ozlabs.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, adaplas@gmail.com
Subject: Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Date: Mon, 18 Feb 2008 08:18:47 +0100	[thread overview]
Message-ID: <20080218081847.e9e65f2f.krzysztof.h1@poczta.fm> (raw)
In-Reply-To: <Pine.LNX.4.64.0802171030330.6848@anakin>

On Sun, 17 Feb 2008 10:44:32 +0100 (CET)
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> On Fri, 15 Feb 2008, Anton Vorontsov wrote:
> > On Thu, Feb 14, 2008 at 10:49:42PM -0800, Andrew Morton wrote:
> > > On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> > > Actually...  should CONFIG_FB_FOREIGN_ENDIAN exist, or should this feature
> > > be permanently enabled?
> > 
(...)
> 
> The notion of `FOREIGN_ENDIAN' is relative, as it depends on the
> architecture you're compiling for.
> 
> Suppose you have a PCI graphics card with a frame buffer that's always
> big endian. When compiling for a big endian platform, the driver won't
> depend on FB_FOREIGN_ENDIAN. When compiling for a little endian
> platform, it will.
> 
> Shouldn't we add LITTLE_ENDIAN and BIG_ENDIAN Kconfig vars first, just
> like we have 64BIT?
> 

I disagree here. The FOREIGN_ENDIAN is enough. It is determined only by
graphics chip endianess and CPU (arch) endianess.
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess. 
I understand that this patch is for chips which cannot reorder bytes by themselves.

So the FOREIGN_ENDIANESS flag should be set by the driver if it is needed
(if the graphics chip is BE and CPU is LE a simple #ifdef will add the flag).

> 
> I'd like to handle this in Kconfig (cfr. above).
> 

Again, it is possible. It is enough to put one rule which enables
the FOREIGN_ENDIAN if the architecture endianess is "foreign"
for the driver. The advantage here is that it  can be set only
for drivers which need it (as some driver can handle it without
this code). It should be hidden option set only internally if needed
(no user selectable).

I tested this patch on the s3c2410fb with disabled byte order
corrections by the graphics chip itself. It worked for 8-bit depth
but not for 16-bit depth (pixel position seemed ok but wrong tux'
colors). I will investigate. The s3c2410fb is BE and the kernel
was arm LE.

I would like to extend this patch to fb depths below 8-bit. The
s3c2410fb cannot handle this correctly with LE kernel.

Kind regards,
Krzysztof

----------------------------------------------------------------------
Masz ostatnia szanse !
Sprawdz >>> http://link.interia.pl/f1d02  


  reply	other threads:[~2008-02-18  7:48 UTC|newest]

Thread overview: 21+ 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 16:45   ` Anton Vorontsov
2008-02-17  9:44     ` [Linux-fbdev-devel] " Geert Uytterhoeven
2008-02-18  7:18       ` Krzysztof Helt [this message]
2008-02-18 17:30         ` Valdis.Kletnieks
2008-02-18 17:37           ` Anton Vorontsov
2008-02-18 23:35           ` Clemens Koller
2008-02-19  0:35             ` Benjamin Herrenschmidt
2008-02-19 11:27               ` Clemens Koller
2008-02-19 12:05                 ` Andrew Morton
2008-02-19 12:22                   ` Clemens Koller
2008-02-20  0:47                   ` Valdis.Kletnieks
2008-02-20  0:50                     ` Benjamin Herrenschmidt
2008-02-20  0:56                   ` Paul Mackerras
2008-02-20 12:18                     ` Anton Vorontsov
2008-02-20 20:38                       ` Benjamin Herrenschmidt
2008-02-21  4:59                       ` Paul Mackerras
2008-02-20 15:43                     ` Clemens Koller
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=20080218081847.e9e65f2f.krzysztof.h1@poczta.fm \
    --to=krzysztof.h1@poczta.fm \
    --cc=adaplas@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avorontsov@ru.mvista.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).