Re: [PATCH] asoc/multi-component: fsl: add support for variable SSI FIFO depth

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Aug 05, 2010 at 04:04:06PM -0600, Grant Likely wrote:
> On Thu, Aug 5, 2010 at 3:42 PM, Mark Brown

> > i think all the issues from the recent discussion about bootloaders
> > also make it strongly desirable to get the soc generic stuff out of
> > the dts that's shipped separately to the kernel...

> The board specific data has the same issues as the soc specific data
> in this regard, so I don't think it helps much to split it up at the
> .dtb level.  However....

Oh, this is purely on the basis that the error count is related to the
amount of data.  The board specific stuff does at least have more chance
someone actually looked at it on this particular board too.

> Absolutely correct.  All of this discussion and lessons learned has
> distilled the fact the .dtb file must not be linked into the boot
> firmware.  Any design that requires a boot firmware upgrade to
> update/replace the .dtb is broken.  There will still be broken cases,
> but fortunately for the broken cases the .dtb can always be linked
> into the kernel image.  So, for "good" firmware, the .dtb use case
> works really well.  In the "broken" firmware case, the .dtb(s) can be
> linked into the wrapper image and the correct one can be chosen based
> on machine-id or some other discernible board data.  I'm being very
> careful to make sure that using a .dtb doesn't paint anybody into a
> corner.

On the other hand if you end up having to replace the device tree with
one in the wrapper then you've got an issue with any per-system data
like MAC addresses that someone put in the device tree unless you can do
some sort of overlay/fixup thing.

> > Remember rmk's constant complaint about bootloaders on ARM - these
> > are programs that need to get two registers right on kernel start
> > and don't reliably do so.

> Understood.  It is my priority to complete a full-featured sample
> implementation so I can prove that it is actually a useful solution.
> I'm going to start with U-Boot and make sure upstream u-boot always
> passes the correct thing for passing a .dtb

u-boot will probably be fine anyway, it's more the less widely used ones
that people cook up which are a concern here.