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

[Gupta, Pekon]

Hi Jason,

>From: Jason Kridner
>
>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.
>>
>> Robert has been talking about the actions required to clean-up Debian
>> Jessie support in another thread
>> (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ)
>> and I suggested we should add a bit of a detour by cleaning up the
>> cape support for the mainline kernel and switching away our primary
>> process of supporting capes from using overlays to using a single
>> devicetree file provided at boot. I promised a pull-request and hadn't
>> gotten around to sending it until now (below). No architecture changes
>> have been made in my pull-request, just bringing in the kernel
>> devicetree source history. This suggestion is based on several
>> assumptions, any number of which might be wrong.
>>
>> The assumptions (for which I'm looking for feedback/corrections):
>> * The overlays pretty much all need to be compiled into the kernel if
>> they are going to be loaded using kernel command-line arguments or
>> /etc/capemgr for the majority of distros. While many cape devicetree
>> use cases are perfectly happy with loading at run-time rather than
>> boot-time, it seems there should be a mechanism for pushing cape
>> support into the category of being available at boot-time across
>> distributions.
>> * The devicetree sources, including the primary boot .dts files, will
>> eventually be removed from the kernel source tree. I'm not too sure if
>> and when it'll really happen, but starting up a project to maintain
>> the definitive beagleboard.org board devicetree files outside the
>> kernel seems to make sense. Given the interdependency of the boot .dtb
>> and the overlay .dtbo files, combining them into a single repository
>> where every distribution can pick them up seems like a natural and
>> obvious choice. There are of course some dependencies on kernel
>> versions, but I believe most of those have settled out by now and we
>> should be OK moving forward.

+1
Yes, moving cape DTS out of kernel tree should help developers.
There are quite a few cape patches floating in mail-lists, but as cape
DTS is still not accepted in mainline so they get lost and forgotten.
So one place for collecting all this is a good idea.


However, somehow the universal I/O DTS looked seemed complicated:
(1)
All capes work standalone, but due to share pin-mux some cape
combinations cannot be used simultaneously. But most users of
BeagleBone are already well-versed with DT and kernel infrastructure,
so they need not be spoon fed to get a out-of-box working solution
for each combination. If there is proper documentation is available
about compatibility of capes with each other, then users will figure
out themselves.

(2)
Also, there was a talk of enabling and disabling DT fragments via u-boot.
That should also be explored instead of complicating cape DTS.

(3)
BeagleBone community and outside are coming out with new featured
capes, which might possess a challenge to get a absolute non-conflicting
universal I/O DTS. What might be working today might have conflicts
tomorrow with introduction of new capes.
We should be open to be compatible to capes developed outside
Beaglebone.org. In my view this is important for longer term.
Example: http://valentfx.com/logi-bone/

So, plz review my feedback and if you plan to create an external tree
for beaglebone Capes, I would be happy to submit some cape patches.


with regards, pekon