LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Lanners <mlan@cpu.lu>
To: linuxppc-dev@lists.linuxppc.org
Cc: Martin Mares <mj@suse.cz>
Subject: Accessing IO space via resources
Date: Fri, 23 Jun 2000 14:24:07 +0200 (CEST)	[thread overview]
Message-ID: <200006231224.OAA00765@piglet.grunz.lu> (raw)


Hi all,

Lots of discussion lately about IO issues on non-ia32 ;-)

Anyway, here is another problem related to IO space:

Until a few kernel versions ago, ioremap() of the IO region on PCI buses
happened to return the same virtual address as the physical address
requested to be mapped.

This was good, as it kept a potential problem hidden: the fact that
drivers want to access IO regions directly, without going through an
ioremap(). On ia32, with its separate IO address space, it's never a
problem since inb() and friends access the IO space directly, and
there's no remapping involved.

However, on non-ia32 platforms, IO space is regular memory space and
needs to be ioremp()'ed into kernel virtual address space. Now, the way
drivers find out about IO ports is most of the time via pci_dev resource
regions. These regions therefore need to contain kernel virtual
addresses. Strictly speaking, this was not the case. In standard
kernels, they contain the bus physical address, and inb() and friends
apply the needed offset to access the ports relative to kernel virtual
of port 0. In essence, it's this:

inb(port) == in_8(port + ioremap(bridge_offset(port_0)))

bridge_offset being the offset added by the PCI bridge.

Since bridge_offset is static, this works for a single bus only. I had
therefore modified the PCI fixup code to replace (port) in the resources
with (port + bridge_offset). This worked since the IO space was
ioremp()'ed 1:1.

Now, in the latest 2.4.0-ac kernels, ioremap() returns different
addresses, not 1:1 the original address anymore. And of course this
breaks the above scheme. (I've not looked into why this is so... I
suppose it's not a bug?)

Of course, I could fix the resources to show the remapped addresses, but
that would break the resource tree, since the entire tree shows phys
addresses. It would be harder as well to re-assign resources, since
before writing the new addresses out into PCI base regs, the correction
stuff needs to be undone. That would be workable, however.

So, what is the way to go? Let IO resources show kernel virtual, where
MEM resources show phys? Do some (inefficient, if at all possible) magic
in inb()? Something else?

Thanks for all comments, ideas and suggestions.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

             reply	other threads:[~2000-06-23 12:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-23 12:24 Michel Lanners [this message]
2000-06-24  6:32 ` Accessing IO space via resources Michel Lanners
2000-06-24 21:27   ` Martin Costabel
2000-06-25  7:39     ` Michel Lanners

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=200006231224.OAA00765@piglet.grunz.lu \
    --to=mlan@cpu.lu \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=mj@suse.cz \
    /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