[linux-sunxi] Re: Auto-detecting touchscreen controller and dealing with hw configuration differences on q8 tablets

[Hans de Goede]

Hi,

On 20-06-16 14:22, Pantelis Antoniou wrote:
> Hi Hans,
>
>> On Jun 20, 2016, at 14:03 , Hans de Goede <hdegoede at redhat.com> 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