Message-ID: <509A97D0.5010006@wwwdotorg.org>
Date:	Wed, 07 Nov 2012 10:18:08 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <robherring2@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Scott Wood <scottwood@...escale.com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices
 to mach-omap2)

On 11/07/2012 01:47 AM, Pantelis Antoniou wrote:
> Hi Stephen,
> 
> On Nov 6, 2012, at 11:37 PM, Stephen Warren wrote:
> 
>> On 11/05/2012 01:40 PM, Grant Likely wrote:
>>> Hey folks,
>>>
>>> As promised, here is my early draft to try and capture what device
>>> tree overlays need to do and how to get there. Comments and
>>> suggestions greatly appreciated.
>>
>> Interesting. This just came up internally at NVIDIA within the last
>> couple weeks, and was discussed on the U-Boot mailing list very recently
>> too:
>>
>> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227
>> (it spills into the November archive too)
> 
> I am aware of this discussion. For our use case u-boot DT manipulation was
> tried, but then abandoned. Asking our user base to modify anything in u-boot
> was ruled out.
>  
>>
>>> For these cases it is proposed to implement an overlay feature for the
>>> so that the initial device tree data can be modified by userspace at
>>
>> I don't know if you're maintaining this as a document and taking patches
>> to it, but if so:
>>
>> "for the so" split across those two lines.
>>
>>> Jane solves this problem by storing an FDT overlay for each cape in the
>>> root filesystem. When the kernel detects that a cape is installed it
>>> reads the cape's eeprom to identify it and uses request_firmware() to
>>> obtain the appropriate overlay. Userspace passes the overlay to the
>>> kernel in the normal way. If the cape doesn't have an eeprom, then the
>>> kernel will still use firmware_request(), but userspace needs to already
>>> know which cape is installed.
>>
>> As mentioned by Pantelis, multiple versions of a board is also very
>> common. We already have the following .dts files in the kernel where
>> this applies, for the main board even:
>>
>> arch/arm/boot/dts/tegra30-cardhu.dtsi
>> arch/arm/boot/dts/tegra30-cardhu-a02.dts
>> arch/arm/boot/dts/tegra30-cardhu-a04.dts
> 
> Exactly. I've made this point in another email, but IMHO board-revision
> management is exactly the same with cape revision management.
> 
> Ideally you'd like to get rid of those three, and replace it with only
> one that's properly versioned.

I don't expect we would ever get rid of some of those .dts files; there
is after all a common subset that applies to all boards, and an
incremental difference that applies to only A02/3, and another for
A04/5/... Representing those as separate source files seems appropriate
to me. If we try and dump all the multiple versions into a single file
with some markup indicating which version of the board some sub-sections
of the .dts apply to, I think we'll end up with rather complex .dts
files. In this case, the simple overlay model works extremely well.
--
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