From: Nick Dyer <hidden> Date: 2015-12-02 20:53:01
Hello-
This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).
The intention is to open-source a utility which can read/display this data, this
should be available very shortly.
It would be good if we could agree a single debugfs interface which could be
supported by all touchscreen chips that have this kind of feature, so I've attempted
to keep that part of this vendor neutral.
This patch sequence is also available from
https://github.com/ndyer/linux/commits/diagnostic-debug
Any feedback appreciated.
Best regards
Nick Dyer
From: Nick Dyer <hidden> Date: 2015-12-02 20:51:20
Invert the diagnostic data to match the orientation of the input device.
Signed-off-by: Nick Dyer <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
From: Nick Dyer <hidden> Date: 2015-12-02 20:51:21
Add a file in debugfs directory with info about the chip.
Signed-off-by: Nick Dyer <redacted>
---
Documentation/ABI/testing/debugfs-heatmap | 14 ++++++++++++++
drivers/input/touchscreen/atmel_mxt_ts.c | 22 ++++++++++++++++++++++
2 files changed, 36 insertions(+)
@@ -6,6 +6,13 @@ Description: A directory will be created under heatmap for each device which provides heatmap data.+What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/info+Date:+KernelVersion:+Contact:+Description:+ Info relating to the device, eg hardware/firmware version+ What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/datatype/ Date: KernelVersion:
@@ -48,6 +55,13 @@ Contact: Description: Display name for the data.+What: /sys/kernel/debug/heatmap-xxx/datatype/input_name+Date:+KernelVersion:+Contact:+Description:+ The name of the corresponding input device, if relevant.+ What: /sys/kernel/debug/heatmap-xxx/datatype/data Date: KernelVersion:
From: Nick Dyer <hidden> Date: 2015-12-02 20:51:22
The touchscreen may have a margin where not all the matrix is used. Read
the parameters from T9 and T100 and take account of the difference.
Signed-off-by: Nick Dyer <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 41 ++++++++++++++++++++++++++++----
1 file changed, 36 insertions(+), 5 deletions(-)
From: Nick Dyer <hidden> Date: 2015-12-02 20:51:51
Both T100 and T9 handle range and orientation in a similar fashion.
Reduce duplication between the two implementations.
Signed-off-by: Nick Dyer <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 68 ++++++++++++--------------------
1 file changed, 26 insertions(+), 42 deletions(-)
From: Nick Dyer <hidden> Date: 2015-12-02 20:51:52
The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.
Signed-off-by: Nick Dyer <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++++++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
@@ -0,0 +1,60 @@+What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/+Date:+KernelVersion:+Contact:+Description:+ A directory will be created under heatmap for each device which+ provides heatmap data.++What: /sys/kernel/debug/heatmap-dev_driver_string-dev_name/datatype/+Date:+KernelVersion:+Contact:+Description:+ The device can have multiple heatmap data types. A directory is created+ for each one.++What: /sys/kernel/debug/heatmap-xxx/datatype/format+Date:+KernelVersion:+Contact:+Description:+ Specifies the type of each data value, one of:+ uint8+ uint16+ uint32+ int8+ int16+ int32++What: /sys/kernel/debug/heatmap-xxx/datatype/width+Date:+KernelVersion:+Contact:+Description:+ The width of the data.++What: /sys/kernel/debug/heatmap-xxx/datatype/height+Date:+KernelVersion:+Contact:+Description:+ The height of the data.++What: /sys/kernel/debug/heatmap-xxx/datatype/name+Date:+KernelVersion:+Contact:+Description:+ Display name for the data.++What: /sys/kernel/debug/heatmap-xxx/datatype/data+Date:+KernelVersion:+Contact:+Description:+ Binary attribute for the data.++ The orientation of the data should correspond to the co-ordinates+ reported to the input layer. Starting at the top left hand corner, rows+ then columns. The endianness of data values will be as per host cpu.
From: Nick Dyer <hidden> Date: 2015-12-02 20:53:41
Retrieve refs data from the T37 diagnostic data object and expose it via
a binary attribute in debugfs.
Signed-off-by: Nick Dyer <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 212 +++++++++++++++++++++++++++++++
1 file changed, 212 insertions(+)
@@ -205,6 +217,20 @@ struct mxt_object {u8num_report_ids;}__packed;+#ifdef CONFIG_DEBUG_FS+structmxt_dbg{+u16t37_address;+u16diag_cmd_address;+structt37_debug*t37_buf;+u16*debug_buf;+unsignedintt37_pages;+unsignedintt37_nodes;++structdentry*debugfs_dir;+structdentry*deltas_file;+};+#endif+/* Each client has this additional data */structmxt_data{structi2c_client*client;
@@ -2043,6 +2070,188 @@ recheck:return0;}+#ifdef CONFIG_DEBUG_FS+staticu16mxt_get_debug_value(structmxt_data*data,unsignedintx,+unsignedinty)+{+structmxt_dbg*dbg=&data->dbg;+unsignedintofs,page;++ofs=(y+(x*(data->info.matrix_ysize)))*sizeof(u16);+page=ofs/MXT_DIAGNOSTIC_SIZE;+ofs%=MXT_DIAGNOSTIC_SIZE;++returnget_unaligned_le16(&dbg->t37_buf[page].data[ofs]);+}++staticvoidmxt_convert_debug_pages(structmxt_data*data)+{+structmxt_dbg*dbg=&data->dbg;+unsignedintx=0;+unsignedinty=0;+unsignedinti;++for(i=0;i<dbg->t37_nodes;i++){+dbg->debug_buf[i]=mxt_get_debug_value(data,x,y);++/* Next value */+if(++x>=data->info.matrix_xsize){+x=0;+y++;+}+}+}++staticintmxt_open_deltas(structinode*inode,structfile*file)+{+structmxt_data*data=inode->i_private;+structmxt_dbg*dbg=&data->dbg;+intretries=0;+intpage;+intret;+u8mode=MXT_DIAGNOSTIC_DELTAS;+u8cmd=mode;+structt37_debug*p;++for(page=0;page<dbg->t37_pages;page++){+p=dbg->t37_buf+page;++ret=mxt_write_reg(data->client,dbg->diag_cmd_address,+cmd);+if(ret)+returnret;++retries=0;++/* Poll until command is actioned */+msleep(20);+wait_cmd:+/* Read first two bytes only */+ret=__mxt_read_reg(data->client,dbg->t37_address,+2,p);+if(ret)+returnret;++if((p->mode!=mode)||(p->page!=page)){+if(retries++>100)+return-EINVAL;++msleep(20);+gotowait_cmd;+}++/* Read entire T37 page */+ret=__mxt_read_reg(data->client,dbg->t37_address,+sizeof(structt37_debug),p);+if(ret)+returnret;++dev_dbg(&data->client->dev,"%s page:%d retries:%d\n",+__func__,page,retries);++/* For remaining pages, write PAGEUP rather than mode */+cmd=MXT_DIAGNOSTIC_PAGEUP;+}++mxt_convert_debug_pages(data);+file->private_data=data;++return0;+}++staticssize_tmxt_read_deltas(structfile*file,char__user*ubuf,+size_tcount,loff_t*offp)+{+structmxt_data*data=file->private_data;++returnsimple_read_from_buffer(ubuf,count,offp,+data->dbg.debug_buf,+data->dbg.t37_nodes*sizeof(u16));+}++staticconststructfile_operationsatmel_mxt_deltas_fops={+.open=mxt_open_deltas,+.read=mxt_read_deltas,+};++staticvoidmxt_debugfs_remove(structmxt_data*data)+{+debugfs_remove_recursive(data->dbg.debugfs_dir);+}++staticvoidmxt_debugfs_init(structmxt_data*data)+{+structmxt_dbg*dbg=&data->dbg;+structmxt_object*object;+chardirname[50];++object=mxt_get_object(data,MXT_GEN_COMMAND_T6);+if(!object)+return;++dbg->diag_cmd_address=object->start_address+MXT_COMMAND_DIAGNOSTIC;++object=mxt_get_object(data,MXT_DEBUG_DIAGNOSTIC_T37);+if(!object)+return;++if(mxt_obj_size(object)!=sizeof(structt37_debug)){+dev_warn(&data->client->dev,"Bad T37 size");+return;+}++dbg->t37_address=object->start_address;++snprintf(dirname,sizeof(dirname),"heatmap-%s-%s",+dev_driver_string(&data->client->dev),+dev_name(&data->client->dev));++dbg->debugfs_dir=debugfs_create_dir(dirname,NULL);+if(!dbg->debugfs_dir){+dev_err(&data->client->dev,"Error creating debugfs dir\n");+return;+}++/* Calculate size of data and allocate buffer */+dbg->t37_nodes=data->info.matrix_xsize*data->info.matrix_ysize;+dbg->t37_pages=dbg->t37_nodes*sizeof(u16)+/sizeof(dbg->t37_buf->data)+1;+dbg->debug_buf=devm_kzalloc(&data->client->dev,+dbg->t37_nodes*sizeof(u16),+GFP_KERNEL);+if(!dbg->debug_buf)+gotoerror;++dbg->t37_buf=devm_kzalloc(&data->client->dev,+sizeof(structt37_debug)*dbg->t37_pages,+GFP_KERNEL);+if(!dbg->t37_buf)+gotoerror;++dbg->deltas_file=debugfs_create_file("deltas",S_IRUGO,+dbg->debugfs_dir,data,+&atmel_mxt_deltas_fops);+if(!dbg->deltas_file)+gotoerror;++dbg->deltas_file->d_inode->i_size=dbg->t37_nodes*sizeof(u16);++return;++error:+dev_err(&data->client->dev,"Error creating debugfs entry\n");+mxt_debugfs_remove(data);+}+#else+staticinlinevoidmxt_debugfs_remove(structmxt_data*data)+{+}++staticinlinevoidmxt_debugfs_init(structmxt_data*data)+{+}+#endif /* CONFIG_DEBUG_FS */+staticintmxt_configure_objects(structmxt_data*data,conststructfirmware*cfg){
From: Nick Dyer <hidden> Date: 2015-12-02 20:53:43
There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.
Signed-off-by: Nick Dyer <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 78 ++++++++++++++++++++++++--------
1 file changed, 60 insertions(+), 18 deletions(-)
From: Nick Dyer <hidden> Date: 2015-12-17 18:38:15
On 02/12/15 20:42, Nick Dyer wrote:
This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).
The intention is to open-source a utility which can read/display this data, this
should be available very shortly.
Hi Nick,
On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
On 02/12/15 20:42, Nick Dyer wrote:
quoted
This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).
The intention is to open-source a utility which can read/display this data, this
should be available very shortly.
Thank you for sharing the utility and the recording, but it seems that
there is a desire to get access to the heat maps not only for
validation, but also for certain processing purposes, and so I do not
think that we should try to standardize on debugfs as the interface, but
rather look for something that allows better performance.
I wonder if the interface should look similar to the V4L2 capture API
where application opens a character device, uses several ioctls to query
its capabilities/set up capture parameters (i.e reference or deltas),
select()s file descriptor for reading and then uses mmap() to access the
captured heat map.
I've CCed a few people who might be interested in this topic.
Thanks.
--
Dmitry
From: Benjamin Tissoires <hidden> Date: 2016-01-12 08:10:52
On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
Hi Nick,
On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
quoted
On 02/12/15 20:42, Nick Dyer wrote:
quoted
This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).
The intention is to open-source a utility which can read/display this data, this
should be available very shortly.
Thank you for sharing the utility and the recording, but it seems that
there is a desire to get access to the heat maps not only for
validation, but also for certain processing purposes, and so I do not
think that we should try to standardize on debugfs as the interface, but
rather look for something that allows better performance.
I wonder if the interface should look similar to the V4L2 capture API
where application opens a character device, uses several ioctls to query
its capabilities/set up capture parameters (i.e reference or deltas),
select()s file descriptor for reading and then uses mmap() to access the
captured heat map.
I've CCed a few people who might be interested in this topic.
I've added Florian, who worked on the driver for the Surface 2.0 which
does exactly that, exports the heat map through V4L2.
See drivers/input/touchscreen/sur40.c for his driver.
Cheers,
Benjamin
From: Nick Dyer <hidden> Date: 2016-01-13 17:21:17
Hi Ben/Dmitry-
On 12/01/16 08:10, Benjamin Tissoires wrote:
On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
quoted
On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
quoted
quoted
This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).
The intention is to open-source a utility which can read/display this data, this
should be available very shortly.
Thank you for sharing the utility and the recording, but it seems that
there is a desire to get access to the heat maps not only for
validation, but also for certain processing purposes, and so I do not
think that we should try to standardize on debugfs as the interface, but
rather look for something that allows better performance.
I wonder if the interface should look similar to the V4L2 capture API
where application opens a character device, uses several ioctls to query
its capabilities/set up capture parameters (i.e reference or deltas),
select()s file descriptor for reading and then uses mmap() to access the
captured heat map.
I've CCed a few people who might be interested in this topic.
I've added Florian, who worked on the driver for the Surface 2.0 which
does exactly that, exports the heat map through V4L2.
See drivers/input/touchscreen/sur40.c for his driver.
That's very interesting, thanks. I do think there is a difference in intent
between the debugfs interface we are proposing and the video interface.
The devices we want to support are I2C based and the frame rate is low:
typically less than 10 fps with 1386 nodes, as an example. So performance
is not critical and doing meaningful processing is not really feasible.
The use cases we want to support are diagnostic, for instance tuning and
analysing touch sensor manufacturing defects. It's useful in this context
to be able to interrogate the device using the command line or shell scripts.
Nick
On Tue, Jan 12, 2016 at 09:10:41AM +0100, Benjamin Tissoires wrote:
On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
quoted
Hi Nick,
On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
quoted
On 02/12/15 20:42, Nick Dyer wrote:
quoted
This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).
The intention is to open-source a utility which can read/display this data, this
should be available very shortly.
Thank you for sharing the utility and the recording, but it seems that
there is a desire to get access to the heat maps not only for
validation, but also for certain processing purposes, and so I do not
think that we should try to standardize on debugfs as the interface, but
rather look for something that allows better performance.
I wonder if the interface should look similar to the V4L2 capture API
where application opens a character device, uses several ioctls to query
its capabilities/set up capture parameters (i.e reference or deltas),
select()s file descriptor for reading and then uses mmap() to access the
captured heat map.
I've CCed a few people who might be interested in this topic.
I've added Florian, who worked on the driver for the Surface 2.0 which
does exactly that, exports the heat map through V4L2.
See drivers/input/touchscreen/sur40.c for his driver.
I am not sure if it best to settle on using V4L2 API or creating smaller
API that behaves similarly to V4L2 API though. One of the main
differences is that we only need capture here.
Thanks.
--
Dmitry
On Wed, Jan 13, 2016 at 05:20:57PM +0000, Nick Dyer wrote:
Hi Ben/Dmitry-
On 12/01/16 08:10, Benjamin Tissoires wrote:
quoted
On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
quoted
On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
quoted
quoted
This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).
The intention is to open-source a utility which can read/display this data, this
should be available very shortly.
Thank you for sharing the utility and the recording, but it seems that
there is a desire to get access to the heat maps not only for
validation, but also for certain processing purposes, and so I do not
think that we should try to standardize on debugfs as the interface, but
rather look for something that allows better performance.
I wonder if the interface should look similar to the V4L2 capture API
where application opens a character device, uses several ioctls to query
its capabilities/set up capture parameters (i.e reference or deltas),
select()s file descriptor for reading and then uses mmap() to access the
captured heat map.
I've CCed a few people who might be interested in this topic.
I've added Florian, who worked on the driver for the Surface 2.0 which
does exactly that, exports the heat map through V4L2.
See drivers/input/touchscreen/sur40.c for his driver.
That's very interesting, thanks. I do think there is a difference in intent
between the debugfs interface we are proposing and the video interface.
The devices we want to support are I2C based and the frame rate is low:
typically less than 10 fps with 1386 nodes, as an example. So performance
is not critical and doing meaningful processing is not really feasible.
The use cases we want to support are diagnostic, for instance tuning and
analysing touch sensor manufacturing defects. It's useful in this context
to be able to interrogate the device using the command line or shell scripts.
I understand that the current controller and firmware you are working on
is not suitable for actual processing and the data rate is only useful
for diagnostic. This does not mean however that we can't use the same
high-speed interface for both diagnostic and processing, if such
interface is available. And given that there is desire to do some of the
host-side processing I'd prefer to standardize on interface that is
suitable for both instead of stuffing driver-specific bits into debugfs.
Thanks.
--
Dmitry
From: Nick Dyer <hidden> Date: 2016-03-10 14:08:48
On Wed, Jan 13, 2016 at 05:20:57PM +0000, Nick Dyer wrote:
quoted
The devices we want to support are I2C based and the frame rate is low:
typically less than 10 fps with 1386 nodes, as an example. So performance
is not critical and doing meaningful processing is not really feasible.
The use cases we want to support are diagnostic, for instance tuning and
analysing touch sensor manufacturing defects. It's useful in this context
to be able to interrogate the device using the command line or shell scripts.
I understand that the current controller and firmware you are working on
is not suitable for actual processing and the data rate is only useful
for diagnostic. This does not mean however that we can't use the same
high-speed interface for both diagnostic and processing, if such
interface is available. And given that there is desire to do some of the
host-side processing I'd prefer to standardize on interface that is
suitable for both instead of stuffing driver-specific bits into debugfs.
Hi Dmitry-
We've begun to look at re-implementing this using V4L2.
One additional thing that I wanted to raise in relation to this feature.
The diagnostic data available from these chips is not limited to raw
capacitance value data for each node on the touch matrix. Examples might be:
* One reading per X/Y line, eg a noise measurement
* Single values, for example a frame counter
* Raw pressure/button data from an active stylus
It's unclear exactly how we are going to expose this kind of information at
the moment.
One option seems to be the multi-plane support in V4L2, or defining a
custom struct for embedding this data in the V4L2 frame.
But the number of differences between chip versions means that we might
have to settle for having some way to get the raw data stream out and
forward it to some user space tool which is able to decode.
Nick