On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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@xxxxxxxxxx> 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. > 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. > Tomi > -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
