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

[Grant Likely <grant.likely@secretlab.ca>]

On Thu, Aug 5, 2010 at 4:34 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On 5 Aug 2010, at 23:04, Grant Likely wrote:
>> On Thu, Aug 5, 2010 at 3:42 PM, Mark Brown
>> <broonie@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....
>
> This is purely on the basis that the error rate and the volume of data are correlated.
>
>> 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 do have to link the device tree into the wrapper image you run into fun and games with any per system data like MAC addresses which might be embedded in the device tree.
>
> Also, it's not just good and bad firmware that's the issue - like I say, there are also coordination issues within large development teams to consider.

I'm starting a working group to prepare a set of requirements,
recommendations and sample implementation for an ARM boot
architecture.  Particularly useful for more-or-less general purpose
OSes like Ubuntu on ARM.  We'll be talking about these kinds of
issues.  Would you like me to cc you when I kick it off?



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