[Top] [All Lists]

Re: Legacy PCI IO for PCI graphics on SGI O2...Anybody?

To: Atsushi Nemoto <>
Subject: Re: Legacy PCI IO for PCI graphics on SGI O2...Anybody?
From: "Maciej W. Rozycki" <>
Date: Tue, 19 Jun 2007 13:03:24 +0100 (BST)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
On Tue, 19 Jun 2007, Atsushi Nemoto wrote:

> I suppose HAVE_PCI_LEGACY provides us a standard way to access 8/16/32
> bit registers in PCI I/O space, right?
> If so, it would be great; When I tried to read a 16-bit register in
> PCI I/O space from userland, I had to find a physical address of the
> PCI I/O region and mmap it via /dev/mem, since /dev/port only supports
> 8bit access.

 That should be taken care of in glibc (or your libc of choice) -- with 
ioperm() or iopl() and then in{b,w,l}() and out{b,w,l}() as appropriate.  
Either of the two formers are used to mmap() the right area of /dev/mem 
and then the latters are used access the area with the desired width (and 
stride, if applicable -- portable code should not assume subsequent I/O 
port addresses are adjacent in the MMIO space).  It has worked like this 
for other platforms for at least ten years now.

 Of course the function doing mmap() still has to know the CPU physical 
address of the I/O space from somewhere.  For quite some time my feeling 
has been it should come from /proc/iomem, where we actually fail to 
register the I/O space, but these days sysfs is probably better (though I 
plan to have a look at /proc/iomem for the use of human beings anyway).  

 That still does not solve the problem of multiple independent I/O spaces, 
but I gather such configurations are very rare indeed.


<Prev in Thread] Current Thread [Next in Thread>