LKML Archive on
help / color / mirror / Atom feed
From: Geert Uytterhoeven <>
Cc: Andrew Morton <>,,,
Subject: Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Date: Sun, 17 Feb 2008 10:44:32 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802171030330.6848@anakin> (raw)
In-Reply-To: <20080215164542.GB16810@localhost.localdomain>

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 <> wrote:
> > > This patch adds support for the framebuffers with non-native
> > > endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will
> > > be used by the drivers. Depending on the host endianness this flag
> > > will be overwritten by FBINFO_BE_MATH internal flag, or cleared.
> > > 
> > > Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
> > 
> > That's a pretty large patch to fbdev core,
> Yes, but changes are mostly trivial. No insurance of typos and thinkos
> though. OTOH, it survived my tests.
> > and Tony appears to have gone
> > offline again and you didn't cc the fbdev mailing list.
> P:      Antonino Daplas
> M:
> L: (subscribers-only)
> I'm lazy to subscribe on occasional patches. Yup, this is hardly
> an excuse...

While linux-fbdev is subscribers-only, non-subscribers are not plainly
rejected, but moderated, so the casual patch/comment/question comes

I'll cook up a patch for MAINTAINERS to clarify.

> > Actually...  should CONFIG_FB_FOREIGN_ENDIAN exist, or should this feature
> > be permanently enabled?
> It should not. Because with CONFIG_FB_FOREIGN_ENDIAN enabled, drawing
> might be a little bit slower, because of external checks for endianness
> (I didn't noticed any slowdown, but I guess it's still measurable if we
> find some fb benchmark).

> > I'd like to at least queue a patch in -mm so that CONFIG_FB_FOREIGN_ENDIAN
> > is forced-on, so the code gets some runtime testing.  Will that break
> > anything?
> Nope, it should not break anything, just possible fbconsole/tux drawing
> slowdown.

Tux drawing speed doesn't really matter, as it's done once only.
Console text drawing is different.

`time cat MAINTAINERS' is a good test. Of course, is most time is spent
in scrolling, you won't see much difference.

So probably we need a test file that contains lines of text interspersed
with `HOME' escape sequences, so we don't scroll?

> Thinking about it a little bit more, I believe we want to add a choice,
> which exactly foreign endianness we want to compile-in. Then, if we're
> pretty confident that particular BE machine uses only LE framebuffer,
> gcc can optimize away endianness checks.
> Patch on top of previous inlined here. With that patch, slowdown is
> possible with CONFIG_FB_BOTH_ENDIAN option only, which is still
> default if FOREIGN_ENDIAN is selected.
> With this patch FB_FOREIGN_ENDIAN converted to menuconfig with the
> choice inside: which type of foreign endianness we want to compile-in.

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?

> As a bonus, now fb subsystem will refuse to register framebuffer with
> unsupported endianness, and will suggest a way to solve the problem.

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



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

  reply	other threads:[~2008-02-17  9:44 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     ` Geert Uytterhoeven [this message]
2008-02-18  7:18       ` [Linux-fbdev-devel] " Krzysztof Helt
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0802171030330.6848@anakin \ \ \ \ \ \ \ \

* 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).