linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Nov 2012 11:31:41 +0100
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Tabi Timur-B04825 <B04825@...escale.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <robherring2@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Wood Scott-B07421 <B07421@...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" <linux-omap@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

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 <grant.likely@...retlab.ca> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/