From: "Mark A. Greer" <mgreer@mvista.com>
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: Mon, 16 May 2005 13:43:36 -0700 [thread overview]
Message-ID: <428905F8.4030204@mvista.com> (raw)
In-Reply-To: <2dd506f0a6d4b03e771c0bc9d80735e6@embeddededge.com>
Dan Malek wrote:
>
> On May 16, 2005, at 2:06 PM, Mark A. Greer wrote:
>
>> Oops...
>> /me unintentionally stepped into the middle of a flame war :)
>
>
> Just pee on it :-)
Heh!
>
>
>> To be clear, "offender" == board that has an io_block_mapping below
>> the 3 GB line.
>
>
> That is one of the obvious changes. You are likely to find some other
> assumptions
> that may need attention. The problem with io_block_mapping is you
> just can't
> remove it, you have to fix up all of the code that is based on the
> assumption these
> spaces are mapped. You are likely to find yourself in a situation
> where you need
> access to some board control registers before VM is set up and you can
> call
> ioremap(). So, you will find yourself doing some hack in head.S to
> map BAT
> registers to get access to this, which is exactly what
> io_block_mapping() does,
> only in a way that is obvious :-)
I think I understand all of that. I wasn't clear in my email. I was
talking about "fixing" such that 3GB works (i.e., io_block_mapping are
above 3GB virt, if possible) not "fixing" such that we can get rid of
io_block_mapping altogether. We still need io_block_mapping for exactly
the reasons you state.
I need to learn how to write better emails... :(
Mark
next prev parent reply other threads:[~2005-05-16 20:43 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
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 [this message]
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=428905F8.4030204@mvista.com \
--to=mgreer@mvista.com \
--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.