From: Eugene Surovegin <ebs@ebshome.net>
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-embedded@ozlabs.org,
linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: RFC: Deprecating io_block_mapping
Date: Wed, 25 May 2005 23:20:57 -0700 [thread overview]
Message-ID: <20050526062057.GA25579@gate.ebshome.net> (raw)
In-Reply-To: <80f48eb53b0f876138cde07a997791b6@embeddededge.com>
On Thu, May 26, 2005 at 02:00:11AM -0400, Dan Malek wrote:
>
> >Well, The PCI IO space base just need to be in a global that is
> >referenced by _IO_BASE, it works fine, no need to hard code a mapping.
>
> Sure you do. No one ioremap()s PCI IO space. It has to be hard wired
> somewhere.
Dan, you must be kidding. 44x ioremaps PCI IO space, 40x uses
io_block_mapping for that, but this is just brain-damaged and should
be fixed.
What is so special about PCI IO space that it must be "wired" ?
[snip]
> You are missing the point. The reason for io_block_mapping() isn't
> to allocate virtual space for someone, it's to _wire_ a space using an
> efficient mapping method so someone else can call ioremap() and
> get that wired access.
Wow, this is something new for me. So you are saying that
io_block_mapping() was supposed to be used with ioremap()?
Could you point me to the port which actually does this?
So far I only saw io_block_mapping() used as a short-cut way _NOT_ to
ioremap and get hard-coded v:p mapping and then use this knowledge to
access physical address directly without ever calling ioremap(). And
this is major source of problems.
Also, by this logic, if platform doesn't have BAT or CAMs or whatever,
which effectively prevents creating this "efficient mapping" and
hence stated purpose of io_block_mapping cannot be achieved,
io_block_mapping() should be eliminated on this platform, right?
--
Eugene
next prev parent reply other threads:[~2005-05-26 6:21 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 [this message]
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=20050526062057.GA25579@gate.ebshome.net \
--to=ebs@ebshome.net \
--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).