From: Daniel Kurtz <hidden> Date: 2012-06-18 04:13:59
This patchset cleans up the atmel_mxt_ts touchscreen driver.
These patches mostly contain non-controversial changes that were previously
reviewed in previous versions of the patchset. However, based on feedback from
Henrik, the individual patches are now all much smaller and easier to review.
They were tested using an MXT224E, and apply cleanly to input/next.
Whenever these patches (or their descendants) are accepted, there is a larger
patchset full of additional features and more significant changes that will
follow.
Daniel Kurtz (22):
Input: atmel_mxt_ts - set phys to i2c client adapter name
Input: atmel_mxt_ts - use client name for irq
Input: atmel_mxt_ts - detect OOM when creating mt slots
Input: atmel_mxt_ts - warn if sysfs could not be created
Input: atmel_mxt_ts - don't read T5 when dumping objects
Input: atmel_mxt_ts - use scnprintf for object sysfs entry
Input: atmel_mxt_ts - optimize reading objects in object sysfs entry
Input: atmel_mxt_ts - print less overhead when dumping objects
Input: atmel_mxt_ts - print all instances when dumping objects
Input: atmel_mxt_ts - return errors from i2c layer
Input: atmel_mxt_ts - add variable length __mxt_write_reg
Input: atmel_mxt_ts - optimize writing of object table entries
Input: atmel_mxt_ts - read ID information block in one i2c
transaction
Input: atmel_mxt_ts - don't re-read matrix after applying pdata
Input: atmel_mxt_ts - update driver ID info logging
Input: atmel_mxt_ts - add sysfs entries to read fw and hw version
Input: atmel_mxt_ts - simplify event reporting
Input: atmel_mxt_ts - add detail to touchevent debug message
Input: atmel_mxt_ts - cache T9 reportid range when reading object
table
Input: atmel_mxt_ts - use T9 reportid range to init number of mt
slots
Input: atmel_mxt_ts - send all MT-B slots in one input report
Input: atmel_mxt_ts - parse T6 reports
drivers/input/touchscreen/atmel_mxt_ts.c | 449 ++++++++++++++----------------
1 files changed, 212 insertions(+), 237 deletions(-)
--
1.7.7.3
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:08:50
Hopefully this new code path will never be used, but better safe than
sorry...
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
@@ -1132,7 +1132,9 @@ static int __devinit mxt_probe(struct i2c_client *client,0,255,0,0);/* For multi touch */-input_mt_init_slots(input_dev,MXT_MAX_FINGER);+error=input_mt_init_slots(input_dev,MXT_MAX_FINGER);+if(error)+gotoerr_free_mem;input_set_abs_params(input_dev,ABS_MT_TOUCH_MAJOR,0,MXT_MAX_AREA,0,0);input_set_abs_params(input_dev,ABS_MT_POSITION_X,
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:08:53
T5 is the message processor object. Reading it will only have two
outcomes, neither of which is particularly useful:
1) the message count decrements, and a valid message will be lost
2) an invalid message will be read (reportid == 0xff)
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:09:12
Streamline interrupt processing by caching the T9 reportid range when
first reading the object table.
In the process, refactor reading the object descriptor table.
First, since the object_table entries are now exactly the same layout
in device memory and in the driver, allocate an appropriately sized
array and fetch the entire table directly into it in a single i2c
transaction. Since a 6 byte table object requires 10 bytes to read,
doing this dramatically reduces overhead.
Note: The cached T9 reportid's are initialized to 0, which is an invalid
reportid. Thus, the checks in the interrupt handler will always fail for
devices that do not support the T9 object. Therefore, after doing a
firmware update, the old object table is destroyed and all cached object
values are reset to 0, before reading the new object table, in case
the new firmware does not have the old objects.
This patch tested on an MXT224E.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 80 +++++++++++++++++-------------
1 files changed, 45 insertions(+), 35 deletions(-)
@@ -227,13 +227,10 @@ struct mxt_info {structmxt_object{u8type;u16start_address;-u8size;-u8instances;+u8size;/* Size of each instance - 1 */+u8instances;/* Number of instances - 1 */u8num_report_ids;--/* to map object and message */-u8max_reportid;-};+}__packed;structmxt_message{u8reportid;
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:09:14
The matrix x/y size in the Info ID Block represents the number of x/y
trace lines on the device. There is no need to re-read them after
applying pdata config, since pdata only configures the object table
etnries. The matrix size read from the ID can only be updated by a
firmware update.
As a side affect, to squash a compiler warning, remove the 1-byte limited
mxt_read_reg() since it no longer has any callers.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:09:19
Read each object in a single i2c transaction instead of byte-by-byte
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 35 ++++++++++++-----------------
1 files changed, 15 insertions(+), 20 deletions(-)
@@ -478,20 +478,6 @@ static int mxt_read_message(struct mxt_data *data,sizeof(structmxt_message),message);}-staticintmxt_read_object(structmxt_data*data,-u8type,u8offset,u8*val)-{-structmxt_object*object;-u16reg;--object=mxt_get_object(data,type);-if(!object)-return-EINVAL;--reg=object->start_address;-return__mxt_read_reg(data->client,reg+offset,1,val);-}-staticintmxt_write_object(structmxt_data*data,u8type,u8offset,u8val){
@@ -899,7 +885,14 @@ static ssize_t mxt_object_show(struct device *dev,inti,j;interror;u8val;+u8*obuf;++/* Pre-allocate buffer large enough to hold max sized object. */+obuf=kmalloc(256,GFP_KERNEL);+if(!obuf)+return-ENOMEM;+error=0;for(i=0;i<data->info.object_num;i++){object=data->object_table+i;
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:09:23
Each interrupt contains information for all contacts with changing
properties. Process all of this information at once, and send it all in a
a single input report (ie input events ending in EV_SYN/SYN_REPORT).
This patch was tested using an MXT224E.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:09:26
For objects with multiple instances, dump them all, prepending each with
its "Instance #".
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:09:29
This allows userspace to more easily distinguish which bus a particular
atmel_mxt_ts device is attached to.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:09:32
The i2c bus requires 4 bytes to do a 1-byte write
(1 byte i2c address + 2 byte offset + 1 byte data).
By taking a length with writes, the driver can amortize transaction
overhead by performing larger transactions where appropriate.
This patch just sets up the new API. Later patches refactor writes
to take advantage of the larger transactions.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 22 +++++++++++++++++-----
1 files changed, 17 insertions(+), 5 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:11:06
Instead of carrying around per-finger state in the driver instance, just
report each finger as it arrives to the input layer, and let the input
layer (evdev) hold the event state (which it does anyway).
Note: this driver does not really do MT-B properly. Each input report
(a group of input events followed by a SYN_REPORT) only contains data for
a single contact. When multiple fingers are present on a device, each is
properly reported in its own MT_SLOT. However, there is only ever one
MT_SLOT per SYN_REPORT. This is fixed in a subsequent patch.
This patch was tested with an mXT224E.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 89 ++++-------------------------
1 files changed, 13 insertions(+), 76 deletions(-)
@@ -239,14 +239,6 @@ struct mxt_message {u8message[7];};-structmxt_finger{-intstatus;-intx;-inty;-intarea;-intpressure;-};-/* Each client has this additional data */structmxt_data{structi2c_client*client;
@@ -512,75 +503,17 @@ static int mxt_write_object(struct mxt_data *data,returnmxt_write_reg(data->client,reg+offset,val);}-staticvoidmxt_input_report(structmxt_data*data,intsingle_id)-{-structmxt_finger*finger=data->finger;-structinput_dev*input_dev=data->input_dev;-intstatus=finger[single_id].status;-intfinger_num=0;-intid;--for(id=0;id<MXT_MAX_FINGER;id++){-if(!finger[id].status)-continue;--input_mt_slot(input_dev,id);-input_mt_report_slot_state(input_dev,MT_TOOL_FINGER,-finger[id].status!=MXT_RELEASE);--if(finger[id].status!=MXT_RELEASE){-finger_num++;-input_report_abs(input_dev,ABS_MT_TOUCH_MAJOR,-finger[id].area);-input_report_abs(input_dev,ABS_MT_POSITION_X,-finger[id].x);-input_report_abs(input_dev,ABS_MT_POSITION_Y,-finger[id].y);-input_report_abs(input_dev,ABS_MT_PRESSURE,-finger[id].pressure);-}else{-finger[id].status=0;-}-}--input_report_key(input_dev,BTN_TOUCH,finger_num>0);--if(status!=MXT_RELEASE){-input_report_abs(input_dev,ABS_X,finger[single_id].x);-input_report_abs(input_dev,ABS_Y,finger[single_id].y);-input_report_abs(input_dev,-ABS_PRESSURE,finger[single_id].pressure);-}--input_sync(input_dev);-}-staticvoidmxt_input_touchevent(structmxt_data*data,structmxt_message*message,intid){-structmxt_finger*finger=data->finger;structdevice*dev=&data->client->dev;u8status=message->message[0];+structinput_dev*input_dev=data->input_dev;intx;inty;intarea;intpressure;-/* Check the touch is present on the screen */-if(!(status&MXT_DETECT)){-if(status&MXT_RELEASE){-dev_dbg(dev,"[%d] released\n",id);--finger[id].status=MXT_RELEASE;-mxt_input_report(data,id);-}-return;-}--/* Check only AMP detection */-if(!(status&(MXT_PRESS|MXT_MOVE)))-return;-x=(message->message[1]<<4)|((message->message[3]>>4)&0xf);y=(message->message[2]<<4)|((message->message[3]&0xf));if(data->max_x<1024)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:11:09
The normal messages sent after boot or NVRAM update are T6 reports,
containing a status, and the config memory checksum. Parse them and dump
a useful info message.
This patch tested on an MXT224E.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:12:13
The i2c layer can report a variety of errors, including -ENXIO for an i2c
NAK. Instead of treating them all as -EIO, pass the actual i2c layer
error up to the caller.
However, still report as -EIO the unlikely case that a transaction was
partially completed, and no error message was returned from i2c_*().
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 28 ++++++++++++++++++++--------
1 files changed, 20 insertions(+), 8 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:12:16
Conserve limited (PAGE_SIZE) sysfs output buffer space by only showing
readable objects and not printing the object's index, which is not useful
to userspace.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:12:17
Make firmware and hardware version strings available to userspace.
This is useful, for example, to allow a userspace program to implement
a firwmare update policy.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
@@ -863,6 +863,26 @@ static void mxt_calc_resolution(struct mxt_data *data)}}+/* Firmware Version is returned as Major.Minor.Build */+staticssize_tmxt_fw_version_show(structdevice*dev,+structdevice_attribute*attr,char*buf)+{+structmxt_data*data=dev_get_drvdata(dev);+structmxt_info*info=&data->info;+returnscnprintf(buf,PAGE_SIZE,"%u.%u.%02X\n",+info->version>>4,info->version&0xf,info->build);+}++/* Hardware Version is returned as FamilyID.VariantID */+staticssize_tmxt_hw_version_show(structdevice*dev,+structdevice_attribute*attr,char*buf)+{+structmxt_data*data=dev_get_drvdata(dev);+structmxt_info*info=&data->info;+returnscnprintf(buf,PAGE_SIZE,"%u.%u\n",+info->family_id,info->variant_id);+}+staticssize_tmxt_object_show(structdevice*dev,structdevice_attribute*attr,char*buf){
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:12:20
Reading the whole info block in one i2c transaction speeds up driver
probe significantly, especially on slower i2c busses.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 26 +++-----------------------
1 files changed, 3 insertions(+), 23 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:13:30
Print unsigned values as '%u'.
Also, parse and print the firmware version in its canonical format, as
suggested by Nick Dyer.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:13:32
Using scnprintf() is a cleaner way to ensure that we don't overwrite the
PAGE_SIZE sysfs output buffer.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 16 ++++------------
1 files changed, 4 insertions(+), 12 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:14:01
If sysfs entry creation fails, the driver is still usable, so don't
just abort probe. Just warn and continue.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:14:04
The atmel_mxt_ts driver can support multiple devices simultaneously.
Use the i2c_client name instead of the driver name when requesting an
interrupt to make the different interrupts distinguishable in
/proc/interrupts and top.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-18 04:15:06
Atmel mxt devices can report one finger for each T9 reportid.
Therefore, this range can be used to report the max number of MT-B slots
to userspace instead of assuming a fixed 10.
Note that mxt_initialized() must complete early, since the input_dev
properties now depend on values in the object table.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
@@ -1056,6 +1054,7 @@ static int __devinit mxt_probe(struct i2c_client *client,structmxt_data*data;structinput_dev*input_dev;interror;+unsignedintnum_mt_slots;if(!pdata)return-EINVAL;
@@ -1082,6 +1081,10 @@ static int __devinit mxt_probe(struct i2c_client *client,mxt_calc_resolution(data);+error=mxt_initialize(data);+if(error)+gotoerr_free_object;+__set_bit(EV_ABS,input_dev->evbit);__set_bit(EV_KEY,input_dev->evbit);__set_bit(BTN_TOUCH,input_dev->keybit);
@@ -1095,9 +1098,10 @@ static int __devinit mxt_probe(struct i2c_client *client,0,255,0,0);/* For multi touch */-error=input_mt_init_slots(input_dev,MXT_MAX_FINGER);+num_mt_slots=data->T9_reportid_max-data->T9_reportid_min+1;+error=input_mt_init_slots(input_dev,num_mt_slots);if(error)-gotoerr_free_mem;+gotoerr_free_object;input_set_abs_params(input_dev,ABS_MT_TOUCH_MAJOR,0,MXT_MAX_AREA,0,0);input_set_abs_params(input_dev,ABS_MT_POSITION_X,
@@ -1110,10 +1114,6 @@ static int __devinit mxt_probe(struct i2c_client *client,input_set_drvdata(input_dev,data);i2c_set_clientdata(client,data);-error=mxt_initialize(data);-if(error)-gotoerr_free_object;-error=request_threaded_irq(client->irq,NULL,mxt_interrupt,pdata->irqflags,client->name,data);if(error){
From: Nick Dyer <hidden> Date: 2012-06-18 15:09:57
Daniel Kurtz wrote:
The normal messages sent after boot or NVRAM update are T6 reports,
containing a status, and the config memory checksum. Parse them and dump
a useful info message.
This can cause a lot of dmesg output - for instance you get 2 messages per
calibration, and the chip can trigger them itself if noise suppression or
anti-touch calibration are enabled. So perhaps dev_dbg()?
--
Nick Dyer
Software Engineer, ITDev Ltd
From: Nick Dyer <hidden> Date: 2012-06-18 15:11:23
Daniel Kurtz wrote:
The matrix x/y size in the Info ID Block represents the number of x/y
trace lines on the device. There is no need to re-read them after
applying pdata config, since pdata only configures the object table
etnries. The matrix size read from the ID can only be updated by a
firmware update.
This isn't correct. For example, mXT224 can be configured as 16x14, 17x13,
18x12, etc. This only takes effect when the chip is reset, which is why it
is necessary to re-read them after applying the config.
cheers
--
Nick Dyer
Software Engineer, ITDev Ltd
Hardware and Software Development Consultancy
Website: http://www.itdev.co.uk
From: Daniel Kurtz <hidden> Date: 2012-06-18 15:28:25
On Mon, Jun 18, 2012 at 11:03 PM, Nick Dyer [off-list ref] wrote:
Daniel Kurtz wrote:
quoted
The matrix x/y size in the Info ID Block represents the number of x/y
trace lines on the device. There is no need to re-read them after
applying pdata config, since pdata only configures the object table
etnries. The matrix size read from the ID can only be updated by a
firmware update.
This isn't correct. For example, mXT224 can be configured as 16x14, 17x13,
18x12, etc. This only takes effect when the chip is reset, which is why it
is necessary to re-read them after applying the config.
Ah, so is that what T46.1 (Mode) does? I hadn't played with that yet.
Ok, I'll move this patch into the next series which cleans up all of
the configuration stuff.
-Dan
cheers
--
Nick Dyer
Software Engineer, ITDev Ltd
Hardware and Software Development Consultancy
Website: http://www.itdev.co.uk
From: Daniel Kurtz <hidden> Date: 2012-06-18 15:30:22
On Mon, Jun 18, 2012 at 11:09 PM, Nick Dyer [off-list ref] wrote:
Daniel Kurtz wrote:
quoted
The normal messages sent after boot or NVRAM update are T6 reports,
containing a status, and the config memory checksum. Parse them and dump
a useful info message.
This can cause a lot of dmesg output - for instance you get 2 messages per
calibration, and the chip can trigger them itself if noise suppression or
anti-touch calibration are enabled. So perhaps dev_dbg()?
Sounds good to me.
--
Nick Dyer
Software Engineer, ITDev Ltd
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 18, 2012 at 11:03 AM, Nick Dyer [off-list ref] wrote:
Daniel Kurtz wrote:
quoted
The matrix x/y size in the Info ID Block represents the number of x/y
trace lines on the device. There is no need to re-read them after
applying pdata config, since pdata only configures the object table
etnries. The matrix size read from the ID can only be updated by a
firmware update.
This isn't correct. For example, mXT224 can be configured as 16x14, 17x13,
18x12, etc. This only takes effect when the chip is reset, which is why it
is necessary to re-read them after applying the config.
so look at structure mxt_info
struct mxt_info {
u8 family_id;
u8 variant_id;
u8 version;
u8 build;
u8 matrix_xsize;
u8 matrix_ysize;
u8 object_num;
};
I think it is meant to be corresponding to Information Block of the
device, of which
the matrix_xsize and matrix_ysize mean "The size of the matrix the
device supports",
which should be fixed for a certain chip.
The configurable matrix size is in T9 XSIZE/YSIZE, which, if ever
needed to be read back,
probably read back into something other than mxt_info struct.
cheers
--
Nick Dyer
Software Engineer, ITDev Ltd
Hardware and Software Development Consultancy
Website: http://www.itdev.co.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Nick Dyer <hidden> Date: 2012-06-19 10:26:10
Yufeng Shen wrote:
On Mon, Jun 18, 2012 at 11:03 AM, Nick Dyer [off-list ref] wrote:
quoted
Daniel Kurtz wrote:
quoted
The matrix x/y size in the Info ID Block represents the number of x/y
trace lines on the device. There is no need to re-read them after
applying pdata config, since pdata only configures the object table
etnries. The matrix size read from the ID can only be updated by a
firmware update.
This isn't correct. For example, mXT224 can be configured as 16x14, 17x13,
18x12, etc. This only takes effect when the chip is reset, which is why it
is necessary to re-read them after applying the config.
so look at structure mxt_info
struct mxt_info {
u8 family_id;
u8 variant_id;
u8 version;
u8 build;
u8 matrix_xsize;
u8 matrix_ysize;
u8 object_num;
};
I think it is meant to be corresponding to Information Block of the
device, of which
the matrix_xsize and matrix_ysize mean "The size of the matrix the
device supports",
which should be fixed for a certain chip.
As I said, it's not fixed, there is a mode setting (T28 byte 2) which
alters the matrix size. This is documented in the protocol guide, if you
have it.
You can also verify this if you want: change mode setting, backup, reset,
and read the information block, you'll see the matrix size changes. I've
just checked that myself on an mXT224.
I also asked the guys at Atmel that I work with, and they confirm that this
behaviour is as designed.
The configurable matrix size is in T9 XSIZE/YSIZE, which, if ever
needed to be read back,
probably read back into something other than mxt_info struct.
The position of the touchscreen within the matrix is a separate
configurable setting, you're confusing the two.
cheers
--
Nick Dyer
Software Engineer, ITDev Ltd
Hardware and Software Development Consultancy
Website: http://www.itdev.co.uk
On Tue, Jun 19, 2012 at 6:26 AM, Nick Dyer [off-list ref] wrote:
Yufeng Shen wrote:
quoted
On Mon, Jun 18, 2012 at 11:03 AM, Nick Dyer [off-list ref] wrote:
quoted
Daniel Kurtz wrote:
quoted
The matrix x/y size in the Info ID Block represents the number of x/y
trace lines on the device. There is no need to re-read them after
applying pdata config, since pdata only configures the object table
etnries. The matrix size read from the ID can only be updated by a
firmware update.
This isn't correct. For example, mXT224 can be configured as 16x14, 17x13,
18x12, etc. This only takes effect when the chip is reset, which is why it
is necessary to re-read them after applying the config.
so look at structure mxt_info
struct mxt_info {
u8 family_id;
u8 variant_id;
u8 version;
u8 build;
u8 matrix_xsize;
u8 matrix_ysize;
u8 object_num;
};
I think it is meant to be corresponding to Information Block of the
device, of which
the matrix_xsize and matrix_ysize mean "The size of the matrix the
device supports",
which should be fixed for a certain chip.
As I said, it's not fixed, there is a mode setting (T28 byte 2) which
alters the matrix size. This is documented in the protocol guide, if you
have it.
You can also verify this if you want: change mode setting, backup, reset,
and read the information block, you'll see the matrix size changes. I've
just checked that myself on an mXT224.
Ah, you are correct. I was looking at the wrong protocol guide. mXT224(E) does
have the mode setting option.
I also asked the guys at Atmel that I work with, and they confirm that this
behaviour is as designed.
quoted
The configurable matrix size is in T9 XSIZE/YSIZE, which, if ever
needed to be read back,
probably read back into something other than mxt_info struct.
The position of the touchscreen within the matrix is a separate
configurable setting, you're confusing the two.
cheers
--
Nick Dyer
Software Engineer, ITDev Ltd
Hardware and Software Development Consultancy
Website: http://www.itdev.co.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Henrik Rydberg <hidden> Date: 2012-06-20 17:35:54
Hi Daniel,
This patchset cleans up the atmel_mxt_ts touchscreen driver.
These patches mostly contain non-controversial changes that were previously
reviewed in previous versions of the patchset.
I have queued patches 1-10 locally, review of the others will follow (eventually).
I will push this set to next in a week or so unless Dmitry wants to takes it.
Thanks,
Henrik
On Mon, Jun 18, 2012 at 12:08:21PM +0800, Daniel Kurtz wrote:
quoted hunk
This allows userspace to more easily distinguish which bus a particular
atmel_mxt_ts device is attached to.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Henrik Rydberg <hidden> Date: 2012-06-25 08:12:54
On Thu, Jun 21, 2012 at 01:41:07AM -0700, Dmitry Torokhov wrote:
On Mon, Jun 18, 2012 at 12:08:21PM +0800, Daniel Kurtz wrote:
quoted
This allows userspace to more easily distinguish which bus a particular
atmel_mxt_ts device is attached to.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Daniel Kurtz <hidden> Date: 2012-06-25 09:59:11
On Mon, Jun 25, 2012 at 4:15 PM, Henrik Rydberg [off-list ref] wrote:
On Thu, Jun 21, 2012 at 01:41:07AM -0700, Dmitry Torokhov wrote:
quoted
On Mon, Jun 18, 2012 at 12:08:21PM +0800, Daniel Kurtz wrote:
quoted
This allows userspace to more easily distinguish which bus a
particular
atmel_mxt_ts device is attached to.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Normally we set phys to 'xxx/input0' nstead of just the adaptor name.
Daniel, will we be seeing another version of this patch?
Yes. Any guidance on "xxx" ? atmel_mxt_ts?
What if there are two devices using the same driver?
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 25, 2012 at 05:58:46PM +0800, Daniel Kurtz wrote:
On Mon, Jun 25, 2012 at 4:15 PM, Henrik Rydberg [off-list ref] wrote:
quoted
On Thu, Jun 21, 2012 at 01:41:07AM -0700, Dmitry Torokhov wrote:
quoted
On Mon, Jun 18, 2012 at 12:08:21PM +0800, Daniel Kurtz wrote:
quoted
This allows userspace to more easily distinguish which bus a
particular
atmel_mxt_ts device is attached to.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Normally we set phys to 'xxx/input0' nstead of just the adaptor name.
Daniel, will we be seeing another version of this patch?
Yes. Any guidance on "xxx" ? atmel_mxt_ts?
What you have before (client->adapter->name) + "/input0" shoudl work
splendidly.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[oops. sorry for duplicate send... resending in plaintext]
Would it more sense to more completely describe the bus type, adapter,
and address in this case, rather than using the client->adapter->name?
Just to give an example from our system, client->adapter->name is
"i915 gmbus panel", so your suggestion would be "i915 gmbus
panel/input0"
How about this instead :
i2c-2-004a/input0
This seems to me more consistent with what is done with USB input
devices, which show a phys field like this :
usb-00:01.2-2.2/input0
Benson
On Mon, Jun 25, 2012 at 6:27 PM, Dmitry Torokhov
[off-list ref] wrote:
On Mon, Jun 25, 2012 at 05:58:46PM +0800, Daniel Kurtz wrote:
quoted
On Mon, Jun 25, 2012 at 4:15 PM, Henrik Rydberg [off-list ref]
wrote:
quoted
On Thu, Jun 21, 2012 at 01:41:07AM -0700, Dmitry Torokhov wrote:
quoted
On Mon, Jun 18, 2012 at 12:08:21PM +0800, Daniel Kurtz wrote:
quoted
This allows userspace to more easily distinguish which bus a
particular
atmel_mxt_ts device is attached to.
Signed-off-by: Daniel Kurtz <redacted>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Normally we set phys to 'xxx/input0' nstead of just the adaptor
name.
Daniel, will we be seeing another version of this patch?
Yes. Any guidance on "xxx" ? atmel_mxt_ts?
What you have before (client->adapter->name) + "/input0" shoudl work
splendidly.
Thanks.
--
Dmitry
--
Benson Leung
Software Engineer, Chrom* OS
bleung@chromium.org
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html