From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Matt Sealey" <matt@genesi-usa.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Raquel and Bill <bbrv@genesi-usa.com>
Subject: Re: Question on mpc52xx_common.c
Date: Tue, 8 Apr 2008 08:52:55 -0600 [thread overview]
Message-ID: <fa686aa40804080752g595196det8f576df1884bac5d@mail.gmail.com> (raw)
In-Reply-To: <47FB3CD6.2090706@genesi-usa.com>
On Tue, Apr 8, 2008 at 3:37 AM, Matt Sealey <matt@genesi-usa.com> wrote:
> I'd not thank Grant.
>
> I think the prom_init fixes are bordering on disgusting.. it would
> make it's way into commercial code for sure, but only because nobody
> would see what a hideous mess it is :)
>
> The best solution by far is to release a new firmware with the
> device tree fixed. The script method is just not tolerated by users,
> and patching the Linux kernel to keep track with broken firmwares
> is exactly what we hoped to AVOID with Aura in the first place.
It may be ideal, but I don't think it is realistic. I'm now of the
firm opinion that device trees and firmware are *never* perfect.
Especially when the definition of perfect is a moving target.
There are certainly a number of things that are wrong and missing in
the Efika device tree, but in the long run it is proof that the design
of OF and the device tree is good. The tree is unique. Linux and
other OSes can derive the information they need. Current Linux
drivers want data in a way slightly different from the way the Efika
offers it; some of that is Efika's fault, some of that is the driver's
fault, but OF provides the ability to massage the data and ensure the
board will boot.
As of right now; Linux support for the Efika contains only 4 distinct fixups:
1. Change device_type property of the / node from "chrp" to "efika".
Linux will run the wrong initialization code if this is "chrp"
2. change the format of the bestcomm interrupts property. The Linux
drivers wants a list of interrupts and kind of treats the bestcomm
engine as it's own interrupt controller. I think this was probably a
design flaw on the Linux driver, but it is what we currently have.
3. the /builtin/sound node is missing an interrupts property
4. The FEC driver wants MDIO and PHY nodes to talk to the Ethernet
Phy. This one is big, but it is really just a single fixup.
All the other things that many not be what we *like* in the device
tree are really not serious flaws. Mostly compatible properties are
missing any mfg prefix like 'fsl,'. Of course, as Segher points out,
'fsl,' is better, but doesn't match recommended practice either
because UPPERCASE is supposed to be used with the prefix is the stock
ticker symbol. See? Device tree bindings are never perfect. :-)
Regardless, the drivers deal with it and Linux is happy.
Cheers,
g.
>
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Raquel and Bill wrote:
>
> > Thanks Grant.
> >
> > R&B
> >
> >
> > On Mon, Apr 7, 2008 at 9:25 PM, Grant Likely <grant.likely@secretlab.ca
> <mailto:grant.likely@secretlab.ca>> wrote:
> >
> > On Mon, Apr 7, 2008 at 8:14 PM, Arnd Bergmann <arnd@arndb.de
> >
> > <mailto:arnd@arndb.de>> wrote:
> > > On Tuesday 08 April 2008, Matt Sealey wrote:
> > >
> > > > Grant Likely wrote:
> > > > >
> > > > > Sure, why not? If the firmware has already set it up
> > correctly and no
> > > > > devices using it are in use, then the kernel should be okay.
> > :-)
> > > > > That said, I can't imagine choosing to not put the cdm node
> > into the
> > > > > device tree.
> > > >
> > > > *ahem* Efika.
> > >
> > > Maybe we should just give up on making the efika boot with its
> > regular
> > > device tree and instead add a boot wrapper that either fixes up the
> > > data provided by its firmware or just adds a proper dt blob?
> >
> > Current kernels boot the Efika without any firmware scripts.
> > prom_init.c is able to handle the few fixups that the kernel really
> > wants to see. (So life is mostly happy in Efika land now. :-)
> >
> > Cheers,
> > g.
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org <mailto:Linuxppc-dev@ozlabs.org>
> >
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> >
> >
> > --
> > http://bbrv.blogspot.com/
> >
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2008-04-08 14:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m21w5map5f.fsf@ohwell.denx.de>
[not found] ` <m2wsne9a4c.fsf@ohwell.denx.de>
2008-04-03 19:00 ` Question on mpc52xx_common.c Grant Likely
2008-04-07 22:31 ` Matt Sealey
2008-04-08 2:14 ` Arnd Bergmann
2008-04-08 2:25 ` Grant Likely
[not found] ` <23d2e4300804071926n57746a3cj551ef38bf10486c7@mail.gmail.com>
[not found] ` <47FB3CD6.2090706@genesi-usa.com>
2008-04-08 14:52 ` Grant Likely [this message]
2008-04-08 19:45 ` Robert Schwebel
2008-04-08 20:07 ` Scott Wood
2008-04-08 23:51 ` David Gibson
2008-04-09 6:18 ` Wolfgang Denk
2008-04-08 20:12 ` Timur Tabi
2008-04-08 21:26 ` Grant Likely
2008-04-08 21:51 ` Segher Boessenkool
2008-04-09 16:46 ` Matt Sealey
2008-04-10 6:39 ` Robert Schwebel
2008-04-08 7:56 ` Sven Luther
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=fa686aa40804080752g595196det8f576df1884bac5d@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=bbrv@genesi-usa.com \
--cc=linuxppc-dev@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).