Re: PCI resources on 2.6 [Cobalt Qube]

[Ralf Baechle <ralf@linux-mips.org>]

On Sun, Feb 08, 2004 at 01:16:29PM +0000, Peter Horton wrote:

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

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