Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933237Ab2KEPh3 (ORCPT ); Mon, 5 Nov 2012 10:37:29 -0500 Received: from li42-95.members.linode.com ([209.123.162.95]:35079 "EHLO li42-95.members.linode.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932830Ab2KEPhW convert rfc822-to-8bit (ORCPT ); Mon, 5 Nov 2012 10:37:22 -0500 Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Pantelis Antoniou In-Reply-To: Date: Mon, 5 Nov 2012 16:37:14 +0100 Cc: Alan Cox , Russ Dill , Felipe Balbi , Benoit Cousson , Tony Lindgren , linux-kernel , Koen Kooi , Matt Porter , linux-omap@vger.kernel.org, Kevin Hilman , Paul Walmsley , devicetree-discuss@lists.ozlabs.org, Rob Herring Content-Transfer-Encoding: 8BIT Message-Id: References: <50924DA3.1060901@ti.com> <20121101110418.GF410@arwen.pp.htv.fi> <3AF5A6FC-61D9-40CA-85B3-81C2C788CB76@antoniou-consulting.com> <20121101124025.GA12489@arwen.pp.htv.fi> <20121101131609.GC12489@arwen.pp.htv.fi> <20121101135148.382aec00@pyramind.ukuu.org.uk> <9F25E89E-9194-4725-8A8C-053DCBADA1DB@antoniou-consulting.com> <20121101220518.GE14982@arwen.pp.htv.fi> <20121102112104.4657fb7b@pyramind.ukuu.org.uk> <0EC43413-1DD7-4E2A-879B-0B5B926FFDFE@antoniou-consulting.com> To: Grant Likely X-Mailer: Apple Mail (2.1085) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3065 Lines: 124 Hi Grant, On Nov 5, 2012, at 1:37 AM, Grant Likely wrote: > On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou > 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/