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@xxxxxxxxx> 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? The logical way to deal with this is to have the boot loader merge DT fragments together before it calls the kernel, so the kernel sees a single DT blob which describes the whole hardware. A good way that this could have been done is to put an I2C EEPROM on each cape, and have that store the DT fragment. The boot loader could have then read that from each cape, and used that information to build up the final DT. Why this hasn't been thought of, considering that the kernel has been moving towards DT for years, is quite unbelievable. I'm quite sure you're going to say that that introduces additional hardware expense. Yes it does, but it also eliminates the problem you are now bringing up. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
