On Mon, Jun 20, 2016 at 04:08:47PM +0300, Pantelis Antoniou wrote: > Hi Hans, > > > On Jun 20, 2016, at 16:02 , Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > > > Hi, > > > > On 20-06-16 14:22, Pantelis Antoniou wrote: > >> Hi Hans, > >> > >>> On Jun 20, 2016, at 14:03 , Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >>> > >>> Hi, > >>> > >>> On 20-06-16 11:27, Pantelis Antoniou wrote: > > > > <snip> > > > >>>> Yes, it’s quite possible. You can even have stacked overlays. > >>> > >>> Ok, is there any example code how to change an overlay before applying it out there, > >>> or if not can you point to the functions to use to do this ? > >>> > >> > >> The canonical place for all the dynamic DT stuff is > >> > >> https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays > >> > >> The beaglebone cape manager is here. > >> > >> https://github.com/pantoniou/linux-beagle-track-mainline/commit/5028d1ed3beb8c75b28fce37b1bb5ee551b2ae9e > >> > >>> Specifically my plan is to: > >>> > >>> 1) Have a single overlay for q8 tablets with gsl1680 tablets > >>> > >>> 2) Write an in kernel overlay manager which when it detects a gsl1680 touchscreen > >>> will pick a best-default firmware-file + matching resolution + swap-x-y based on > >>> which SoC (A13/A23/A33) the tablet is based on as well as the gsl1680's chip-id > >>> and will then "patch" this info into the overlay before applying it. This > >>> means being able to set / modify several string, int and bool dt properties. > >>> > >>> 3) Offer a kernel-module option for the overlaymanager which will allows > >>> overriding the defaults for the firmware-filename, etc. This is also > >>> why I want to go with the patch approach instead of having multiple > >>> dt-overlay files. > >>> > >> > >> Hmm, your problem appears to be simpler. You already know all the possible > >> parts that your touchscreen/video/thingy is going to use. > >> > >> You don’t have to use an overlay then. Overlays are built on top of > >> changesets. > >> > >> For example, let’s say that you have various options for a touchscreen out > >> of a finite set. > >> > >> You just put the basic configuration for each in a disable node and your > >> manager only needs to update the properties and set the status to enabled > >> for it to be enabled. > >> > >> For instance let’s say you have an option of two devices (only one of them > >> being present). > >> > >> devA { > >> status = “disabled”; > >> compatible = “foo,A”; > >> }; > >> > >> devB { > >> status = “disabled”; > >> compatible = “bar,B”; > >> }; > >> > >> Your manager can simply use a changeset to enable A and put a property there > >> (example done using the extended helper API for clarity). > >> > >> struct of_changeset cset; > >> struct device_node *np = of_find_node_by_path(“/devA”); > >> > >> of_changeset_init(&cset); > >> of_changeset_add_property_bool(&cset, np, “invert-x”); > >> of_changeset_update_property_string(&cset, np, “status”, “okay”); > >> > >> of_changeset_apply(&cset); > > > > Cool that looks quite nice / easy. 2 questions on the above: > > > > 1) Is the functionality needed by the above snippet in mainline ? > > Changesets are in mainline; The extended API for the example above is not. The reason being that you sent it just before the merge window and there was a comment on it that has not been addressed. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
