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 15:16:39 -0700 [thread overview]
Message-ID: <42964AC7.8080605@mvista.com> (raw)
In-Reply-To: <1117145621.9076.147.camel@gaston>
Benjamin Herrenschmidt wrote:
>On Thu, 2005-05-26 at 13:30 -0700, Mark A. Greer wrote:
>
>
>>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).
>>
>>
>
>Or have the implementation of progress() check if the mapping was done
>or not ...
>
Doesn't seem worth it to me.
> In any ways, I always disliked ppc_md.progress deeply. It's
>ugly and clutters the code. It has never proven very useful to me vs.
>having an early console.
>
Okay, let's rip it out of MMU_init then. Anyone have a problem with that?
Mark
next prev parent reply other threads:[~2005-05-26 22:16 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
2005-05-26 22:13 ` Benjamin Herrenschmidt
2005-05-26 22:16 ` Mark A. Greer [this message]
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=42964AC7.8080605@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.