linux-mips
[Top] [All Lists]

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

To: linux-mips@linux-mips.org
Subject: Re: Legacy PCI IO for PCI graphics on SGI O2...Anybody?
From: sknauert@wesleyan.edu
Date: Tue, 19 Jun 2007 01:58:35 -0400 (EDT)
Importance: Normal
In-reply-to: <20070619.121030.130240189.nemoto@toshiba-tops.co.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <cda58cb80706120255w5ef28123tc27a8152d18e3039@mail.gmail.com> <39830.129.133.92.31.1181651585.squirrel@webmail.wesleyan.edu> <54672.129.133.92.31.1182184357.squirrel@webmail.wesleyan.edu> <20070619.121030.130240189.nemoto@toshiba-tops.co.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: SquirrelMail/1.4.9a
First, thanks for the interest.

> On Mon, 18 Jun 2007 12:32:37 -0400 (EDT), sknauert@wesleyan.edu wrote:
>> Justing bumping this topic, I'm really stuck and could use some (any)
>> help
>> here. I understand that people are busy and most effort is focused on
>> 2.6.23, but I haven't received any response regarding my prelimenary
>> patch
>> and its been over a week.
>
> I suppose HAVE_PCI_LEGACY provides us a standard way to access 8/16/32
> bit registers in PCI I/O space, right?

Yes, according to Jesse Barnes' description of the ia64 version:

"The legacy_io file is a read/write file that can be used by applications to
do legacy port I/O.  The application should open the file, seek to the
desired +port (e.g. 0x3e8) and do a read or a write of 1, 2 or 4 bytes.
The legacy_mem +file should be mmapped with an offset corresponding to the
memory offset +desired, e.g. 0xa0000 for the VGA frame buffer. The
application can then +simply dereference the returned pointer (after
checking for errors of course) to access legacy memory space."

More info. here:
http://www.kernel.org/pub/linux/kernel/people/jbarnes/patches/sysfs-legacy-resource-7.patch

>
> 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.
>
> Also I'd suggest to support multiple PCI busses (please refer
> iomap-pci.c):
>
> Something like this:
>
> int pci_legacy_read(struct pci_bus *bus, u16 port, u32 *val, u8 size)
> {
>       struct pci_controller *ctrl = bus->sysdata;
>       unsigned long base = ctrl->io_map_base;
>       void __iomem *addr = (void __iomem *)(ctrl->io_map_base + port);
>       int ret = size;
>
>       switch (size) {
>       case 1:
>               *val = ioread8(addr);
>               break;
>       case 2:
>               *val = ioread16(addr);
>               break;
>       case 4:
>               *val = ioread32(addr);
>               break;
>       default:
>               ret = -EINVAL;
>               break;
>       }
>
>       return ret;
> }
>

I could be wrong, but I believe it already supports multiple buses some
other way. I get legacy_io, legacy_mem in /sys/class/pci_bus/0000:xx/ for
the three on my O2. If not (I couldn't get any useful io with the
interface files though), I agree something like the above is a great idea.

> Also I think no need to add "mips_" prefix and make aliases. (unless
> we really need to override them for each platform)
>
>> +#define pci_get_legacy_mem mips_pci_get_legacy_mem
>> +#define pci_legacy_read mips_pci_legacy_read
>> +#define pci_legacy_write mips_pci_legacy_write
>

I did define the functions directly as you suggested first, but there were
a bunch of compile errors. Plus, my only example code, the ia64 version of
this did it with an ia64_ prefix. If there is consensus for direct
declaration, I'll glady spend the time to change this (shouldn't be too
hard).

The main part of this code which will probably be platform specific
shouldn't be the legacy functions, but the address offsets as different
hardware may different memory structures so either method should in theory
be okay.

> ---
> Atsushi Nemoto
>
>

Thanks again,
Scott


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