Messages in this thread | | | Subject | Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) | From | Pantelis Antoniou <> | Date | Wed, 7 Nov 2012 12:23:25 +0100 |
| |
Hi Benoit,
On Nov 7, 2012, at 12:12 PM, Benoit Cousson wrote:
> On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: >> Hi Benoit, >>
[snip]
>> I don't know if this breaks any conventions but seems to work fine for our case. > > Yeah, my main concern with that approach is that you change the > structure of the tree by adding an extra node/hierarchy that will not be > there in case of non-versioned tree. > That's why I think we should have something lighter that will not change > the structure. > Ideally we should be able to add extra versioned node to the original > dts without changing it at all. >
You will still need the versioned nodes to be injected to the non-versioned ones. FWIW the driver will use the standard of_property_read_* interface.
You can patch of_property_read to hide the version node matching, and it will work.
I'll leave Grant answer what approach is better, I don't claim to have the insight to handle all cases.
>>> Maybe some extra version match table can just be passed during the board machine_init >>> >>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >>> >> >> Would we need explicit of_platform_populate calls if we have node modification notifiers? >> In that case the notifier would pick it up automatically, and can do the per >> version matching internally. > > Yes indeed, but here I was thinking about an intermediate step, i.e. > now, without any dynamic node insertion mechanism. > Thanks to this simple approach, when can already fix the board > versionning problem. >
As I pointed, with a kind of injection mechanism. the versioned node contents end up in the proper place in the device tree. Your method will work in a much more simpler way.
> Regards, > Benoit >
Regards
-- Pantelis
| |