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

[Icenowy Zheng]

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" :
> 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  wrote:
>
> 
>
>>>  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:
>
> 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
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Holger Schurig]

> 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 0xff /env/logo.png
fb0.enable=1
pwm_0208.period_ns=20
pwm_0208.duty_ns=16
pwm_0208.enable=1
fi
gpio_set_value 191 1

There are also commands available to directly modify the device tree.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Pantelis Antoniou]

Hi Hans,

> On Jun 20, 2016, at 14:03 , Hans de Goede  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  wrote:
> 
> 
> 
>>> 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 ?
> 

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();
of_changeset_add_property_bool(, np, “invert-x”);
of_changeset_update_property_string(, np, “status”, “okay”);

of_changeset_apply();

> Thanks & Regards,
> 
> Hans

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Hans de Goede]

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  wrote:





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:

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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Pantelis Antoniou]

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  wrote:
> 
> 
> 
> 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 -, 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:
> 

Yeah, you’re going to be fighting a losing battle.

> 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