linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

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