Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751705Ab2KFKbr (ORCPT ); Tue, 6 Nov 2012 05:31:47 -0500 Received: from li42-95.members.linode.com ([209.123.162.95]:33614 "EHLO li42-95.members.linode.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751410Ab2KFKbp convert rfc822-to-8bit (ORCPT ); Tue, 6 Nov 2012 05:31:45 -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: <6AE080B68D46FC4BA2D2769E68D765B708174B7D@039-SN2MPN1-023.039d.mgd.msft.net> Date: Tue, 6 Nov 2012 11:31:41 +0100 Cc: Grant Likely , Rob Herring , Deepak Saxena , Benjamin Herrenschmidt , Wood Scott-B07421 , Tony Lindgren , Kevin Hilman , Matt Porter , Koen Kooi , linux-kernel , Felipe Balbi , Russ Dill , "linux-omap@vger.kernel.org" , "devicetree-discuss@lists.ozlabs.org" Content-Transfer-Encoding: 8BIT Message-Id: <52AABEEA-1695-4B28-A342-B234268090F0@antoniou-consulting.com> References: <6AE080B68D46FC4BA2D2769E68D765B708174B7D@039-SN2MPN1-023.039d.mgd.msft.net> To: Tabi Timur-B04825 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: 2686 Lines: 62 Hi Timur, On Nov 5, 2012, at 10:40 PM, Tabi Timur-B04825 wrote: > On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely wrote: > >> Jane is building custom BeagleBone expansion boards called 'capes'. She >> can boot the system with a stock BeagleBoard device tree, but additional >> data is needed before a cape can be used. She could replace the FDT file >> used by U-Boot with one that contains the extra data, but she uses the >> same Linux system image regardless of the cape, and it is inconvenient >> to have to select a different device tree at boot time depending on the >> cape. > > What's wrong with having the boot loader detect the presence of the > Cape and update the device tree accordingly? We do this all the time > in U-Boot. Doing stuff like reading EEPROMs and testing for the > presence of hardware is easier in U-Boot than in Linux. > > For configurations that can be determined by the boot loader, I'm not > sure overlays are practical. > Each use case is different. For our use-cases boot loader DT modifications just won't work. What's nice about the stuff we're talking about is that if you don't use the new functionality, nothing changes for you. Go on and use DT the old way if you'd like. >> Nigel is building a real-time video processing system around a MIPS SoC >> and a Virtex FPGA. Video data is streamed through the FPGA for post >> processing operations like motion tracking or compression. The FPGA is >> configured via the SPI bus, and is also connected to GPIO lines and the >> memory mapped peripheral bus. Nigel has designed several FPGA >> configurations for different video processing tasks. The user will >> choose which configuration to load which can even be reprogrammed at >> runtime to switch tasks. > > Now this, on the other hand, makes more sense. If the hardware > configuration is literally user-configurable, then okay. However, I'm > not sure I see the need to update the device tree. The device tree is > generally for hardware that cannot be discovered/probed by the device > driver. If we're loading a configuration from user space, doesn't the > driver already know what the hardware's capabilities are, since it's > the one doing the uploading of a new FPGA code? Why not skip the > device tree update and just tell the driver what the new capabilities > are? > > -- > Timur Tabi > Linux kernel developer at Freescale 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/