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