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

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

[Hans de Goede]

<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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hans de Goede]

<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

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

[Hans de Goede]

<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

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

Re: 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 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.

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

[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 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.

Re: 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 <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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:

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

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

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

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

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

Re: 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" <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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:
>
> 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-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

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" <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:
>
> 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-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[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" <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:
>
> 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-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: 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 <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 ?
> 

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);

> Thanks & Regards,
> 
> Hans

Regards

— Pantelis

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

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 <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>
> 
>>> 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(&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

[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 <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>
> 
>>> 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(&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

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

[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@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

[U-Boot] [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@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

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

[Pantelis Antoniou]

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/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 ?

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.

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

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

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

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

[Pantelis Antoniou]

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/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 ?

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.

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

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

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

[Pantelis Antoniou]

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/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 ?

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.

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

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

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

[Rob Herring]

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

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

[Rob Herring]

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/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 ?
> 
> 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

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

[Rob Herring]

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/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 ?
> 
> 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

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

[Pantelis Antoniou]

Hi Rob,

> On Jun 20, 2016, at 21:20 , Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> 
>>> Hi,
>>> 
>>> On 20-06-16 14:22, Pantelis Antoniou wrote:
>>>> Hi Hans,
>>>> 
>>>>> On Jun 20, 2016, at 14:03 , Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 ?
>> 
>> 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

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

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

[Pantelis Antoniou]

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/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 ?
>> 
>> 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

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

[Pantelis Antoniou]

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/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 ?
>> 
>> 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

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

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