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

[Grant Likely]

On Thu, Aug 5, 2010 at 3:42 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On 5 Aug 2010, at 22:19, Grant Likely wrote:
>
>> You are; but the lack of dts factorization must be solved first before
>> looking at whether or not .dtb overlays make sense.  Otherwise we
>> don't have a source for the factorized data.  I personally don't think
>> .dtb overlays are needed, but I'm not closed to the idea either.
>
> 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....

> ... You've got issues on reference boards where the SoC vendor may have shipped a low quality device tree in flash and users are scared to try to reflash the board due to a lack of recovery facilities (so the less we rely on being able to update data flashed into the device the better) and you've got issues on end user projects with large, potentially distributed, teams where coordinating updates between everyone can be tricky especially if those updates need to be done in lockstep (so the less data is shipped outside the kernel the better).

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.

> 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

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.