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 ?
2) I assume you'vc e left out error handling from the above
for simplicity. I assume that of_changeset_apply() needs some
error return checking ? What about the others ?
And one new question, the overlay manager will need access
to (several) i2c busses, preferably I can pass in a phandle
to these in devicetree, do you have any experience with /
examples of doing such a thing ?
Regards,
Hans
--
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
