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

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