[Top] [All Lists]

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

Subject: Re: Legacy PCI IO for PCI graphics on SGI O2...Anybody?
Date: Fri, 22 Jun 2007 09:34:58 -0400 (EDT)
Importance: Normal
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: SquirrelMail/1.4.9a
> On Tue, 19 Jun 2007 13:03:24 +0100 (BST), "Maciej W. Rozycki"
> <> 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).

The only reason I even attempted to implement this is that I was told uses the sysfs legacy_ IO inorder to do its Int10 x86 emulation.
This is very useful as it is what allows to POST most video cards on
non-x86 architectures. The fact that my errors went down with my
preliminary patch gives more evidence that if this was correctly
implemented a much larger set of PCI graphics cards would work on MIPS.

> 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 ;)

This seems like a mistake, shouldn't the hardware specific chunks be in
the kernel?

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