From: Ralph Blach <rblach@intrex.net>
To: paulus@samba.org
Cc: Tom Rini <trini@kernel.crashing.org>,
Dan Malek <dan@embeddededge.com>,
Matt Porter <mporter@mvista.com>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: Organisation of 4xx initialization code
Date: Sat, 17 Nov 2001 07:43:55 -0500 [thread overview]
Message-ID: <3BF65B8B.EB015B30@intrex.net> (raw)
In-Reply-To: 15350.18199.593968.834376@cargo.ozlabs.ibm.com
Just a note that might influence you. The sprs of each 405 will be the same,
but there is NO gurantee that the DCR, any of them look anything like any
other DCR in any other DCR.
I suggest core, chip, and then platform specfic.
Chip
Paul Mackerras wrote:
> Tom Rini writes:
>
> > > No need - the board's platform_init() can call the processor general
> > > functions if necessary.
> >
> > But why not do this once instead of many times? Right now, each of the
> > 405GP 'board' file would look awful similar. I think what Dan said
>
> As a philosophical thing, I think it is better to give control to the
> platform-specific code early and let it call back to generic stuff.
> This is very much the Linux philosophy - it's basically what Linus did
> with the USB code for instance (the old code worked its way down
> through several layers to the HCI driver, Linus' new code called
> straight into the HCI driver which then called a library of support
> routines).
>
> I think that each platform (ep405, walnut, etc.) should have its own
> platform_init(), and if all that does is ppc405_init(), that's fine.
> The fact that we have board_init() at present suggests that some
> platforms will do more than just ppc405_init. And having a
> platform_init() for each platform is consistent with our approach on
> other platforms as well. Then ppc4xx_setup.c becomes a library of
> pieces of code that can be called or not as appropriate.
>
> Paul.
>
--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-11-17 12:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-16 5:46 Organisation of 4xx initialization code David Gibson
2001-11-16 11:57 ` Matt Porter
2001-11-16 15:51 ` Tom Rini
2001-11-16 16:42 ` Matt Porter
2001-11-16 17:13 ` Tom Rini
2001-11-16 23:24 ` Dan Malek
2001-11-17 0:43 ` David Gibson
2001-11-17 1:01 ` Dan Malek
2001-11-17 2:18 ` Tom Rini
2001-11-17 11:16 ` Paul Mackerras
2001-11-17 12:43 ` Ralph Blach [this message]
2001-11-17 14:46 ` Mark Pilon
2001-11-17 0:50 ` David Gibson
2001-11-17 2:16 ` Tom Rini
2001-11-17 0:35 ` David Gibson
2001-11-17 2:18 ` Tom Rini
2001-11-16 16:07 ` Mark Pilon
2001-11-16 17:29 ` Tom Rini
2001-11-16 14:59 ` Tom Rini
2001-11-17 0:40 ` David Gibson
2001-11-17 2:15 ` Tom Rini
2001-11-16 16:46 ` Dan Malek
2001-11-17 0:47 ` David Gibson
2001-11-17 1:11 ` Dan Malek
2001-11-16 17:15 ` Armin Kuster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BF65B8B.EB015B30@intrex.net \
--to=rblach@intrex.net \
--cc=dan@embeddededge.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=mporter@mvista.com \
--cc=paulus@samba.org \
--cc=trini@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).