From: Kumar Gala <galak@kernel.crashing.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <jwboyer@gmail.com>,
paulus@samba.org, linuxppc-dev@lists.ozlabs.org,
Ian Munsie <imunsie@au1.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: Introduce support for little endian PowerPC
Date: Fri, 1 Oct 2010 12:59:31 -0500 [thread overview]
Message-ID: <BBD78246-343E-4A96-9E55-3E40AD628C0B@kernel.crashing.org> (raw)
In-Reply-To: <1285935283.2463.78.camel@pasglop>
On Oct 1, 2010, at 7:14 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-10-01 at 07:30 -0400, Josh Boyer wrote:
>>
>>> From a community aspect is anyone actually going to use this? Is
>> this going to be the equivalent of voyager on x86? I've got nothing
>> against some of the endian clean ups this introduces. However the
>> changes to misc_32.S are a bit ugly from a readability point of view.
>> Just seems like this is likely to bit-rot pretty quickly.
>>
>> I'm with Kumar on this one. Why would we want to support this? I
>> can't say I would be very willing to help anyone run in LE mode, let
>> alone have it randomly selectable.
>
> There's some good reasons on the field ... sadly.
>
> At this stage this is mostly an experiment, which went pretty well in
> the sense that it's actually quite easy and a lot of the "fixes" are
> actually reasonable cleanups to carry.
>
> Now, the main reasons in practice are anything touching graphics.
>
> There's quite a few IP cores out there for SoCs that don't have HW
> swappers, and -tons- of more or less ugly code that can't deal with non
> native pixel ordering (hell, even Xorg isn't good at it, we really only
> support cards that have HW swappers today).
>
> There's an even bigger pile of application code that deals with graphics
> without any regard for endianness and is essentially unfixable.
>
> So it becomes a matter of potential customers that will take it if it
> does LE and won't if it doesn't ...
>
> Now, I don't have a problem supporting that as the maintainer, as I
> said, from a kernel standpoint, it's all quite easy to deal with. Some
> of the most gory aspects in misc_32.S could probably be done in a way
> that is slightly more readable, but the approach is actually good, I
> think, to have macros to represent the high/low parts of register pairs.
>
> So at this stage, I'd say, let's not dismiss it just because we all come
> from a long education of hating LE for the sake of it :-)
>
> It makes -some- sense, even if it's not necessarily on the markets
> targeted by FSL today for example. At least from the kernel POV, it
> doesn't seem to me to be a significant support burden at all.
>
> Cheers,
> Ben.
I'm not against it, and I agree some of the patches seem like good clean up. I'm concerned about this bit rotting pretty quickly.
- k
next prev parent reply other threads:[~2010-10-01 18:00 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-01 7:05 Ian Munsie
2010-10-01 7:05 ` [PATCH 01/18] powerpc: Add ability to build little endian kernels Ian Munsie
2010-10-01 9:18 ` Kumar Gala
2010-10-01 11:28 ` Josh Boyer
2010-10-01 12:09 ` Benjamin Herrenschmidt
2010-10-01 11:40 ` Josh Boyer
2010-10-01 12:22 ` Benjamin Herrenschmidt
2010-10-01 7:05 ` [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper Ian Munsie
2010-10-01 7:13 ` Geert Uytterhoeven
2010-10-01 7:19 ` Ian Munsie
2010-10-01 7:05 ` [PATCH 03/18] powerpc: Support parsing a little endian kernel from zImage wrapper Ian Munsie
2010-10-01 7:05 ` [PATCH 04/18] powerpc: Allow taishan platform to boot a little endian kernel Ian Munsie
2010-10-01 7:05 ` [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets Ian Munsie
2010-10-01 11:27 ` Josh Boyer
2010-10-06 1:28 ` Ian Munsie
2010-10-06 1:55 ` Josh Boyer
2010-10-06 2:10 ` Sean MacLennan
2010-10-01 7:05 ` [PATCH 06/18] powerpc 44x: Set E bit in TLBs and PTEs when CPU is in little endian mode Ian Munsie
2010-10-01 7:06 ` [PATCH 07/18] powerpc: Use generic bitops for little endian bitmap operations Ian Munsie
2010-10-01 7:06 ` [PATCH 08/18] powerpc: Include the appropriate endianness header Ian Munsie
2010-10-01 7:06 ` [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness Ian Munsie
2010-10-03 3:15 ` Grant Likely
2010-10-03 6:22 ` Benjamin Herrenschmidt
2010-10-01 7:06 ` [PATCH 10/18] powerpc: Support endian agnostic MMIO Ian Munsie
2010-10-01 7:06 ` [PATCH 11/18] powerpc: Make assembly endian agnostic when accessing 64bit values Ian Munsie
2010-10-01 7:06 ` [PATCH 12/18] powerpc 44x: Handle TLB miss regardless of endianness Ian Munsie
2010-10-01 7:06 ` [PATCH 13/18] powerpc 44x: Make DCR endianness agnostic Ian Munsie
2010-10-01 7:06 ` [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports Ian Munsie
2010-10-07 23:23 ` Grant Likely
2010-10-01 7:06 ` [PATCH 15/18] mtd: Fix endianness issues from device tree Ian Munsie
2010-10-01 19:29 ` Artem Bityutskiy
2010-10-01 7:06 ` [PATCH 16/18] powerpc: Fix endianness issues in alignment handler Ian Munsie
2010-10-01 7:06 ` [PATCH 17/18] net: Fix endianess issues in IBM newemac driver Ian Munsie
2010-10-01 7:06 ` [PATCH 18/18] powerpc: Fix jiffies variable on little endian Ian Munsie
2010-10-01 9:02 ` Introduce support for little endian PowerPC Kumar Gala
2010-10-01 11:30 ` Josh Boyer
2010-10-01 11:55 ` Gary Thomas
2010-10-01 12:15 ` Benjamin Herrenschmidt
2010-10-01 12:37 ` Gary Thomas
2010-10-01 12:14 ` Benjamin Herrenschmidt
2010-10-01 16:20 ` Michel Dänzer
2010-10-01 20:50 ` Benjamin Herrenschmidt
2010-10-04 10:30 ` Michel Dänzer
2010-10-04 22:50 ` Benjamin Herrenschmidt
2010-10-01 17:59 ` Kumar Gala [this message]
2010-10-01 20:51 ` Benjamin Herrenschmidt
2010-10-01 22:03 ` Olof Johansson
2010-10-01 22:28 ` Benjamin Herrenschmidt
2010-10-07 16:25 ` Hollis Blanchard
2010-10-01 11:36 ` Josh Boyer
2010-10-01 12:21 ` Benjamin Herrenschmidt
2010-10-06 1:04 ` Ian Munsie
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=BBD78246-343E-4A96-9E55-3E40AD628C0B@kernel.crashing.org \
--to=galak@kernel.crashing.org \
--cc=benh@kernel.crashing.org \
--cc=imunsie@au1.ibm.com \
--cc=jwboyer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®