PCI resources on 2.6 [Cobalt Qube]

PCI resources on 2.6 [Cobalt Qube]

[Peter Horton]

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.

Re: PCI resources on 2.6 [Cobalt Qube]

[ilya]

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

		Ilya.

On Sun, Feb 08, 2004 at 01:16:29PM +0000, Peter Horton wrote:
> 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.
> 

Re: PCI resources on 2.6 [Cobalt Qube]

[Ralf Baechle]

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