Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Matt Porter]

On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote:
> On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
> > Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
> > 
> > On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner <jkridner at gmail.com> wrote:
> > > I'd like to discuss moving our current library of cape devicetree
> > > overlay sources into a single tree, including the boot .dtb files for
> > > BeagleBoard.org boards and moving towards enabling as much of the cape
> > > support into a single boot-time .dtb file with an approach similar to
> > > the cape-universal overlay
> > > (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
> > > in an overlay.
> > >
> > > First of all, I want to note this doesn't change my view on the
> > > importance of mainline support for devicetree overlays. They are still
> > > absolutely critical and highly useful, solving problems that cannot be
> > > solved through boot-time devicetrees. I'm simply looking for an
> > > approach that will complement the availability of overlays and provide
> > > the best user experience.
> 
> Here's the most obvious question in the world on this topic.  Are capes
> hot-pluggable?
> 
> Looking at the posts on google+ from David Anders, they're using pin
> headers for connectivity, with no additional protection against hot-
> plugging, and no sequencing of pin connection.  In other words, they are
> not hot-pluggable.
> 
> So, why do we need to add a load of infrastructure to the kernel to allow
> the device tree to be modified at run time?  At present, the way the
> entire DT infrastructure works is that it assumes the DT remains static
> and never changes - this applies not only to the core DT code, but also
> to all the drivers which have been converted.
> 
> So, you're asking for a feature which is impossible to really make use
> of on the hardware which you want to use it.
> 
> Why should kernel developers go to the extent of adding support for DT
> modification at runtime when the platform you want this for doesn't even
> support hotplugging of these capes?

It's important to note that Jason's use case is not the real one driving
runtime DT modification. You'll have to go back to threads like
https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all
hashed out. The clearest use cases are the FPGA folks that are loading
their bitstream from userspace and due to DT-everywhere also need to
initiate runtime modification of the live DT tree from userspace.
There's a lot of discussion over many threads where this has been
debated.

-Matt