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