Message-Id: <AC5129F0-FF30-46ED-AD57-3FA6CA919F99@antoniou-consulting.com>
Date:	Mon, 5 Nov 2012 16:37:14 +0100
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	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 Nov 5, 2012, at 1:37 AM, Grant Likely wrote:

> On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou
> <panto@...oniou-consulting.com> 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@...9c000 { 
		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-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