From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-dev@ozlabs.org, John Reiser <jreiser@BitWagon.com>
Subject: Re: 2GB address space limit on 32-bit PowerPC Macintosh
Date: Tue, 17 May 2005 10:54:47 +1000 [thread overview]
Message-ID: <1116291287.5095.147.camel@gaston> (raw)
In-Reply-To: <22b73f109d1c4a95b565f1007d76b8bf@embeddededge.com>
> Who cares? We have the ability to support the memory map flexibility
> for everyone. If you need it, use it, and fix it if necessary. There
> are
> too many other things that need attention. Again, you are taking one
> of the features we added for embedded boards a long time ago, and
> demanding everyone support it.
Gack ? None of this was 'added for embedded boards'. The initial 2G/2G
split was Cort's decision afaik for the PReP port, and it was PReP and
pmac that introduced the use of BATs for IO mappings, which then got
turned into io_block_mapping() for clarity. Those platorms predate by
far any embedded involvement in the ppc kernel.
> That's not necessary. If you want
> to use this feature on a PMac, then use it, but please don't demand
> everyone else do so. We didn't do that when the feature was added.
It's more than a "feature", it's the way it should have been done in the
first place on 6xx/7xx/7xxx CPUs and wasn't done because of a cheap hack
for IO mapping. I have no problem with other CPU family maintainers
deciding to restrict TASK_SIZE for the sake of saving a couple of
instructions (on 4xx, it's really replacing andis.;beq with
rlwinm;cmpl;bne or something like that, so one instruction, to support
any TASK_SIZE).
> > The whole io_block_mapping() was a bad idea in the first place.
>
> All of the ideas in 2.6 are going to look like bad ideas in the future
> :-)
Hrm... If you say so ...
> It's what worked and was necessary given the lack of any other
> APIs at the time.
ioremap and variants was available at this time and has always been.
> We are working on removing these in the embedded
> boards, and it has to be done on the PMac as well if you want to
> take advantage of something other than a 2G task space.
Well, you know what ? I've removed them from pmac a long time ago :) And
you know what also ? what you just stated above is _exactly_ what this
thread is all about ... so what are you complaining about ? :)
> As time permits, I will make whatever changes to the board ports
> I'm aware of so they will accommodate a 3G task space, or fix up
> the configuration files so the default is 2G. At some point, we can
> make it the configuration default.
Good, I'm not asking for anything else here.
Ben.
next prev parent reply other threads:[~2005-05-17 0:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-15 22:36 2GB address space limit on 32-bit PowerPC Macintosh John Reiser
2005-05-15 23:01 ` Benjamin Herrenschmidt
2005-05-15 23:29 ` Paul Mackerras
2005-05-15 23:34 ` Benjamin Herrenschmidt
2005-05-16 5:51 ` Kumar Gala
2005-05-16 5:52 ` Benjamin Herrenschmidt
2005-05-16 6:21 ` Kumar Gala
2005-05-16 6:22 ` Benjamin Herrenschmidt
2005-05-16 15:04 ` Dan Malek
2005-05-16 15:05 ` Benjamin Herrenschmidt
2005-05-16 15:52 ` Dan Malek
2005-05-16 16:42 ` Benjamin Herrenschmidt
2005-05-16 17:11 ` Dan Malek
2005-05-17 0:54 ` Benjamin Herrenschmidt [this message]
2005-05-16 18:00 ` Mark A. Greer
2005-05-16 18:06 ` Mark A. Greer
2005-05-16 20:31 ` Dan Malek
2005-05-16 20:43 ` Mark A. Greer
2005-05-16 21:02 ` Dan Malek
2005-05-17 3:14 ` Benjamin Herrenschmidt
2005-05-17 0:56 ` Benjamin Herrenschmidt
2005-05-16 16:11 ` Wolfgang Denk
2005-05-16 16:22 ` Eugene Surovegin
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=1116291287.5095.147.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=dan@embeddededge.com \
--cc=jreiser@BitWagon.com \
--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 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.