[RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Pantelis Antoniou]

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 at secretlab.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