linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: akpm@osdl.org, linuxppc-embedded@ozlabs.org, sl@bplan-gmbh.de,
	linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
	sha@pengutronix.de
Subject: Re: [PATCH] General CHRP/MPC5K2 platform support patch
Date: Thu, 26 Oct 2006 08:59:38 +1000	[thread overview]
Message-ID: <1161817178.22582.138.camel@localhost.localdomain> (raw)
In-Reply-To: <528646bc0610251541s21bb45f1t6fc911778d5084@mail.gmail.com>


> What are the implications anyway for the bplan board being CHRP vs the
> way the rest of the embedded ppcs are set up?  Will having this setup
> as a CHRP system conflict w/ non-CHRP embedded boards?  (I'm assuming
> that CHRP requires more capable firmware than u-boot passing in a fdt)

Not really :) The main thing they "buy" by going CHRP is that they use
RTAS for PCI config space access and thus don't have to write the host
bridge code. Since their firmware initializes everything properly, there
is little need for non-generic platform code and that sort of generic
platform code is what CHRP provides.

With the device-tree thingy done properly nowadays, there should be
little difference between platforms unless you end up dealing with
really special things.

There should be no conflict with non-CHRP boards using the MPC5200 chip
provided they do things right which is what I've been advocating so far.
That includes making sure everybody agrees on the format of the MPC5200
specific bits in the device-tree:

 - Format of the interrupt cells (they have come up upon my suggestion
to a 3-cell based format (could probably be compressed a bit but heh)
and that should be documented publically)

 - Binding (set of required properties and their definitions) for on
chip devices, and more specifically, for representing the bestcomm and
the links between devices and associated bestcomm tasks.

If the above is properly agreed upon, then the code for dealing with
MPC5200 specific devices will purely rely on those bits, and thus should
be useable from whatever platform it's included in, wether it's CHRP, or
something else.

Unfortunately, at this point, Nicolas seems to be unwilling to open up
his device-tree publically.

Ben.

  reply	other threads:[~2006-10-25 22:59 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-25 19:05 [PATCH] General CHRP/MPC5K2 platform support patch Nicolas DET
2006-10-25 21:59 ` Paul Mackerras
2006-10-25 22:41   ` Grant Likely
2006-10-25 22:59     ` Benjamin Herrenschmidt [this message]
2006-10-26 11:09       ` Nicolas DET
2006-10-26 11:17     ` Nicolas DET
2006-10-25 22:53 ` Benjamin Herrenschmidt
2006-10-26 11:09   ` Nicolas DET
2006-10-26 12:49     ` Benjamin Herrenschmidt
2006-10-26 12:59       ` Nicolas DET
2006-10-26 16:02         ` Grant Likely
2006-10-26 16:09           ` Grant Likely
2006-10-26 17:06             ` Nicolas DET
2006-10-26 17:54               ` Sylvain Munaut
2006-10-27  3:08                 ` Benjamin Herrenschmidt
2006-10-26 19:14               ` Grant Likely
2006-10-26 19:21                 ` Nicolas DET
2006-10-26 19:32                   ` Nicolas DET
2006-10-27  2:49               ` Benjamin Herrenschmidt
2006-10-26 16:45           ` Sven Luther
2006-10-26 19:50           ` Nicolas DET
2006-10-26 20:00             ` Grant Likely
2006-10-26 20:51               ` Sylvain Munaut
2006-10-27  3:28               ` Benjamin Herrenschmidt
2006-10-27 14:52                 ` Nicolas DET
2006-10-27 15:04                   ` Nicolas DET
2006-10-27 17:08                     ` Jon Loeliger
2006-10-28  0:27                       ` Stephen Rothwell
2006-10-27 22:34                     ` Benjamin Herrenschmidt
2006-10-27 22:05                   ` Sylvain Munaut
2006-10-25 23:01 ` Grant Likely
2006-10-25 23:06   ` Benjamin Herrenschmidt
2006-10-25 23:13     ` Sven Luther
2006-10-26 12:09     ` Nicolas DET
2006-10-26 12:51       ` Benjamin Herrenschmidt
2006-10-26 17:17 ` John Rigby
2006-10-26 17:23   ` Nicolas DET
2006-10-26 17:33   ` Sylvain Munaut
2006-10-27  3:03     ` Benjamin Herrenschmidt
2006-10-27  2:57   ` Benjamin Herrenschmidt

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=1161817178.22582.138.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=sha@pengutronix.de \
    --cc=sl@bplan-gmbh.de \
    /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).