Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752383Ab2KLMF5 (ORCPT ); Mon, 12 Nov 2012 07:05:57 -0500 Received: from li42-95.members.linode.com ([209.123.162.95]:54046 "EHLO li42-95.members.linode.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751358Ab2KLMFz convert rfc822-to-8bit (ORCPT ); Mon, 12 Nov 2012 07:05:55 -0500 Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: 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: <509D8A62.1080102@wwwdotorg.org> Date: Mon, 12 Nov 2012 14:05:47 +0200 Cc: David Gibson , Grant Likely , Kevin Hilman , Matt Porter , Koen Kooi , linux-kernel , Felipe Balbi , Deepak Saxena , Scott Wood , Russ Dill , linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org Content-Transfer-Encoding: 8BIT Message-Id: References: <20121109022624.GI23553@truffula.fritz.box> <509D8A62.1080102@wwwdotorg.org> To: Stephen Warren 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: 4848 Lines: 116 Hi Stephen, On Nov 10, 2012, at 12:57 AM, Stephen Warren wrote: > On 11/08/2012 07:26 PM, David Gibson wrote: > ... >> I also think graft will handle most of your use cases, although as I >> said I don't fully understand the implications of some of them, so I >> could be wrong. So, the actual insertion of the subtree is pretty >> trivial to implement. phandles are the obvious other matter to be >> dealt with. I haven't found the right thread where what you've >> envisaged so far is discussed, so here are things I can see: >> >> 1) Avoiding phandle collisions between main tree and subtree (or >> between subtrees). >> >> I'm hopeful that this can be resolved just by establishing some >> conventions about the ranges of phandles to be used for various >> components. I'd certainly be happy to add a directive to dtc which >> enforces allocation of phandles within a specified range. > > One case I wonder about is: > > Base board A that's split into two .dts files e.g. due to there being > two versions of the base board which are 90% identical, yet there being > a few differences between them. > > Base board B that's just a single .dts file. > > We might allocate phandle range 0..999 for the base board. > > Child board X plugs into either, so the two base boards need to "export" > the same set of phandle IDs to the child board to allow it to reference > them. > > If base board A version 2 comes along after the phandle IDs that the > child board uses are defined, then how do we handle assigning a specific > phandle ID range to each of base board A's two version-specific > overlays, when the version-specific changes might affect arbitrary > phandle IDs within the range, and require some to be moved into the base > board version-specific overlays and some to stay in the common base > board .dts? > Static phandle allocation, could work, but not without considerable trouble. Maybe we're over-engineering things. Perhaps having the kernel use the phandle values generated by dtc is not required. What about the following simple scheme: 1) Have dtc create local phandle values the same way, as it is today. Generate the flat tree normally, but keep in a table the locations of all phandle references. Keep track of non resolvable phandle references in a different table. One could use the fixup mechanism I described in a previous email, if you don't care about keeping a big table. 2) Upon loading the base DT or the overlay, the kernel makes sure the phandles don't overlap; simply add a per DT fragment constant offset. 3) Resolve phandle references that were unresolved at compile time. >> 2) Resolving phandle references within a subtree >> >> If we can handle (1) by convention, we don't need anything here, the >> references are fine as is. >> >> (3) Resolving phandle references from the subtree to the main tree. >> >> So, I think this can actually be avoided, at least in cases where what >> physical connections are available to the expansion module is well >> defined. The main causes to have external references are interrupts >> and gpios. Interrupts we handle by defining an interrupt specifier >> space for the interrupts available on the expansion >> socket/connector/bus/whatever. In the master tree we then have >> something like: >> >> ... >> expansion-socket@XXXX { >> expansion-id = "SlotA"; >> interrupt-map = < /* map expansion irq specs to >> board interrupt controllers */ >; >> interrupt-map-mask = < ... >; >> ranges = < /* map expansion local addresses to global >> mmio */ >; >> }; > > We would end up needing an interrupt-map or ranges type of property for > basically any resource type. > > For example, what about an I2C bus that's routed to the daughter board, > and the daughter board contains an I2C bus mux, whose control path isn't > through I2C but rather GPIOs? In this case, the I2C bus mux isn't a > child of the I2C bus, but a separate entity that indicates its parent > I2C bus using a phandle. I presume a similar argument applies to almost > any kind of resource. This is probably do-able, but certainly something > to consider with the socket approach. I do like the socket approach though. Capebus has taken this approach. You see, perhaps from the standpoint of the standard platform devices that a cape provides, a bus is not a very fitting construct. But from a hardware engineer/user perspective, a cape is an expansion board, and virtual slots are used. This is similar to what you're saying with socket approach, right? 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/