From: Pantelis Antoniou <panto@intracom.gr>
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
linuxppc-embedded@ozlabs.org
Subject: Re: RFC: Deprecating io_block_mapping
Date: Wed, 25 May 2005 09:07:37 +0300 [thread overview]
Message-ID: <42941629.8020101@intracom.gr> (raw)
In-Reply-To: <8818d51720e46592f49178f803ed2f0b@embeddededge.com>
Dan Malek wrote:
>
> On May 24, 2005, at 10:30 PM, Kumar Gala wrote:
>
>> I know what I've done in the past is either steal a BAT (83xx) or CAM
>> (85xx) entry and then free it up when a proper ioremap can be done later.
>
>
> This is even more of a hack than io_block_mapping() because it is often
> obscure and not documented. Several boards have done this in the past
> as well. It's "magic" that occurs, what seems to be minor code changes
> often cause this to break and makes debugging more complex :-)
>
>> No, as far as a can tell doing a quick glance if we drop
>> io_block_mapping than we can drop setup_io_mappings().
>
>
> We've got to have something to address the board unique requirements
> that are currently satisfied by this.
>
> There is a real problem that we have to solve. Some boards just need
> access to mapped hardware before the VM is set up. You can't just
> remove a feature or tell them their design is wrong. I don't think obscure
> mapping tricks are the solution, either.
>
> The only solution is to make ioremap() smart enough to properly use
> BATs and CAMs that are available to a processor. I suspect this is going
> to lead to a bunch of also undesirable configuration options to address
> the customizations necessary.
/me nods
>
> Thanks.
>
>
> -- Dan
>
Regards
Pantelis
next prev parent reply other threads:[~2005-05-25 6:07 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 [this message]
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
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=42941629.8020101@intracom.gr \
--to=panto@intracom.gr \
--cc=dan@embeddededge.com \
--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.