linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: Eugene Surovegin <ebs@ebshome.net>
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:00:48 -0400	[thread overview]
Message-ID: <fb2cb3a9f4b80b8fc6392698036b9f6a@embeddededge.com> (raw)
In-Reply-To: <20050526062057.GA25579@gate.ebshome.net>


On May 26, 2005, at 2:20 AM, Eugene Surovegin wrote:

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

Anyone that uses assumptions of mapping from io_block_mapping()
should be fixed, unless it is absolutely necessary, like to get an
early serial port for debugging.  I've been guilty of this as well,
but everyone should be calling ioremap().

> What is so special about PCI IO space that it must be "wired" ?

My point was someone needs to set up BATs or CAMs for that
space and further configure it so the in/out macros work.  Drivers
don't call ioremap for such space (although I think they should).
Assuming mappings exist, whether by calling ioremap() or
otherwise, is Linux legacy and shouldn't be done.

> Wow, this is something new for me. So you are saying that
> io_block_mapping() was supposed to be used with ioremap()?

Except in rare circumstances, it's the way I've always used
it to set up IO mapping on embedded boards.

> Could you point me to the port which actually does this?

I don't see any of them in the 2.6 right now, but the EP and STx ports
I did should do this.  I certainly plan to use it on all of the 85xx 
ports
so we get the advantage of CAM mapping for various IO spaces.

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

That's just wrong.  The only "acceptable" io_block_mapping without
an ioremap has usually been the PCI IO space.  It gets abused for
early serial ports, but that's a hack no matter how you look at it :-)

> 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?

Depends.  If you need early ioremap() prior to VM initialized so
a vmalloc will work, you have to do this even if you do call ioremap().
The 8xx ports usually do this, and ioremap() for these boards should
know to not try to allocate VM space if this was done.  Most of the 8xx
ports still skip the ioremap() because the associated code changes
to ioremap() never stuck in the code.

The problem with ioremap() if you don't wire some spaces is it will try 
to
allocate VM space prior to the Linux VM being initialized.  We all want
to write drivers so they use the proper ioremap() interfaces, but many
drivers call this too early if you haven't made the provisions for 
ioremap()
to find the "efficient" map and just return the associated address.

Thanks.


	-- Dan

  reply	other threads:[~2005-05-26 19:00 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 [this message]
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=fb2cb3a9f4b80b8fc6392698036b9f6a@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=ebs@ebshome.net \
    --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).