[U-Boot] Auto-detecting touchscreen controller and dealing with hw configuration differences on q8 tablets
<resend with Pantelis' email address fixed>
Hi All,
The sunxi support in the kernel supports (amongst many other devices) the quite popular low cost q8 form factor 7" tablets.
These are all based on the same case, with an allwinner SoC inside (there are non allwinner versions, but those are out of scope) and typically all based on the same reference design.
Currently we support any such tablet with 4 u-boot defconfigs / 4 dts files:
q8_a13_tablet q8_a23_tablet_800x480 q8_a33_tablet_800x480 q8_a33_tablet_1026x600
So all the user needs to know to get mainline running on these is which SoC his tablet is using and which resolution his lcd has.
However the reference design gets completed by the manufacturers with whatever accelerometer, wifi chip and touchscreen controller are cheapest for the batch being produced that week.
The plan is (was ?) to use auto-detection to figure out which components are used and adjust the dts using e.g. overlays.
Recently I've been working together with some students from my local university to get a driver for the gsl1680 touchscreen controller used in most of these tablets upstream.
So now I've been testing the touschscreen on all q8 tablets I own and unfortunately things are not so easy. The gsl1680 is quite flexible, it features a number of capacitive sense pins and these can be routed in random order to sense lines in the display, during init the controller gets feed a configuration data file with which pins go where and various lookup tables.
Here is a table of all tablets I've tested:
a13-94v-0: a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw 1024x600 inverted-x a13-tzx-713b-v2.1: a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw 1024x600 a23-q8h-v3: a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 800x480 swapped-x-y a23-tj-a23-q88-v4.0: a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw 1024x600 a23-ippo-q8h-v1.2: a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 800x480 swapped-x-y a33-ippo-q8h-v1.2: a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 800x480 swapped-x-y a33-tzx-723q4: b482 a33-Q8_V2.4_1118/GSL1680_FW_D702.fw 960x480 inverted-x a33-q8-v2.4-1118: b482 a33-Q8_V2.4_1118/GSL1680_FW_D702.fw 960x480 a33-q8h-v1.5: b482 a33-q8h-v1.5/GSL1688_A70_FW.fw 960x480
The first column is <soc>-<pcb-marking>, the second is the chip-id from the gsl1680 (this can be read via i2c), the third column is the configdata file used for testing, the directory-name it is prefixed with is from which board's android image the firmware file was extracted. The 4th column shows the resolution of the reported coordinates and any necessary flags.
Note that the resolution and if we need swapped-x-y actually is fixed for a given fw file, so we need to keep this information paired.
So as you can see which fw file to use, and whether x is inverted or not vary from board to board.
This leaves us with 2 options:
1) Move to 1 dts file per PCB variant solution, of ALL the q8 tablets I've seen I've only ever had 2 with identical PCB-s and those were from the same batch, so this seems unmaintainable. Which leaves us with:
2) Give the user some way to override the dts settings.
Which after a somewhat long intro brings me to the actual purpose of this thread, discuss how to best deal with this. I again see 2 options:
1) Put a disabled gsl1680 node in the dts file, have a q8_autodetect.c in u-boot which probes i2c and if it finds the gsl1680 nodes enables it, and patches in a best-effort default for which fw file to use. Allow the user to set a touchscreen_fw u-boot env variable which will override this. Also allow the user to set a touchscreen_inverted_x env variable to add inverted-x to the dt node for the gsl1680.
2) Write an in kernel overlay manager which does auto-detect as described by 1, and loads an overlay for the detected touchscreen controller, with module options to allow specifying the fw-file, x-inversion, etc.
One things which worries me about 2. is that we would need to have 2 overlay files per fw-file, one regular config, one inverted-x, or is it possible for the overlay manager to modify an overlay before applying it ?
I tend towards doing the auto-detect in u-boot, since that will give the greatest flexibility (the dtb is fully read-writable in u-boot) and I can easily access things like i2c-busses, soc id/version register, etc. there.
But before sinking a lot of time in either one of these I first wanted to discuss this, if the consensus is that an in kernel overlay manager is the way to go I will take a shot at that instead.
Regards,
Hans
Hi Hans,
I’m going to commend only on the overlay related parts since I’m not I get all the nuances right.
On Jun 19, 2016, at 14:06 , Hans de Goede hdegoede@redhat.com wrote:
<resend with Pantelis' email address fixed>
Hi All,
The sunxi support in the kernel supports (amongst many other devices) the quite popular low cost q8 form factor 7" tablets.
These are all based on the same case, with an allwinner SoC inside (there are non allwinner versions, but those are out of scope) and typically all based on the same reference design.
Currently we support any such tablet with 4 u-boot defconfigs / 4 dts files:
q8_a13_tablet q8_a23_tablet_800x480 q8_a33_tablet_800x480 q8_a33_tablet_1026x600
So all the user needs to know to get mainline running on these is which SoC his tablet is using and which resolution his lcd has.
However the reference design gets completed by the manufacturers with whatever accelerometer, wifi chip and touchscreen controller are cheapest for the batch being produced that week.
The plan is (was ?) to use auto-detection to figure out which components are used and adjust the dts using e.g. overlays.
Recently I've been working together with some students from my local university to get a driver for the gsl1680 touchscreen controller used in most of these tablets upstream.
So now I've been testing the touschscreen on all q8 tablets I own and unfortunately things are not so easy. The gsl1680 is quite flexible, it features a number of capacitive sense pins and these can be routed in random order to sense lines in the display, during init the controller gets feed a configuration data file with which pins go where and various lookup tables.
Here is a table of all tablets I've tested:
a13-94v-0: a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw 1024x600 inverted-x a13-tzx-713b-v2.1: a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw 1024x600 a23-q8h-v3: a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 800x480 swapped-x-y a23-tj-a23-q88-v4.0: a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw 1024x600 a23-ippo-q8h-v1.2: a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 800x480 swapped-x-y a33-ippo-q8h-v1.2: a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 800x480 swapped-x-y a33-tzx-723q4: b482 a33-Q8_V2.4_1118/GSL1680_FW_D702.fw 960x480 inverted-x a33-q8-v2.4-1118: b482 a33-Q8_V2.4_1118/GSL1680_FW_D702.fw 960x480 a33-q8h-v1.5: b482 a33-q8h-v1.5/GSL1688_A70_FW.fw 960x480
The first column is <soc>-<pcb-marking>, the second is the chip-id from the gsl1680 (this can be read via i2c), the third column is the configdata file used for testing, the directory-name it is prefixed with is from which board's android image the firmware file was extracted. The 4th column shows the resolution of the reported coordinates and any necessary flags.
Note that the resolution and if we need swapped-x-y actually is fixed for a given fw file, so we need to keep this information paired.
So as you can see which fw file to use, and whether x is inverted or not vary from board to board.
This leaves us with 2 options:
- Move to 1 dts file per PCB variant solution, of ALL the q8 tablets I've seen I've only ever
had 2 with identical PCB-s and those were from the same batch, so this seems unmaintainable. Which leaves us with:
Yeah, you’re going to be fighting a losing battle.
- Give the user some way to override the dts settings.
Which after a somewhat long intro brings me to the actual purpose of this thread, discuss how to best deal with this. I again see 2 options:
- Put a disabled gsl1680 node in the dts file, have a q8_autodetect.c in u-boot
which probes i2c and if it finds the gsl1680 nodes enables it, and patches in a best-effort default for which fw file to use. Allow the user to set a touchscreen_fw u-boot env variable which will override this. Also allow the user to set a touchscreen_inverted_x env variable to add inverted-x to the dt node for the gsl1680.
That can work. The problem is that having anything requiring smarts in u-boot always leads to trouble with users. It all depends on your user’s technical proficiency, if they are comfortable tweaking things in u-boot it’s fine. If it’s not, expect lots of bricked boards when they mess up.
- Write an in kernel overlay manager which does auto-detect as described by 1, and
loads an overlay for the detected touchscreen controller, with module options to allow specifying the fw-file, x-inversion, etc.
One things which worries me about 2. is that we would need to have 2 overlay files per fw-file, one regular config, one inverted-x, or is it possible for the overlay manager to modify an overlay before applying it ?
Yes, it’s quite possible. You can even have stacked overlays.
I tend towards doing the auto-detect in u-boot, since that will give the greatest flexibility (the dtb is fully read-writable in u-boot) and I can easily access things like i2c-busses, soc id/version register, etc. there.
u-boot will work, but you will get into trouble if you demand users to drop to u-boot to make changes.
But before sinking a lot of time in either one of these I first wanted to discuss this, if the consensus is that an in kernel overlay manager is the way to go I will take a shot at that instead.
Regards,
Hans
Regards
— Pantelis
u-boot will work, but you will get into trouble if you demand users to drop to u-boot to make changes.
On my device I use barebox, which is a bit easier *) to use than U-Boot.
Still I don't expect my users to the bootloader. Instead my hardware has a 256 byte i2c EEPROM where I store information. And the user can run a user-space command to change settings there, e.g.
uccomm verbose_boot yes uccomm power_config ignition
... and so on. I could do some of them via bootloader environment files, but not all.
And this is the other obvious way of doing "communication" from Linux user-space to bootloader: setting the environment. The bootloader could mount the partition and try to source some file, to get the info needed.
*) in barebox, you have actual shell-like script that look sane, not variables that call variables, e.g. you can do things like this:
if [ $oem_id = 255 ]; then splash -x 550 -y 500 -b 0xffffff /env/logo.png fb0.enable=1 pwm_02080000.period_ns=200000 pwm_02080000.duty_ns=160000 pwm_02080000.enable=1 fi gpio_set_value 191 1
There are also commands available to directly modify the device tree.
Hi,
On 20-06-16 11:27, Pantelis Antoniou wrote:
Hi Hans,
I’m going to commend only on the overlay related parts since I’m not I get all the nuances right.
No problem and thanks for the answer anyways!
On Jun 19, 2016, at 14:06 , Hans de Goede hdegoede@redhat.com wrote:
<snip>
- Give the user some way to override the dts settings.
Which after a somewhat long intro brings me to the actual purpose of this thread, discuss how to best deal with this. I again see 2 options:
- Put a disabled gsl1680 node in the dts file, have a q8_autodetect.c in u-boot
which probes i2c and if it finds the gsl1680 nodes enables it, and patches in a best-effort default for which fw file to use. Allow the user to set a touchscreen_fw u-boot env variable which will override this. Also allow the user to set a touchscreen_inverted_x env variable to add inverted-x to the dt node for the gsl1680.
That can work. The problem is that having anything requiring smarts in u-boot always leads to trouble with users. It all depends on your user’s technical proficiency, if they are comfortable tweaking things in u-boot it’s fine. If it’s not, expect lots of bricked boards when they mess up.
- Write an in kernel overlay manager which does auto-detect as described by 1, and
loads an overlay for the detected touchscreen controller, with module options to allow specifying the fw-file, x-inversion, etc.
One things which worries me about 2. is that we would need to have 2 overlay files per fw-file, one regular config, one inverted-x, or is it possible for the overlay manager to modify an overlay before applying it ?
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 ?
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.
Thanks & Regards,
Hans
I'm also a user of an A33 Q8 tablet with GSL1680.
However, I think a devicetree-per-device structure is not unacceptable...
We can still have sun{5,8}i-q8.common.dtsi, and write most of the q8 codes there.
Then the device dt can only contain wifi, touchscreen, accelerometer. (after including sun{5,8}i-q8-common.dtsi)
(On my tablet, wifi(esp8089) should use "broken-cd" instead of "non-removable". Touchscreen have a weird chip/firmware that cannot even set a correct STATUS. And mma8452 iio driver will refuse to work if the chip number in dt is the same as the real chip, even the chip id can be probed)
20.06.2016, 19:07, "Hans de Goede" hdegoede@redhat.com:
Hi,
On 20-06-16 11:27, Pantelis Antoniou wrote:
Hi Hans,
I’m going to commend only on the overlay related parts since I’m not I get all the nuances right.
No problem and thanks for the answer anyways!
On Jun 19, 2016, at 14:06 , Hans de Goede hdegoede@redhat.com wrote:
<snip>
2) Give the user some way to override the dts settings.
Which after a somewhat long intro brings me to the actual purpose of this thread, discuss how to best deal with this. I again see 2 options:
1) Put a disabled gsl1680 node in the dts file, have a q8_autodetect.c in u-boot which probes i2c and if it finds the gsl1680 nodes enables it, and patches in a best-effort default for which fw file to use. Allow the user to set a touchscreen_fw u-boot env variable which will override this. Also allow the user to set a touchscreen_inverted_x env variable to add inverted-x to the dt node for the gsl1680.
That can work. The problem is that having anything requiring smarts in u-boot always leads to trouble with users. It all depends on your user’s technical proficiency, if they are comfortable tweaking things in u-boot it’s fine. If it’s not, expect lots of bricked boards when they mess up.
2) Write an in kernel overlay manager which does auto-detect as described by 1, and loads an overlay for the detected touchscreen controller, with module options to allow specifying the fw-file, x-inversion, etc.
One things which worries me about 2. is that we would need to have 2 overlay files per fw-file, one regular config, one inverted-x, or is it possible for the overlay manager to modify an overlay before applying it ?
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 ?
Specifically my plan is to:
Have a single overlay for q8 tablets with gsl1680 tablets
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.
- 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.
Thanks & Regards,
Hans
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Hans,
On Jun 20, 2016, at 14:03 , Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 20-06-16 11:27, Pantelis Antoniou wrote:
Hi Hans,
I’m going to commend only on the overlay related parts since I’m not I get all the nuances right.
No problem and thanks for the answer anyways!
On Jun 19, 2016, at 14:06 , Hans de Goede hdegoede@redhat.com wrote:
<snip>
- Give the user some way to override the dts settings.
Which after a somewhat long intro brings me to the actual purpose of this thread, discuss how to best deal with this. I again see 2 options:
- Put a disabled gsl1680 node in the dts file, have a q8_autodetect.c in u-boot
which probes i2c and if it finds the gsl1680 nodes enables it, and patches in a best-effort default for which fw file to use. Allow the user to set a touchscreen_fw u-boot env variable which will override this. Also allow the user to set a touchscreen_inverted_x env variable to add inverted-x to the dt node for the gsl1680.
That can work. The problem is that having anything requiring smarts in u-boot always leads to trouble with users. It all depends on your user’s technical proficiency, if they are comfortable tweaking things in u-boot it’s fine. If it’s not, expect lots of bricked boards when they mess up.
- Write an in kernel overlay manager which does auto-detect as described by 1, and
loads an overlay for the detected touchscreen controller, with module options to allow specifying the fw-file, x-inversion, etc.
One things which worries me about 2. is that we would need to have 2 overlay files per fw-file, one regular config, one inverted-x, or is it possible for the overlay manager to modify an overlay before applying it ?
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/5028d1ed3beb...
Specifically my plan is to:
Have a single overlay for q8 tablets with gsl1680 tablets
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.
- 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);
Thanks & Regards,
Hans
Regards
— Pantelis
Hi,
On 20-06-16 14:22, Pantelis Antoniou wrote:
Hi Hans,
On Jun 20, 2016, at 14:03 , Hans de Goede hdegoede@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/5028d1ed3beb...
Specifically my plan is to:
Have a single overlay for q8 tablets with gsl1680 tablets
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.
- 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
Hi Hans,
On Jun 20, 2016, at 16:02 , Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 20-06-16 14:22, Pantelis Antoniou wrote:
Hi Hans,
On Jun 20, 2016, at 14:03 , Hans de Goede hdegoede@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/5028d1ed3beb...
Specifically my plan is to:
Have a single overlay for q8 tablets with gsl1680 tablets
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.
- 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:
- Is the functionality needed by the above snippet in mainline ?
Changesets are in mainline; The extended API for the example above is not. So you’ll have to create the property/ies to pass to the bare of_changeset_update_property/of_changeset_add_property methods.
Dig into the bbb-overlays branch and you’ll figure it out.
- 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 ?
Error checking is removed for clarity. On error you simply destroy the changeset. Changes to the tree apply atomically or not at all.
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 ?
No problems there. There’s an I2C API to get the bus from a phandle.
Regards,
Hans
Regards
— Pantelis
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@redhat.com wrote:
Hi,
On 20-06-16 14:22, Pantelis Antoniou wrote:
Hi Hans,
On Jun 20, 2016, at 14:03 , Hans de Goede hdegoede@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/5028d1ed3beb...
Specifically my plan is to:
Have a single overlay for q8 tablets with gsl1680 tablets
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.
- 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:
- 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
Hi Rob,
On Jun 20, 2016, at 21:20 , Rob Herring robh@kernel.org wrote:
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@redhat.com wrote:
Hi,
On 20-06-16 14:22, Pantelis Antoniou wrote:
Hi Hans,
On Jun 20, 2016, at 14:03 , Hans de Goede hdegoede@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/5028d1ed3beb...
Specifically my plan is to:
Have a single overlay for q8 tablets with gsl1680 tablets
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.
- 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:
- 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.
True. I ran out of time and $JOB interfered. I hope I’ll be able to sent out a new patchset this week.
Rob
Regards
— Pantelis
participants (5)
-
Hans de Goede -
Holger Schurig -
Icenowy Zheng -
Pantelis Antoniou -
Rob Herring