Question on mpc52xx_common.c
grant.likely at secretlab.ca
Wed Apr 9 00:52:55 EST 2008
On Tue, Apr 8, 2008 at 3:37 AM, Matt Sealey <matt at 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.
> Matt Sealey <matt at 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 at secretlab.ca
> <mailto:grant.likely at secretlab.ca>> wrote:
> > On Mon, Apr 7, 2008 at 8:14 PM, Arnd Bergmann <arnd at arndb.de
> > <mailto:arnd at 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 at ozlabs.org <mailto:Linuxppc-dev at ozlabs.org>
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> > --
> > http://bbrv.blogspot.com/
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
More information about the Linuxppc-dev