Re: Organisation of 4xx initialization code

On Sat, Nov 17, 2001 at 11:40:52AM +1100, David Gibson wrote:

On Fri, Nov 16, 2001 at 07:59:17AM -0700, Tom Rini wrote:

quoted

On Fri, Nov 16, 2001 at 04:46:26PM +1100, David Gibson wrote:

quoted

At the moment the initialization for each of the 4xx boards goes
through the platform_init() in arch/ppc/kernel/ppc4xx_setup.c, which
in turns calls a board_init() function for the specific board.

It seems to me that it would make more sense to put platform_init() in
the board specific files, and these functions could then call back,
where appropriate, to generic 4xx setup functions.  This would mean:

But 95% of the current 4xx platform_init is generic.  With the exception
of the redwood kbd init stuff, which right now we could probably move
into the redwood board_init (providing redwood_irkb_init sets things to
NULL which the previous bits set).

And the common stuff can still be shared - it's just that the board
code, which clearly knows more about the configuration than the 4xx
generic stuff, chooses what order to do things in.

And provided things are done in the 'right' order to start with, it
should just work.  We deal with having a rather useless firmware on 7xx
by doing things under ppc_md I believe.  So why not here?  Keep in mind
that 'board_init' is calling in platform_setup and can override ppc_md
stuff set in platform_setup.

quoted

quoted

	- We should be able to remove some inconvenient header
dependencies - at present lots of things are recompiled when board
local defines are changed because walnut.h/ep405.h/etc are included
indirectly in serial.h and some other unexpected places.

Keep in mind <asm/ibm4xx.h> has the same exact thing.  As does
<asm/mpc8xx.h>.  There's lots of wierd header dependancies, and it's not
fixable in 2.4 anyhow.  kbuild-2.5 doesn't have this issue, and this
isn't even much of a problem anyhow.

Um, no, this has nothing to do with the build system.  Board specific
header files, which contain largely information which is irrelevant to
everything except the board and 4xx setup code is being indirectly
included in parts of the generic kernel.  That creates a dependency
regardless of the build system.

So what were you complainging about <asm/serial.h> deps for?  It isn't
excactly nice, but it's not exactly related to this.  And supposedly
kbuild-2.5 is smarter about how it does deps, so unless you're say
CONFIG_SPRUCE, changing <asm/spruce_serial.h> won't effect
<asm/serial.h> on !CONFIG_SPRUCE.  If I understand things right.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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