@@ -29,7 +29,7 @@#include<asm/dpmc.h>#if IS_ENABLED(CONFIG_TOUCHSCREEN_AD7879)-#include<linux/spi/ad7879.h>+#include<linux/input/ad7879.h>#define LCD_BACKLIGHT_GPIO 0x40/* TLL6527M uses TLL7UIQ35 / ADI LCD EZ Extender. AD7879 AUX GPIO is used for*LCDBacklightEnable
@@ -0,0 +1,41 @@+/* linux/input/ad7879.h */++/* Touchscreen characteristics vary between boards and models. The+*platform_dataforthedevice's"struct device"holdsthisinformation.+*+*It'sOKifthemin/maxvaluesarezero.+*/+structad7879_platform_data{+u16model;/* 7879 */+u16x_plate_ohms;+u16x_min,x_max;+u16y_min,y_max;+u16pressure_min,pressure_max;++boolswap_xy;/* swap x and y axes */++/* [0..255] 0=OFF Starts at 1=550us and goes+*allthewayto9.440msinstepsof35us.+*/+u8pen_down_acc_interval;+/* [0..15] Starts at 0=128us and goes all the+*wayto4.096msinstepsof128us.+*/+u8first_conversion_delay;+/* [0..3] 0 = 2us, 1 = 4us, 2 = 8us, 3 = 16us */+u8acquisition_time;+/* [0..3] Average X middle samples 0 = 2, 1 = 4, 2 = 8, 3 = 16 */+u8averaging;+/* [0..3] Perform X measurements 0 = OFF,+*1=4,2=8,3=16(median>averaging)+*/+u8median;+/* 1 = AUX/VBAT/GPIO export GPIO to gpiolib+*requiresCONFIG_GPIOLIB+*/+boolgpio_export;+/* identifies the first GPIO number handled by this chip;+*or,ifnegative,requestsdynamicIDallocation.+*/+s32gpio_base;+};
@@ -1,41 +0,0 @@-/* linux/spi/ad7879.h */--/* Touchscreen characteristics vary between boards and models. The- * platform_data for the device's "struct device" holds this information.- *- * It's OK if the min/max values are zero.- */-struct ad7879_platform_data {- u16 model; /* 7879 */- u16 x_plate_ohms;- u16 x_min, x_max;- u16 y_min, y_max;- u16 pressure_min, pressure_max;-- bool swap_xy; /* swap x and y axes */-- /* [0..255] 0=OFF Starts at 1=550us and goes- * all the way to 9.440ms in steps of 35us.- */- u8 pen_down_acc_interval;- /* [0..15] Starts at 0=128us and goes all the- * way to 4.096ms in steps of 128us.- */- u8 first_conversion_delay;- /* [0..3] 0 = 2us, 1 = 4us, 2 = 8us, 3 = 16us */- u8 acquisition_time;- /* [0..3] Average X middle samples 0 = 2, 1 = 4, 2 = 8, 3 = 16 */- u8 averaging;- /* [0..3] Perform X measurements 0 = OFF,- * 1 = 4, 2 = 8, 3 = 16 (median > averaging)- */- u8 median;- /* 1 = AUX/VBAT/GPIO export GPIO to gpiolib- * requires CONFIG_GPIOLIB- */- bool gpio_export;- /* identifies the first GPIO number handled by this chip;- * or, if negative, requests dynamic ID allocation.- */- s32 gpio_base;-};
--
2.7.0
--
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
From: Stefan Agner <stefan@agner.ch> Date: 2016-01-26 03:04:59
The measurements read from the controller which are temporary stored
in conversion_data, are interpreted wrong. The first measurement X+
contains the Y position, and the second measurement Y+ the X position
(see also Table 11 Register Table in the data sheet).
The problem is already known and a swap option has been introduced:
commit 6680884a4420 ("Input: ad7879 - add option to correct xy axis")
However, with that the meaning of the new boolean is inverted since
the underlying values are already swapped. With this change, a true
in swap_xy actually swaps the two axis.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Hi Michael,
It seems that swap_xy is not used in any board which is in mainline,
hence swap_xy is always false. Therefore, up until now all boards
actually used swapped axis. However, I doubt that the blackfin boards
really have those axis swapped, it is probably more likely that the
userspace calibration took care of it.
However, if they are really swapped, we should set the swap_xy flag
to 1 for those board...
Do you happen to now what is the case with those boards?
From: Stefan Agner <stefan@agner.ch> Date: 2016-01-26 03:05:03
Add device tree support for the I2C variant of AD7879 (AD7879-1). This
allows to specify the touchscreen controller as a I2C client node.
Most of the options available as platform data are also available as
device tree properties. Exporting the GPIO is currently not possible
through device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
.../bindings/input/touchscreen/ad7879-i2c.txt | 47 ++++++++++++++++
drivers/input/touchscreen/ad7879-i2c.c | 63 +++++++++++++++++++++-
drivers/input/touchscreen/ad7879-spi.c | 3 +-
drivers/input/touchscreen/ad7879.c | 2 +-
drivers/input/touchscreen/ad7879.h | 1 +
5 files changed, 113 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ad7879-i2c.txt
@@ -54,9 +55,50 @@ static const struct ad7879_bus_ops ad7879_i2c_bus_ops = {.write=ad7879_i2c_write,};+staticstructad7879_platform_data*ad7879_parse_dt(structdevice*dev)+{+structad7879_platform_data*pdata;+structdevice_node*np=dev->of_node;+interr;+u32tmp;++if(!np)+returnNULL;++pdata=devm_kzalloc(dev,sizeof(*pdata),GFP_KERNEL);++if(!pdata)+returnERR_PTR(-ENOMEM);++err=of_property_read_u32(np,"resistance-plate-x",&tmp);+if(err){+dev_err(dev,"failed to get resistance-plate-x property\n");+returnERR_PTR(err);+}+pdata->x_plate_ohms=(u16)tmp;++err=of_property_read_u32(np,"touchscreen-max-pressure",&tmp);+if(err){+dev_err(dev,"failed to get touchscreen-max-pressure property\n");+returnERR_PTR(err);+}+pdata->pressure_min=(u16)tmp;++of_property_read_u8(np,"first-conversion-delay",&pdata->first_conversion_delay);+of_property_read_u8(np,"acquisition-time",&pdata->acquisition_time);+of_property_read_u8(np,"median-filter-size",&pdata->median);+of_property_read_u8(np,"averaging",&pdata->averaging);+of_property_read_u8(np,"conversion-interval",&pdata->pen_down_acc_interval);++pdata->swap_xy=of_property_read_bool(np,"touchscreen-swapped-x-y");++returnpdata;+}+staticintad7879_i2c_probe(structi2c_client*client,conststructi2c_device_id*id){+structad7879_platform_data*pdata;structad7879*ts;if(!i2c_check_functionality(client->adapter,
drivers/input/touchscreen/ad7879.h:28:21: warning: 'struct ad7879_platform_data' declared inside parameter list
const struct ad7879_bus_ops *bops);
^
quoted
drivers/input/touchscreen/ad7879.h:28:21: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/input/touchscreen/ad7879-spi.c: In function 'ad7879_spi_probe':
quoted
drivers/input/touchscreen/ad7879-spi.c:131:55: error: 'pdata' undeclared (first use in this function)
ts = ad7879_probe(&spi->dev, AD7879_DEVID, spi->irq, pdata,
^
drivers/input/touchscreen/ad7879-spi.c:131:55: note: each undeclared identifier is reported only once for each function it appears in
quoted
drivers/input/touchscreen/ad7879-spi.c:131:7: error: too many arguments to function 'ad7879_probe'
From: Michael Hennerich <michael.hennerich@analog.com> Date: 2016-01-26 08:21:39
On 01/26/2016 04:04 AM, Stefan Agner wrote:
Add device tree support for the I2C variant of AD7879 (AD7879-1). This
allows to specify the touchscreen controller as a I2C client node.
Most of the options available as platform data are also available as
device tree properties. Exporting the GPIO is currently not possible
through device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Hi Stefan,
Thanks for the patch -
There is something similar in our tree but I forgot to send it mainline
a long time ago.
https://github.com/analogdevicesinc/linux/commit/69b16d4b616a4bbe9001d3f67d3ff54f3deb85ce
There are some build issues can you have a look?
I also don't understand why "exporting the GPIO is not possible through
device tree"?
Can you explain?
Regards,
Michael
@@ -54,9 +55,50 @@ static const struct ad7879_bus_ops ad7879_i2c_bus_ops = {.write=ad7879_i2c_write,};+staticstructad7879_platform_data*ad7879_parse_dt(structdevice*dev)+{+structad7879_platform_data*pdata;+structdevice_node*np=dev->of_node;+interr;+u32tmp;++if(!np)+returnNULL;++pdata=devm_kzalloc(dev,sizeof(*pdata),GFP_KERNEL);++if(!pdata)+returnERR_PTR(-ENOMEM);++err=of_property_read_u32(np,"resistance-plate-x",&tmp);+if(err){+dev_err(dev,"failed to get resistance-plate-x property\n");+returnERR_PTR(err);+}+pdata->x_plate_ohms=(u16)tmp;++err=of_property_read_u32(np,"touchscreen-max-pressure",&tmp);+if(err){+dev_err(dev,"failed to get touchscreen-max-pressure property\n");+returnERR_PTR(err);+}+pdata->pressure_min=(u16)tmp;++of_property_read_u8(np,"first-conversion-delay",&pdata->first_conversion_delay);+of_property_read_u8(np,"acquisition-time",&pdata->acquisition_time);+of_property_read_u8(np,"median-filter-size",&pdata->median);+of_property_read_u8(np,"averaging",&pdata->averaging);+of_property_read_u8(np,"conversion-interval",&pdata->pen_down_acc_interval);++pdata->swap_xy=of_property_read_bool(np,"touchscreen-swapped-x-y");++returnpdata;+}+staticintad7879_i2c_probe(structi2c_client*client,conststructi2c_device_id*id){+structad7879_platform_data*pdata;structad7879*ts;if(!i2c_check_functionality(client->adapter,
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
From: Michael Hennerich <michael.hennerich@analog.com> Date: 2016-01-26 09:39:04
On 01/26/2016 04:04 AM, Stefan Agner wrote:
The measurements read from the controller which are temporary stored
in conversion_data, are interpreted wrong. The first measurement X+
contains the Y position, and the second measurement Y+ the X position
(see also Table 11 Register Table in the data sheet).
The problem is already known and a swap option has been introduced:
commit 6680884a4420 ("Input: ad7879 - add option to correct xy axis")
However, with that the meaning of the new boolean is inverted since
the underlying values are already swapped. With this change, a true
in swap_xy actually swaps the two axis.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Hi Michael,
It seems that swap_xy is not used in any board which is in mainline,
hence swap_xy is always false. Therefore, up until now all boards
actually used swapped axis. However, I doubt that the blackfin boards
really have those axis swapped, it is probably more likely that the
userspace calibration took care of it.
However, if they are really swapped, we should set the swap_xy flag
to 1 for those board...
Do you happen to now what is the case with those boards?
Hi Stefan,
I would be hesitant to invert the default behaviour of the driver.
Too many people in the field already using it as it is.
A XY swap can have multiple reasons.
Lot's of small VGA/QVGA TFTs have the option to switch the scan
direction from Landscape to Portrait. In addition you can also rotate
and flip or mirror using VDMA options. So it really depends on the use
case, how the touch panel is mounted to the screen or how it is wired.
Regards,
Michael
From: Stefan Agner <stefan@agner.ch> Date: 2016-01-26 17:06:43
On 2016-01-25 23:58, Michael Hennerich wrote:
On 01/26/2016 04:04 AM, Stefan Agner wrote:
quoted
The measurements read from the controller which are temporary stored
in conversion_data, are interpreted wrong. The first measurement X+
contains the Y position, and the second measurement Y+ the X position
(see also Table 11 Register Table in the data sheet).
The problem is already known and a swap option has been introduced:
commit 6680884a4420 ("Input: ad7879 - add option to correct xy axis")
However, with that the meaning of the new boolean is inverted since
the underlying values are already swapped. With this change, a true
in swap_xy actually swaps the two axis.
Signed-off-by: Stefan Agner <redacted>
---
Hi Michael,
It seems that swap_xy is not used in any board which is in mainline,
hence swap_xy is always false. Therefore, up until now all boards
actually used swapped axis. However, I doubt that the blackfin boards
really have those axis swapped, it is probably more likely that the
userspace calibration took care of it.
However, if they are really swapped, we should set the swap_xy flag
to 1 for those board...
Do you happen to now what is the case with those boards?
Hi Stefan,
I would be hesitant to invert the default behaviour of the driver.
Too many people in the field already using it as it is.
Afaik, we should be able to change in-kernel API's (especially if they
are wrong) since we do not guarantee any API...
A XY swap can have multiple reasons.
Lot's of small VGA/QVGA TFTs have the option to switch the scan
direction from Landscape to Portrait. In addition you can also rotate
and flip or mirror using VDMA options. So it really depends on the use
case, how the touch panel is mounted to the screen or how it is wired.
Ok, I see the reason for that functionality.
I am mainly concerned about the new DT bindings. The touchscreen binding
documents specify touchscreen-swapped-x-y, see:
https://www.kernel.org/doc/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
I would like to make sure that this property is really swapping axis
(and not necessary if the hardware is implemented according to the
datasheet...)
We could also implement a workaround to keep the platform data behavior
as is (invert the swap_xy flag)...
--
Stefan
--
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
From: Stefan Agner <stefan@agner.ch> Date: 2016-01-26 17:12:31
On 2016-01-26 00:14, Michael Hennerich wrote:
On 01/26/2016 04:04 AM, Stefan Agner wrote:
quoted
Add device tree support for the I2C variant of AD7879 (AD7879-1). This
allows to specify the touchscreen controller as a I2C client node.
Most of the options available as platform data are also available as
device tree properties. Exporting the GPIO is currently not possible
through device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Yeah I saw that patch. I tried to use the standard touchscreen
properties where applicable.
Also, my implementation is currently only for I2C. However, when I now
think about it, I might as well move my code into ad7879.c which would
enable to use the same bindings for SPI devices too.
There are some build issues can you have a look?
Yeah I saw, shame on me. Will fix them.
I also don't understand why "exporting the GPIO is not possible
through device tree"?
Can you explain?
I should have written "not implemented" instead of "not possible".
To implement proper device tree GPIO bindings it would need some more
changes. I did not look into that, hence the current device tree
bindings do not allow to enable the GPIO functionality.
--
Stefan
@@ -54,9 +55,50 @@ static const struct ad7879_bus_ops ad7879_i2c_bus_ops = {.write=ad7879_i2c_write,};+staticstructad7879_platform_data*ad7879_parse_dt(structdevice*dev)+{+structad7879_platform_data*pdata;+structdevice_node*np=dev->of_node;+interr;+u32tmp;++if(!np)+returnNULL;++pdata=devm_kzalloc(dev,sizeof(*pdata),GFP_KERNEL);++if(!pdata)+returnERR_PTR(-ENOMEM);++err=of_property_read_u32(np,"resistance-plate-x",&tmp);+if(err){+dev_err(dev,"failed to get resistance-plate-x property\n");+returnERR_PTR(err);+}+pdata->x_plate_ohms=(u16)tmp;++err=of_property_read_u32(np,"touchscreen-max-pressure",&tmp);+if(err){+dev_err(dev,"failed to get touchscreen-max-pressure property\n");+returnERR_PTR(err);+}+pdata->pressure_min=(u16)tmp;++of_property_read_u8(np,"first-conversion-delay",&pdata->first_conversion_delay);+of_property_read_u8(np,"acquisition-time",&pdata->acquisition_time);+of_property_read_u8(np,"median-filter-size",&pdata->median);+of_property_read_u8(np,"averaging",&pdata->averaging);+of_property_read_u8(np,"conversion-interval",&pdata->pen_down_acc_interval);++pdata->swap_xy=of_property_read_bool(np,"touchscreen-swapped-x-y");++returnpdata;+}+staticintad7879_i2c_probe(structi2c_client*client,conststructi2c_device_id*id){+structad7879_platform_data*pdata;structad7879*ts;if(!i2c_check_functionality(client->adapter,
Hi Stefan,
On Mon, Jan 25, 2016 at 07:04:37PM -0800, Stefan Agner wrote:
quoted hunk
Add device tree support for the I2C variant of AD7879 (AD7879-1). This
allows to specify the touchscreen controller as a I2C client node.
Most of the options available as platform data are also available as
device tree properties. Exporting the GPIO is currently not possible
through device tree.
Signed-off-by: Stefan Agner <redacted>
---
.../bindings/input/touchscreen/ad7879-i2c.txt | 47 ++++++++++++++++
drivers/input/touchscreen/ad7879-i2c.c | 63 +++++++++++++++++++++-
drivers/input/touchscreen/ad7879-spi.c | 3 +-
drivers/input/touchscreen/ad7879.c | 2 +-
drivers/input/touchscreen/ad7879.h | 1 +
5 files changed, 113 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ad7879-i2c.txt
@@ -54,9 +55,50 @@ static const struct ad7879_bus_ops ad7879_i2c_bus_ops = {.write=ad7879_i2c_write,};+staticstructad7879_platform_data*ad7879_parse_dt(structdevice*dev)+{+structad7879_platform_data*pdata;+structdevice_node*np=dev->of_node;+interr;+u32tmp;++if(!np)+returnNULL;++pdata=devm_kzalloc(dev,sizeof(*pdata),GFP_KERNEL);++if(!pdata)+returnERR_PTR(-ENOMEM);++err=of_property_read_u32(np,"resistance-plate-x",&tmp);+if(err){+dev_err(dev,"failed to get resistance-plate-x property\n");+returnERR_PTR(err);+}+pdata->x_plate_ohms=(u16)tmp;++err=of_property_read_u32(np,"touchscreen-max-pressure",&tmp);+if(err){+dev_err(dev,"failed to get touchscreen-max-pressure property\n");+returnERR_PTR(err);+}+pdata->pressure_min=(u16)tmp;++of_property_read_u8(np,"first-conversion-delay",&pdata->first_conversion_delay);+of_property_read_u8(np,"acquisition-time",&pdata->acquisition_time);+of_property_read_u8(np,"median-filter-size",&pdata->median);+of_property_read_u8(np,"averaging",&pdata->averaging);+of_property_read_u8(np,"conversion-interval",&pdata->pen_down_acc_interval);++pdata->swap_xy=of_property_read_bool(np,"touchscreen-swapped-x-y");
I'd prefer if we used device_property_* API instead of of_property_*, so
that properties would work not only on OF, but also on other platforms
and even legacy boards could potentially be converted to properties.
Thanks.
--
Dmitry
--
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
On Tue, Jan 26, 2016 at 09:04:20AM -0800, Stefan Agner wrote:
On 2016-01-25 23:58, Michael Hennerich wrote:
quoted
On 01/26/2016 04:04 AM, Stefan Agner wrote:
quoted
The measurements read from the controller which are temporary stored
in conversion_data, are interpreted wrong. The first measurement X+
contains the Y position, and the second measurement Y+ the X position
(see also Table 11 Register Table in the data sheet).
The problem is already known and a swap option has been introduced:
commit 6680884a4420 ("Input: ad7879 - add option to correct xy axis")
However, with that the meaning of the new boolean is inverted since
the underlying values are already swapped. With this change, a true
in swap_xy actually swaps the two axis.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
Hi Michael,
It seems that swap_xy is not used in any board which is in mainline,
hence swap_xy is always false. Therefore, up until now all boards
actually used swapped axis. However, I doubt that the blackfin boards
really have those axis swapped, it is probably more likely that the
userspace calibration took care of it.
However, if they are really swapped, we should set the swap_xy flag
to 1 for those board...
Do you happen to now what is the case with those boards?
Hi Stefan,
I would be hesitant to invert the default behaviour of the driver.
Too many people in the field already using it as it is.
Afaik, we should be able to change in-kernel API's (especially if they
are wrong) since we do not guarantee any API...
quoted
A XY swap can have multiple reasons.
Lot's of small VGA/QVGA TFTs have the option to switch the scan
direction from Landscape to Portrait. In addition you can also rotate
and flip or mirror using VDMA options. So it really depends on the use
case, how the touch panel is mounted to the screen or how it is wired.
Ok, I see the reason for that functionality.
I am mainly concerned about the new DT bindings. The touchscreen binding
documents specify touchscreen-swapped-x-y, see:
https://www.kernel.org/doc/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
I would like to make sure that this property is really swapping axis
(and not necessary if the hardware is implemented according to the
datasheet...)
We could also implement a workaround to keep the platform data behavior
as is (invert the swap_xy flag)...
That is probably the best option.
Thanks.
--
Dmitry
From: Rob Herring <robh@kernel.org> Date: 2016-01-29 03:00:39
On Mon, Jan 25, 2016 at 07:04:37PM -0800, Stefan Agner wrote:
quoted hunk
Add device tree support for the I2C variant of AD7879 (AD7879-1). This
allows to specify the touchscreen controller as a I2C client node.
Most of the options available as platform data are also available as
device tree properties. Exporting the GPIO is currently not possible
through device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
.../bindings/input/touchscreen/ad7879-i2c.txt | 47 ++++++++++++++++
drivers/input/touchscreen/ad7879-i2c.c | 63 +++++++++++++++++++++-
drivers/input/touchscreen/ad7879-spi.c | 3 +-
drivers/input/touchscreen/ad7879.c | 2 +-
drivers/input/touchscreen/ad7879.h | 1 +
5 files changed, 113 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ad7879-i2c.txt