lkml.org 
[lkml]   [2000]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A simple question about readw, readw and the like
   Date: Thu, 27 Jul 2000 13:47:37 +0200
From: Abramo Bagnara <abramo@alsa-project.org>

Does this means that there is no way to mmap the PCI IO space on
any platform other than ia32?

One needs to be a bit more specific for me to give you an
answer :-)

Inside the kernel:

1) PCI I/O space is accessed by obtaining the base address via the
appropriate pci_dev->resource[xxx] value, and feeding that directly
into inb/inw/inl and friends.

2) PCI MEM space is accessed by obtaining the opaque MEM base cookie
in pci_dev->resource[xxx], mapping it with ioremap(cookie), and
feeding what you obtain from that to readw and friends. When
done with the MEM space area, you iounmap it.

For userspace things are much different. It is nearly impossible to
be %100 portable for PCI I/O space. On x86 you can just do inb
etc. instructions on the base address register value. This fails to
work on just about every other system, you must actually mmap() the
PCI I/O space area needed on PPC, MIPS, Alpha, Sparc64, etc.

Honestly we lack a truly portable way to do this, and I am working on
a solution which will allow you to portably mmap I/O and MEM space PCI
areas via mmap() on /proc/bus/pci/xxx device nodes. Just plain mmap
on /dev/mem is not a solution because that fails to work for 32-bit
userspace running on a 64-bit kernel, and besides this would require
that we give the user some way to find the base of I/O and MEM space
for a particular PCI controller in the machine. The /proc/bus/pci
mmap solution hides all of this mess from userspace.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.084 / U:1.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site