[PATCH 11/11] ARM: versatile: move CLCD configuration to device tree

[Pantelis Antoniou]

Hi Adam,

> On Feb 23, 2016, at 12:32 , Adam Ford <aford173 at gmail.com> wrote:
> 
> On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> (cc'ing a few more people as this is going into generic direction)
>> 
>> On 23/02/16 11:08, Linus Walleij wrote:
>>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>>> 
>>>> This moves the versatile CLCD configuration to the device tree by:
>>> 
>>> As this Schrödinger's cat approach seems controversial, as well
>>> as the alternative to manipulate the DT in memory at run-time,
>>> I will respin the series without the full Versatile support, adding
>>> plug-in for the other ARM boards and and half-baked support
>>> for the Versatile supporting just VGA (like the other reference
>>> designs from ARM).
>>> 
>>> The pluggable displays prove yet again to be a problem to the
>>> world, sigh.
>>> 
>>> I will think of a better solution, if any, for this for v4.6, but will
>>> put forward something that handles the Nomadik and all the
>>> other ARM reference designs for now.
>> 
>> I had a chat with Tom Rini and Pantelis Antoniou yesterday.
>> 
>> Panto is about to send a new series for DT overlay management soon. I
>> haven't had time to test that yet, but what it would give us is that you
>> could build DT overlay binaries as "firmware" into the kernel image, and
>> thus the panel DT data would be there even before rootfs is mounted. The
>> DT overlays can be loaded from the rootfs or initramfs too, if it's not
>> critical to get the display up early.
>> 
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>> 
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>> 
> If there was a nice way to merge the device trees, I would love to
> create device tree 'modules' that could be loaded at will and merged
> just before the time of boot.  I could see this being useful beyond
> just plugable displays.
> 

Looks like you would be happy by having a way to boot using a device tree
blob + a number of device tree overlay blobs to be applied in sequence.

You could append the dtbo’s to the device tree blob (where-ever that may be)
and it should work.

The good thing about this scheme is that it’s independent of the bootloader.

An advanced bootloader (like u-boot) with DT smarts can create the appended
DT blob itself, while a dumb one can just be given the appended blob as
it was created outside of the device.

>> In any case, I think the firmware solution is a good step forward, and
>> will probably work fine for many users. Then again, I haven't tested it
>> yet so I don't know the details, and it's not in the mainline.
>> 
> I am willing to test it, but I'll need the patch and some instructions
> from Panto.
> 

The appended device tree blob thing does not exist yet, but it’s not such a big
problem to add. I’d give it a shot this week.

The standard device tree overlays are in my overlay branch at
https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays

The capemgr has options for parsing a kernel command line to apply an overlay:

https://github.com/pantoniou/linux-beagle-track-mainline/blob/bbb-overlays/drivers/misc/bone_capemgr.c

The command line options are enable_partno & disable_partno where you supply
the part numbers of the capes you want enabled/disabled at boot.

The capemgr is complicated due to the eeprom detection and the horrible kludges done with the
variants (beaglebone white/beaglebone black), but I think you can figure out what’s going
on with the command line options.


>> Tomi
>> 

Regards

— Pantelis