Date:	Mon, 5 Nov 2012 16:59:56 -0600
From:	Joel A Fernandes <agnel.joel@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Russ Dill <Russ.Dill@...com>, Felipe Balbi <balbi@...com>,
	Benoit Cousson <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, linux-omap@...r.kernel.org,
	Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>,
	devicetree-discuss@...ts.ozlabs.org,
	Rob Herring <robherring2@...il.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

Hi Grant,

On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou
> <panto@...oniou-consulting.com> wrote:
>>> 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.

I am fairly new to the DT world so please bear with me, but how about
a method that resolves symbols the same way that the linux dynamic
linker does when shared libraries are loaded?

A separate table (similar to .PLT/GOT sections  in the ELF object
format) could be created when the fragment is loaded, and the phandle
references could be fixed to point to the table offsets during compile
time. This table would be a second level indirection and the kernel
would populate this table with the in-kernel values of the phandles
that the dt fragment refers to.

This might involve changes to the DT core, but as such, this method
wouldn't suffer from the fragility problem of either base or fragment
DT trees being modified.

The table itself could be added to the tree by the compiler, and the
phandles could point to it (fixed). such phandles could be marked for
special handling to facilitate the 1-level indirection.

What do you think about this?

Regards,
Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists