PCI rework & CHRP question

PCI rework & CHRP question

[Benjamin Herrenschmidt]

I'm working on a rework of our arch/pci.c (to properly handle multiple
host bridges, and various other cleanups).

In the chrp_pci.c code, I found this code:

        if ( !strncmp("MOT",
                      get_property(find_path_device("/"), "model", NULL),3) )
        {
                pci_dram_offset = 0;
                isa_mem_base = 0xf7000000;
                isa_io_base = 0xfe000000;
                set_config_access_method(grackle);
        }

However, I found no way in the Grackle documentation to have isa_mem_base
at 0xf7000000. AFAIK, it's at 0xfd000000

Also, the grackle access method expect a PCI bridge structure configured
with the ioremap'ed config space registers, which is not the case on
chrp. (They are defined only in pmac_pci.c).

I'm fixing those along with my changes. I suppose Grackle on CHRP uses
memory map B ?

Note (tell me if it's a problem), that I'm removing the various
xxx_setup_pci_ptrs(). Each host bridge has a pci_controler structure (the
old bridge_data) that contains also the function pointers to the access
methods. Archs now call whatever xxx_find_bridges from their
xxx_setup_arch() function and all host-bridge dependent setup is done there.

I will push those changes in the new linuxppc_2_5 bk tree as soon as I'm
happy with them.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PCI rework & CHRP question

[Cort Dougan]

} I'm working on a rework of our arch/pci.c (to properly handle multiple
} host bridges, and various other cleanups).
}
} In the chrp_pci.c code, I found this code:
}
}         if ( !strncmp("MOT",
}                       get_property(find_path_device("/"), "model", NULL),3) )
}         {
}                 pci_dram_offset = 0;
}                 isa_mem_base = 0xf7000000;
}                 isa_io_base = 0xfe000000;
}                 set_config_access_method(grackle);
}         }
}
} However, I found no way in the Grackle documentation to have isa_mem_base
} at 0xf7000000. AFAIK, it's at 0xfd000000

I think I did this for the Cobra.  You can kill off the cobra.  I have two
here that I don't boot anymore for testing and I don't think many people in
the world have them.  Those that do have them aren't likely to care much
about Linux.

} Also, the grackle access method expect a PCI bridge structure configured
} with the ioremap'ed config space registers, which is not the case on
} chrp. (They are defined only in pmac_pci.c).
}
} I'm fixing those along with my changes. I suppose Grackle on CHRP uses
} memory map B ?

Actually, it seemed to use a memory map something entirely unlike A or B.

} Note (tell me if it's a problem), that I'm removing the various
} xxx_setup_pci_ptrs(). Each host bridge has a pci_controler structure (the

Good!  Thanks, those bastards have needed to die for a while.

I still do want to be able to mix-and-match PCI controllers and not have
any board<->chipset association except in the direction board->chipset but
not chipset implies board.   This helps people with custom hardware get
their boards going and helps us with new ports.

} old bridge_data) that contains also the function pointers to the access
} methods. Archs now call whatever xxx_find_bridges from their
} xxx_setup_arch() function and all host-bridge dependent setup is done there.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PCI rework & CHRP question

[Benjamin Herrenschmidt]

>Good!  Thanks, those bastards have needed to die for a while.
>
>I still do want to be able to mix-and-match PCI controllers and not have
>any board<->chipset association except in the direction board->chipset but
>not chipset implies board.   This helps people with custom hardware get
>their boards going and helps us with new ports.

There should be no problem. You can have your board code create a
controller for any chipset, the chipset code is not dependant on the
board. We already have both PReP and CHRP boards use indirect PCI, we
have some CHRP and pmac use Grackle, etc...

The PCI config access methods are stuffed in the PCI controller structure
(removes a bit from ppc_md. which can't be a bad thing, and makes the
overall thing more readable). But the board specific stuffs are still
there and it's the board support code who decide which chipset to
"instanciate".

On Pmac, I even have a cases where you have 3 hosts bridges with
different access methods (2xbandits and 1xchaos, chaos beeing buggy, it
has special access methods, currently empty, but soon to be filled with
code that returns a fake config space built from OF tree).

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/