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
next prev parent 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: linkBe 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).