linux-mips
[Top] [All Lists]

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

To: macro@linux-mips.org
Subject: Re: Legacy PCI IO for PCI graphics on SGI O2...Anybody?
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Wed, 20 Jun 2007 01:22:06 +0900 (JST)
Cc: sknauert@wesleyan.edu, linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.64N.0706191246060.15474@blysk.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <54672.129.133.92.31.1182184357.squirrel@webmail.wesleyan.edu> <20070619.121030.130240189.nemoto@toshiba-tops.co.jp> <Pine.LNX.4.64N.0706191246060.15474@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
On Tue, 19 Jun 2007 13:03:24 +0100 (BST), "Maciej W. Rozycki" 
<macro@linux-mips.org> wrote:
>  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).  

Oh I thought ioperm() or iopl() on archs other then x86 are all dummy
routines, but apparently that was wrong.  Now I have looked some
ioperm.c in glibc and am very suprised by so many hard-coded
boardname/addresses ;)

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

I agree.
---
Atsushi Nemoto

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