lkml.org 
[lkml]   [2012]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/08/2012 07:26 PM, David Gibson wrote:
...
> So, let me take a stab at this from a more bottom-up approach, and see
> if we meet in the middle somewhere. As I discussed in the other
> thread with Daniel Mack, I can see two different operationso on the
> fdt that might be useful in this context. I think of them as "graft"
> - which takes one fdt and adds it as a new subtree to an existing fdt
> - and "overlay" where a new fdt adds or overrides arbitrary properties
> in an existing tree. Overlay is more or less what we do at the source
> level in dtc already.

One more thought on the differences between overlay and grafting:

With overlay, it's possible to make your overlay a complete DT tree
rooted at /. In some cases, you might find a lower-level node which all
overlaid elements share, and root the overlay process there.

With grafting, you're basically guaranteed to want the child/graft file
to have different parts of itself grafted into different points in the
parent/underlying tree, e.g. to add nodes to an I2C bus, an SPI bus, and
perhaps some bus-less devices at the root (e.g. a new gpio-leds device).
This will require that a child/graft file to consist of multiple chunks
of DT all to be grafted as separate operations, whereas with overlay you
may be able to get away with a single chunk to be overlaid (although
with some of the use-cases discussed, even the overlay approach might
require multiple chunks to be applied).


\
 
 \ /
  Last update: 2012-11-10 01:01    [W:0.372 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site