From: "Mark A. Greer" <mgreer@mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
linuxppc-embedded@ozlabs.org
Subject: Re: RFC: Deprecating io_block_mapping
Date: Thu, 26 May 2005 13:30:04 -0700 [thread overview]
Message-ID: <429631CC.6000606@mvista.com> (raw)
In-Reply-To: <1117089669.9076.105.camel@gaston>
Benjamin Herrenschmidt wrote:
> - There is _one_ important point to keep in mind, but that has always
>been true: None of this work before MMU_init(),
>
>
This is very true and raises a couple issues that we should fix while
we're at it:
1) There are progress calls in MMU_init which will try to access the
uart before its possible to create a mapping to the uart's regs
(assuming you don't make a hack to map them and that you set up
ppc_md.progress in your platform_init routine). We should either get
rid of those calls in MMU_init, provide an acceptable way to make
temporary pre-MMU_init mappings, or make sure nobody sets up
ppc_md.progress until ioremap is working (and also get rid of the calls
in MMU_init b/c they're never used).
2) Some firmwares don't provide any info on how much memory is in the
system but MMU_init needs to know that. So the platform code has to
read the SPD from the mem sticks via i2c, read the mem ctlr, or read a
board reg that has the info. All of those require access to hw regs
before or during MMU_init. I should be able to get rid of this one by
figuring out the amount of memory in the bootwrapper and passing it in
to the kernel. I am assuming that all the boards with this problem use
the bootwrapper. I think that's a safe assumption but I'll have to verify.
BTW, these are the reasons that I made that set_bat hack that Dan is so
fond of. :) I'll get rid of that hack but I need an answer to 1) first.
Mark
next prev parent reply other threads:[~2005-05-26 20:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-25 1:30 RFC: Deprecating io_block_mapping Benjamin Herrenschmidt
2005-05-25 2:17 ` Kumar Gala
2005-05-25 2:21 ` Benjamin Herrenschmidt
2005-05-25 2:30 ` Kumar Gala
2005-05-25 5:00 ` Dan Malek
2005-05-25 6:07 ` Pantelis Antoniou
2005-05-25 5:14 ` Dan Malek
2005-05-25 5:20 ` Benjamin Herrenschmidt
2005-05-25 5:49 ` Dan Malek
2005-05-25 6:00 ` Benjamin Herrenschmidt
2005-05-25 6:08 ` Kumar Gala
2005-05-25 7:04 ` Benjamin Herrenschmidt
2005-05-25 16:36 ` Dan Malek
2005-05-25 21:44 ` Benjamin Herrenschmidt
2005-05-26 6:00 ` Dan Malek
2005-05-26 6:20 ` Eugene Surovegin
2005-05-26 19:00 ` Dan Malek
2005-05-26 21:54 ` Benjamin Herrenschmidt
2005-05-26 6:41 ` Benjamin Herrenschmidt
2005-05-26 19:32 ` Dan Malek
2005-05-26 22:10 ` Benjamin Herrenschmidt
2005-05-26 20:30 ` Mark A. Greer [this message]
2005-05-26 22:13 ` Benjamin Herrenschmidt
2005-05-26 22:16 ` Mark A. Greer
2005-05-26 16:31 ` Matt Porter
2005-05-26 16:54 ` Eugene Surovegin
2005-05-25 4:48 ` Dan Malek
2005-05-25 4:45 ` Dan Malek
2005-05-25 5:15 ` Benjamin Herrenschmidt
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=429631CC.6000606@mvista.com \
--to=mgreer@mvista.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@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.