PCI resources on 2.6 [Cobalt Qube]

Hi.

I'm working to get the 2.6 kernel booting on the Qube/RaQ, but the PCI resource stuff is giving me a hard time.

I/O accesses using inb() etc are adjusted by Galileo's PCI I/O base thus

	00000000 - 0000ffff --> b0000000 - b000ffff

The problem is that Galileo passes I/O addresses straight to PCI so that a read of the RTC translates to a PCI address of 1000007[01]. This works fine for the stuff on the VIA south bridge as it doesn't seem to decode all 32 bits of the address for I/O accesses. But this doesn't work for the Tulip's, they must have the correct addresses written into the I/O BAR.

If I change the PCI I/O resource range to 10000000 - 1000ffff, then inb() etc fail because they add Galileo's PCI I/O base again

	10000000 - 1000ffff --> c0000000 - c000ffff !!

causing a page fault.

If I set the I/O port base to 00000000 to overcome this then accesses to the peripherals on the VIA south bridge don't get Galileo's PCI I/O base added and they land up accessing RAM.

I effectively have two I/O ranges that need to map to the same addresses

	00000000 - 0000ffff --> b0000000 - b000ffff (for VIA)
	10000000 - 1000ffff --> b0000000 - b000ffff (for PCI)

I was hopefull that the 'io_offset' field in 'struct pci_controller' would do this for me, but I can't work out what it does :-|

This all worked in 2.4 as it's actually the boot loader that maps the Tulip's into the I/O address space and the kernel has hardcoded resource entries to match.

P.

you can do some messing with port addresses by implementing include/asm/mach-<your machine>/mangle-port.h

Ilya.

In general io_offset should be left 0 unless you already register ioport resources elsewhere in the kernel, which typically is needed for platforms with legacy peripherals - that is the Cobalt, too.

Two examples you could take a look at:

- Siemens-Nixdorf RM200

In arch/mips/sni/setup.c it statically initializes sni_controller. io_address range:

static struct pci_controller sni_controller = {
.pci_ops = &sni_pci_ops,
.mem_resource = &sni_mem_resource,
.mem_offset = 0x10000000UL,
.io_resource = &sni_io_resource,
.io_offset = 0x00000000UL
};

A few legacy PC style I/O port resources are registered first using repeated calls to request_resource:

request_resource(&ioport_resource, pcimt_io_resources + i);

Note we're allocating resources from ioport_resource, the kernel's "master" I/O port resource. It means later the kernel won't try to assign PCI cards to the same place even though all legacy resources actually exist on the PCI bus or more exactly on a SuperIO chip behind the PCI-EISA bridge.

- MIPS Malta

The Malta board takes an exchangable processor card which also contains one of several different possible system controllers, among those the GT-64120 which is rather similar to the GT-64111 used on Cobalts.

   static struct resource gt64120_mem_resource = {
           .name   = "GT64120 PCI MEM",
           .start  = 0x10000000UL,
           .end    = 0x1fffffffUL,
           .flags  = IORESOURCE_MEM,
   };
                                                                                
   static struct resource gt64120_io_resource = {
           .name   = "GT64120 IO MEM",
           .start  = 0x00002000UL,
           .end    = 0x007fffffUL,
           .flags  = IORESOURCE_IO,
   };

Aside of supporting several different system controllers this also fairly simple. The complexity here which (afair ...) you'll also have to handle on the GT64111 is that the system controller itself shows up on the PCI bus as a PCI device, so when the kernel configures the PCI bus it'll accendidentally move the system controller including all PCI devices around. I wonder if that's what you just ran into?

Ralf