From: Jon Loeliger <jdl@freescale.com>
To: Matt Sealey <matt@genesi-usa.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: use of fsl, in lite5200b.dts in git current
Date: Thu, 08 Nov 2007 13:57:44 -0600 [thread overview]
Message-ID: <47336A38.1020807@freescale.com> (raw)
In-Reply-To: <47336805.4040807@genesi-usa.com>
Matt Sealey wrote:
> The orderable part numbers add 3 or 4 characters to the front and about
> 8 after. There is a difference between MPC7400 and PPC7400, and the
> low voltage versions, and the different clock speeds. Orderable part
> number for a recent G4 might be PPC7448B1333NL -
Yeah, part, stepping, variant, speed, etc.
> this is a ridiculous
> amount of specificity in a device tree,
Except that some of that information _is_ specified
elsewhere in other properties. Speed, for example.
> and it also does not match the
> datasheet (MPC7448 is the name of the chip).
Because the data sheets are _soooo_ reliable. :-)
> Indeed, so.. at some point we should all sit down and hammer out the
> major issues in describing something like the MPC5121E because right
> now Genesi has a vested interest in that.
You understand that _that_ is being worked on as we, er, speak?
> If we could all agree on how it should be mapped out, with an example
> tree which shows *every damn thing available* so platform developers
> can pick and choose and OF developers can use it as a reference, it
> would make a much happier process.
Right. It's being nailed down, but it is a slow, community process...
> And then we can fix up the Efika to fit some definition of the new
> MPC5200 tree too.
*gasp*
> By the way while I was poking around the tree today I noticed that
> there is a PCI errata fixup handled by a Kconfig in there. Why?
Happens occasionally. And other places as well.
> Surely
> this is something you check the PVR/SVR for and switch on that for
> a runtime solution,
That's not always fine-grained enough to base a decision on it.
> and not trick users with the possibility of
> forgetting to enable some obscure "PCI errata fix" configuration
> item? (CONFIG_PPC_MPC5200_BUGFIX)
It should be in the defconfig. :-)
jdl
next prev parent reply other threads:[~2007-11-08 20:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 21:55 use of fsl, in lite5200b.dts in git current Jon Smirl
2007-11-07 22:17 ` Matt Sealey
2007-11-07 22:18 ` Jon Smirl
2007-11-08 20:40 ` Jon Smirl
2007-11-08 20:47 ` Scott Wood
2007-11-08 20:51 ` Jon Smirl
2007-11-08 20:56 ` Scott Wood
2007-11-08 21:53 ` Jon Smirl
2007-11-08 22:03 ` Scott Wood
2007-11-08 22:17 ` Jon Smirl
2007-11-08 22:30 ` Scott Wood
2007-11-08 20:50 ` Grant Likely
2007-11-07 22:21 ` Jon Smirl
2007-11-08 0:30 ` Matt Sealey
2007-11-08 2:15 ` Jon Smirl
2007-11-08 16:28 ` Scott Wood
2007-11-08 17:04 ` Jon Smirl
2007-11-08 19:48 ` Matt Sealey
2007-11-08 19:57 ` Jon Loeliger [this message]
2007-11-10 14:09 ` Matt Sealey
2007-11-08 20:39 ` Jon Smirl
2007-11-08 3:14 ` Grant Likely
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=47336A38.1020807@freescale.com \
--to=jdl@freescale.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=matt@genesi-usa.com \
/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).