Thread (12 messages) 12 messages, 3 authors, 2012-11-06

Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

From: Grant Likely <hidden>
Date: 2012-11-05 20:14:37
Also in: linux-omap, lkml

On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou
[off-list ref] wrote:
quoted
This handles many of the use cases, but it assumes that an overlay is
board specific. If it ever is required to support multiple base boards
with a single overlay file then there is a problem. The .dtb overlays
generated in this manor cannot handle different phandles or nodes that
are in a different place. On the other hand, the overlay source files
should have no problem being compiled for multiple targets, so maybe
it isn't an issue. Plus if dtc is installed on the target, then the
live tree from /proc can be used as the reference when compiling the
overlay.
My worry is that this format is dependent on linking against the board
DTS file. One of the ideas thrown around here was that it might make
sense to store the DTB fragment in the EEPROM of the device.
Right, that wouldn't work well if the base DT changed, or if a
BeagleBone2 is released that has the same header configuration, but
different backing devices. It would be nice to have a solution for
that.
In that case you have a OS independent hardware description, which can
be even used even by the bootloader to access devices it knows not about
at compile time.

Other than that, I have no other objections.
I'm open to suggestions if anyone has any. I have not objections to a
fixup approach, but I'm not comfortable with anything that is fragile
to modifications to the fragment.

g.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help