Hi Grant,
On Nov 5, 2012, at 1:37 AM, Grant Likely wrote:
> On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou
> <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> The i2c2 alias cannot be resolved at compile time; there has to be
>>
>> a) A DT object format where unresolved aliases (symbols) are tracked
>> b) A runtime DT linker that will resolve the alias, and will insert the
>> i2c2-devices child nodes as children in the i2c2 node.
>> c) A method to trigger platform device creation for the child nodes just
>> inserted.
>>
>> DT core changes aren't bound to be easily accepted, so without having a clear
>> signal from the DT maintainers that they would consider such a method people
>> are just hesitant to go down this road.
>
> I do agree and will accept such a method.
>
> g.
Understood.
I'll think about the issues and come up with a design for the format, but
let's talk about this in the open for a while.
I don't want to modify the DTB format, in order to avoid impacting any other
DT users.
So would something like this work for you?
-----8<--------8<--------
/* booting DT (all symbols are resolved) */
/* this is a valid DTB today */
/ {
i2c2: i2c@4819c000 {
compatible = "ti,omap4-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3"; /* TODO: Fix hwmod */
reg = <0x4819c000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <30>;
status = "on-demand";
};
/* .... others nodes .... */
/* the symbols node can be generated by the DTC */
symbols {
compatible = "dt,symbols";
symbol@0 {
name = "i2c2";
phandle = <&i2c2>;
};
...
};
};
-----8<--------8<--------
/* fragment DT (not all symbols are resolved) */
/ {
i2c2-append {
compatible = "dt,append";
#address-cells = <1>;
#size-cells = <0>;
append-at = <&i2c2>; /* offset F00, either -1 (end of list) */
/* or next offset in the list of i2c2 refs. */
/* Ambient light sensor */
tsl2550@39 {
compatible = "tsl,tsl2550";
reg = <0x39>;
};
};
};
-----8<--------8<--------
The <&i2c2> value can't be resolved at compile time.
We can use a simple linked list method for keeping track of the
locations in the fragment which we need to resolve, terminating with -1.
The compiler can add the following nodes to mark the entries requiring
resolution.
For example i2c2...
dt-resolution {
i2c2 = <0xf00>; /* first offset in the dtb fragment requiring */
/* resolution of i2c2 */
....
};
The dt-resolution node, can be appended to the dt fragment contents and
can be generated by the compiler.
Upon injection of the DT fragment the in-kernel loader can perform
symbol resolution and replace the phandles with the in-kernel values.
I know there's an aliases node, but I don't know if it's wise to modify it.
What do you think?
Regards
-- Pantelis
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
