Auto-detecting touchscreen controller and dealing with hw configuration differences on q8 tablets

[Hans de Goede]

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 syncing 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