[RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Stephen Warren]

On 11/12/2012 05:10 AM, Pantelis Antoniou wrote:
> Hi Stephen,
> 
> On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote:
> 
>> On 11/09/2012 09:28 AM, Grant Likely wrote:
>>> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> ...
>>>> I do rather suspect this use-case is quite common. NVIDIA certainly has
>>>> a bunch of development boards with pluggable
>>>> PMIC/audio/WiFi/display/..., and I believe there's some ability to
>>>> re-use the pluggable components with a variety of base-boards.
>>>>
>>>> Given people within NVIDIA started talking about this recently, I asked
>>>> them to enumerate all the boards we have that support pluggable
>>>> components, and how common it is that some boards support being plugged
>>>> into different main boards. I don't know when that enumeration will
>>>> complete (or even start) but hopefully I can provide some feedback on
>>>> how common the use-case is for us once it's done.
>>>
>>> From your perspective, is it important to use the exact same .dtb
>>> overlays for those add-on boards, or is it okay to have a separate
>>> build of the overlay for each base tree?
>>
>> I certainly think it'd be extremely beneficial to use the exact same
>> child board .dtb with arbitrary base boards.
>>
> 
> Oh yes. In fact if one was to use a single kernel image for beagleboard
> and beaglebone, for the cape to work for both, it is required for it's
> dtb to be compatible. 

Well, as Grant pointed out, it's not actually strictly necessary for the
.dtb to be compatible; only the .dts /need/ be compatible, and the .dtb
can be generated at run-time using dtc for example.

Of course, relying on .dts compatibility rather than .dtb compatibility
might negatively impact the complexity of an initrd environment if we
end up loading overlays from there...

> We're not there yet, but people would like to have an upgrade path.
> 
> beaglebone -> beagleboard -> pandaboard -> future-boards
> 
> It is not possible yet, but perhaps newer boards could have that.