trini at kernel.crashing.org
Sat Oct 20 01:13:53 EST 2001
On Fri, Oct 19, 2001 at 10:19:32PM +1000, Paul Mackerras wrote:
> I feel that arch/ppc/kernel in the linuxppc_2_4_devel tree is getting
> more than a bit cluttered. I propose that we make a new
> arch/ppc/platforms directory and move the platform-specific files into
> there - i.e. all of *_setup.c, *_pic.c, *_pci.c, and maybe some
> others. What would be left in arch/ppc/kernel is the more generic
> stuff, i.e. things relating to the different base processors, the
> different types of interrupt controllers or PCI host bridges, the
> generic stuff that interfaces to the rest of the kernel (e.g. setup.c)
> and so on.
I think we should go and look at what MIPS is doing. They've got
board_name/setup.c, other board specific stuffs.
I think doing something like this, but inside of arch/ppc/platforms
would make sense.
> My idea is that adding support for a new board would not normally
> require changes in arch/ppc/kernel unless the new board has a new type
> of interrupt controller, PCI host bridge, etc.
> Another thing I would like to do is to generalize the drivers for the
> various on-chip peripherals a bit more. The platform code would then
> specify in some way "this platform has an XYZZY on-chip ethernet
> controller with registers at 0xabcdef00, using interrupt 123, with
> quirks A, D and F". (This sort of thing is what the OF device tree
> was designed for and does very well, BTW.)
How about we put the totally platform specific stuff, like say 8xx
microcode updating into arch/ppc/platforms/cpm8xx/drivers/ or something
like that, and move the enet/serial drivers out. But yes, the 8xx/8260
enet/serial drivers need some work. The ppc405 enet driver is a bit
better about some of these things.
With the ppc405 enet driver we can detect things like the PHY, but other
infos are still a compile-time option. Some of these might be
detectible, but I think in the case where you don't have any control
over the firmware, and it's either buggy or it's lacking in features,
it's a toss up if you want to figure stuff out at compile time with a
config option or hardcode stuff either in the driver or wrapper based on
> The configuration scripts could force CONFIG_XYZZY on when this
> platform is selected and that would compile in the xyzzy driver.
> The xyzzy driver initialization would get called during boot and would
> look up whether the platform has any XYZZY's, and if so, what
> addresses and interrupts to use. So the XYZZY code doesn't need to
> know anything about which platforms have an XYZZY at all.
Erm, I don't think you can get rid of asking things about CONFIG_XYZZY
tho. I _think_ depending on how you build the drivers it's sometimes
possible to have the same HW either have 2 XYZZYs or an XYZZY and a
ZYXXY. But the drivers can certainly be cleaned up a bit to probe
around in some cases instead of big ugly #ifdef tables.
> This could extend to things like interrupt controllers and PCI host
> bridges as well as regular I/O devices, too.
Eh? I'm pretty sure all of the bridge stuff is pretty well extracted.
Pass it your board values (which are unchanging constants) and it just
works. There are a couple of funny issues which could be handled a bit
better (Sandpoint X2 vs Sandpoint X3) but by and large the I/O device
drivers are the ones with some glaring uglies in it (which I have been
Tom Rini (TR1265)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev