Add information to debugfs to allow a generic utility to retrieve
screen parameters and info.
Signed-off-by: Nick Dyer
---
Documentation/ABI/testing/debugfs-heatmap | 60 +++
drivers/input/touchscreen/atmel_mxt_ts.c | 48 +++--
2 files changed
There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 75 +---
1 file changed, 59 insertions(+), 16 deletions(-)
diff --git a/drivers
The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/input
Both T100 and T9 handle range and orientation in a similar fashion.
Reduce duplication between the two implementations.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 68
1 file changed, 26 insertions(+), 42 deletions(-)
diff --git a
Add support for retrieving a single node of data at high rate.
---
drivers/input/touchscreen/atmel_mxt_ts.c | 60 +---
1 file changed, 55 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
ind
Retrieve refs data from the T37 diagnostic data object and expose it via
a binary attribute in debugfs.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 208 +++
1 file changed, 208 insertions(+)
diff --git a/drivers/input/touchscreen
Add files in debugfs directory with info about the chip and input device.
Signed-off-by: Nick Dyer
---
Documentation/ABI/testing/debugfs-heatmap | 14 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 22 ++
2 files changed, 36 insertions(+)
diff --git a
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
---
drivers/input/touchscreen/atmel_mxt_ts.c | 41
1 file changed, 36 insertions(+), 5 deletions
splay this data has now been released, and you can find it at:
https://github.com/ndyer/heatmap
I've recorded a couple of videos of the utility in action on a Pixel 2:
https://youtu.be/M0VD2gZt8Zk and https://youtu.be/nwDLB4zikzU
Any feedback appreciated.
Best regards
Nick Dyer
--
Invert the diagnostic data to match the orientation of the input device.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers
> On Wed, 2013-09-04 at 13:41 +0300, Andy Shevchenko wrote:
>> There is no need to pass constants via stack. The width may be
>> explicitly
>> specified in the format.
>
> Dmitry, any comments on this?
Hi Andy-
Just to weigh in on the atmel_mxt_ts part - it's made moot by:
http://git.kernel.org/
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
Retrieve refs data from the T37 diagnostic data object and expose it via
a binary attribute in debugfs.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 212 +++
1 file changed, 212 insertions(+)
diff --git a/drivers/input/touchscreen
There are different datatypes available from a maXTouch chip. Add
support to retrieve reference data as well.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 78
1 file changed, 60 insertions(+), 18 deletions(-)
diff --git a/drivers
Add a file in debugfs directory with info about the chip.
Signed-off-by: Nick Dyer
---
Documentation/ABI/testing/debugfs-heatmap | 14 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 22 ++
2 files changed, 36 insertions(+)
diff --git a/Documentation/ABI/testing
Add information to debugfs to allow a generic utility to retrieve
screen parameters and info.
Signed-off-by: Nick Dyer
---
Documentation/ABI/testing/debugfs-heatmap | 60 +++
drivers/input/touchscreen/atmel_mxt_ts.c | 46 ++--
2 files changed
ed 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
--
To unsubscribe
Both T100 and T9 handle range and orientation in a similar fashion.
Reduce duplication between the two implementations.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 68
1 file changed, 26 insertions(+), 42 deletions(-)
diff --git a
The mXT1386 family of chips have a different architecture which splits
the diagnostic data into 3 columns.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/input
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
---
drivers/input/touchscreen/atmel_mxt_ts.c | 41
1 file changed, 36 insertions(+), 5 deletions
Invert the diagnostic data to match the orientation of the input device.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input
On 11/08/15 17:29, Benjamin Tissoires wrote:
>>> Are you able to send me some dmesg output with dyndbg=+pt enabled?
>
> I will do that after lunch if you still need them.
Looks unnecessary given that the calibrate worked.
>> sudo ./mxt-app -d i2c-dev:0-004a --calibrate
>
> Yep, this works with
On 11/08/15 15:24, Nick Dyer wrote:
> On 10/08/15 21:11, Benjamin Tissoires wrote:
>> I am currently running v4.2-rc6, merged with Dmitry's and Jiri's tree.
>> This patch completely kills my touchpad on the Pixel 2. No touch
>> information is sent while the physical
On 10/08/15 21:11, Benjamin Tissoires wrote:
> I am currently running v4.2-rc6, merged with Dmitry's and Jiri's tree.
> This patch completely kills my touchpad on the Pixel 2. No touch
> information is sent while the physical button still emits values. You
> said that you tested it on this laptop t
On 05/08/15 01:02, Dmitry Torokhov wrote:
> Since the T9 code is for compatibility with old Pixel only I do not think
> we should be adding it to device tree binding, at least not at the
> moment. I cut the device tree parsing out and default to deep sleep on
> DT-based systems. Thanks.
That so
On 06/08/15 12:19, Javier Martinez Canillas wrote:
>> In mainline the EV_ABS bit automatically gets set as soon as
>> input_set_abs_params get called.
>>
>> If you're using this patch on an older kernel you should backport
>> 2c9a9cfec04f2c6ed7b4e607cd53ca903b2c4642 as well.
>>
> That's correct.
The CHG/interrupt line is momentarily set (approximately 100 ms) as an
input after power-up or reset for diagnostic purposes. This may cause
spurious interrupts, so disable interrupt handler during this period.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 9
Many of these values are out of date and they aren't used in the driver
- all they do is increase the size of the kernel source.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
---
drivers/input/touchscreen/atmel_mxt_ts.c | 66 +---
1
necessity for a
default IDC file.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index ff48d45..2aa44dc 100644
--- a/drivers/input
Signed-off-by: Nick Dyer
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..d2409bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1915,6 +1915,12 @@ W: http://atmelwlandriver.sourceforge.net/
S: Maintained
F
tch.
best regards
Nick Dyer
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Pan Xinhui
input_dev may be NULL if mxt_initialize_input_device fails. But pm ops is
still available and suspend/resume assume
input_dev is not NULL. To fix this issue, we add a check if (!input_dev).
Signed-off-by: Pan Xinhui
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen
An error in the sysfs init may otherwise interfere with the async return
from the firmware loader
Add guards for sysfs functions
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 2aa44dc..c874008 100644
--- a/drivers/input
configuration is
zero on probe, which would mean that the device never wakes up to execute
commands.
After a config download, the T7 power configuration may have changed so it
is necessary to re-read it.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
---
.../devicetree/bindings
Use function rather than loop, define np to reduce wrapping.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input
Hi Dmitry-
This is similar to something that I've already got in my tree:
https://github.com/ndyer/linux/commit/449643df3c80
https://github.com/ndyer/linux/commit/a520bbbfbdd1
However, my version is based on the earlier Pixel code and allows updating
the config at any point in time by writing to
On 08/04/15 01:26, Dmitry Torokhov wrote:
> This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
> Google Pixel 2 (2015).
Can you point me to any instructions for testing this on the Pixel 2 we
have here?
> While newer version of ACPI standard allow use of device-tree-like
> prop
On 19/01/15 13:08, Dirk Behme wrote:
> we have two questions regarding the atmel_mxt_ts driver:
>
> First, what's the status of your github 'for-dtor' branch [1]? Is this
> subject to change? Or how stable is it? Will it go into mainline, soon?
>
> We've tested the patches in that branch on top o
On 12/01/15 09:50, Dirk Behme wrote:
> Hi Nick,
>
> being new to the atmel_mxt_ts and starting to work with it, we wonder if
> it's really necessary to download the device config [1] at each driver
> start up?
>
> I've been told that technically each device config download does mean the
> configu
Hi Benson-
On 18/12/14 18:49, Benson Leung wrote:
> Dmitry and Chung-Yih have had some discussion about how to handle
> hovering fingers, and I think the direction they wanted to go was to
> use ABS_MT_DISTANCE instead.
>
> http://www.spinics.net/lists/linux-input/msg33950.html
Thanks for flaggi
On 16/12/14 17:46, Javier Martinez Canillas wrote:
> On 12/16/2014 06:07 PM, Nick Dyer wrote:
>> I had been keeping them separate on the basis that we don't want changes to
>> support new T100 features to cause regressions in the old T9 handling. But
>> there is a fair am
On 16/12/14 16:49, Javier Martinez Canillas wrote:
> Awesome, what do you think about the change to have a common input device
> initialization function that I squashed in your original patch?
> mxt_initialize_t100_input_device() and mxt_initialize_t9_input_device()
> are very similar so I think th
On 16/12/14 16:34, Javier Martinez Canillas wrote:
> On 12/16/2014 05:16 PM, Nick Dyer wrote:
>>> Nick Dyer (1):
>>> Input: atmel_mxt_ts - Implement support for T100 touch object
>> I posted an updated version of this patch on 9th December and would prefer
>>
rts
> the former so this series add support for the later.
>
> The series is composed of the following patches:
>
> Nick Dyer (1):
> Input: atmel_mxt_ts - Implement support for T100 touch object
Hi Dmitry-
I posted an updated version of this patch on 9th December and would prefer
Add support for the new T100 object which replaces the previous T9 multitouch
touchscreen object in recent maXTouch devices. T100 provides improved
reporting with selectable auxiliary information, and a type field for
hover/stylus/glove reporting.
Signed-off-by: Nick Dyer
Acked-by: Yufeng Shen
On 21/10/14 13:22, One Thousand Gnomes wrote:
>> If you will have touch processing in a binary blob, you'll also be going
>> to ages "Works with Ubuntu 12.04 on x86_32!" (and nothing else), or
>> "Android 5.1.2 on Tegra Blah (build 78912KT)" (and nothing else).
>
> As well as not going upstream be
to get a
driver accepted. Obviously it's not an input device in the normal sense. Is
it acceptable just to send the raw touch data out via a char device? Is
there another subsystem which is a good match (eg IIO)? Does the protocol
(there is ancillary/control data as well) need to be documented?
cheers
the documentation for the gpio-property.
>
> That patch makes sense, and is a nice description,
> Acked-by: Stephen Warren
Hi Dmitry-
Something went a bit wrong in merging f5940231a - there's a bit of repeated
text that's been introduced.
Signed-off-by: Nick Dyer
---
Docu
On 11/09/14 12:41, Javier Martinez Canillas wrote:
> On 09/11/2014 01:35 PM, Wolfram Sang wrote:
This is a workaround. It would make sense, however, to add it because we
want to support i2c_board_info structures.
>>>
>>> I think it really depends if an IP block can be used on non-DT
On 11/09/14 09:38, Javier Martinez Canillas wrote:
> To expand on what Sjoerd already said and just to be sure everyone is on the
> same page.
>
> The problem is that right now the driver reports the following modalias:
>
> # cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> i2c:maxtouch
>
> bu
From: Stephen Warren
[reworked after comments by Dmitry Torokhov. Move free of input device into
separate function. Only call in paths that require it.]
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions
On 10/09/14 00:49, Dmitry Torokhov wrote:
> On Tue, Sep 09, 2014 at 03:50:49PM +0100, nick.d...@itdev.co.uk wrote:
>> From: Stephen Warren
>>
>> [reworked after comments by Dmitry Torokhov. Move free of input device into
>> separate function. Only call in paths that require it. Move mxt_initialize
From: Nick Dyer
In the case where the CHG/interrupt line mode is not configured correctly,
this warning is output to dmesg output for each interrupt. Downgrade the
message to debug.
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 7 ++-
1 file changed, 6 insertions
. Add guards for sysfs
functions. ]
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 40 ++--
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index
Hi Dmitry/Stephen-
I have tested and reworked the fix for the double free issue in atmel_mxt_ts
that Stephen identified. A lot more entertaining than I thought at first. Also
a minor change to reduce the verbosity of a warning message.
cheers
Nick
--
To unsubscribe from this list: send the line
On 09/09/14 08:52, Sjoerd Simons wrote:
> For i2c devices in OF the modalias exposed to userspace is i2c: type>, for the Maxtouch driver this is i2c:maxtouch.
>
> Add maxtouch to the i2c id table such that userspace can correctly
> load the module for the device and drop the OF table as it's not
>
On 09/09/14 11:21, Javier Martinez Canillas wrote:
> On 09/09/2014 09:52 AM, Sjoerd Simons wrote:
>> For i2c devices in OF the modalias exposed to userspace is i2c:> type>, for the Maxtouch driver this is i2c:maxtouch.
>>
>> Add maxtouch to the i2c id table such that userspace can correctly
>> load
ps://github.com/swarren/linux-tegra/commit/09789801
trackpad@4b {
compatible = "atmel,maxtouch";
reg = <0x4b>;
interrupt-parent = <&gpio>;
interrupts = ;
linux,gpio-keymap = <0 0 0 BTN_LEFT>;
};
This maps BTN_LEFT to the 4th bit of the T19 message. I haven&#x
On 12/08/14 17:41, Stephen Warren wrote:
>> I've reviewed these changes and they look correct to me. Apologies that
>> they slipped through, most of it is bad merging on my part I think.
>>
>> Signed-off-by: Nick Dyer
>
> Don't you mean Acked-by or
rivers/input/touchscreen/atmel_mxt_ts.c: 1211 in mxt_update_cfg()
>
> Signed-off-by: Dmitry Torokhov
I've reviewed these changes and they look correct to me. Apologies that
they slipped through, most of it is bad merging on my part I think.
Signed-off-by: Nick Dyer
--
To unsubscrib
From: Dmitry Torokhov
I think having control flow with 2 goto/labels/flags is quite hard to read,
this version is a bit more readable IMO.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 81 +---
1 file
From: Dmitry Torokhov
Let's split config update code a bit so it is hopefully a bit easier to
read. Also, the firmware update callback should be the entity releasing
firmware blob, not lower layers.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Nick Dyer
---
drivers/input/touchs
Hi Dmitry-
I tested both your patches, here they are rebased on your current tree and
with my signoff.
I need to have a little more of a play with the change to the
input_unregister_device code before putting it it. I want to be sure that all
the possible probe failures do the sensible thing. Hop
py for this to go in if Dmitry will accept it. It does seem to be a
quirk of some platforms that it is necessary, but it's only one line.
Thanks for spending so much time debugging this.
Signed-off-by: Nick Dyer
> ---
>
> This patch was first sent as a part of a two part series
From: Nick Dyer
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index da497db..67ea728 100644
--- a/drivers
From: Stephen Warren
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt_ts.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 03b8571..da497db 100644
--- a/drivers
Hi Dmitry-
It would be good to get these minor fixes applied to atmel_mxt_ts.
regards
Nick Dyer
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/08/14 01:48, Javier Martinez Canillas wrote:
> The Atmel maXTouch driver allows to dynamically define the
> event keycodes set that the device is capable of. This may
> not be evident when reading the DT binding document so add
> an example to make it easier to understand how this works.
>
>
On 07/08/14 01:48, Javier Martinez Canillas wrote:
> The Atmel maXTouch driver assumed that the IRQ type flags will
> always be passed using platform data but this is not true when
> booting using Device Trees. In these setups the interrupt type
> was ignored by the driver when requesting an IRQ.
>
On 29/07/14 17:16, Stephen Warren wrote:
> I then tried updating the firmware. This didn't work at all.
>
> First I tried via mxt-app:
>
>> root@localhost:~# ./obp-utils/mxt-app -d i2c-dev:1-004b --flash
>> 130.1_1.0.170.bin
>> Version:1.16-65-g0a4c
>> Opening firmware file 130.1_1.0.170.bin
>> R
On 29/07/14 01:10, Yufeng Shen wrote:
> T37 (0x25) is DEBUG_DIAGNOSTIC object which the host can read debugging info
> from. It is not useful to have a initial config for it so usually CrOS
> system would just
> don't include configuration for this object.
>
> Nick, I want to confirm with you that
On 29/07/14 00:42, Stephen Warren wrote:
> Anyway, here's the diff between the two config files:
>
>> # diff -u mxt-save-after-t9-83-write.xml 224sl.raw
>> --- mxt-save-after-t9-83-write.xml2014-07-25 19:41:45.0 +
>> +++ 224sl.raw2014-07-28 23:25:49.0 +
>> @@ -1,8 +
On 24/07/14 22:19, Stephen Warren wrote:
>> mxt-app [device] --save fail.xcfg
>
> That command always experiences a timeout error, but still seems to dump
> something out. Is this timeout error an issue? I'm a little hesitant to
> modify the COMMSCONFIG settings until I know load/save are really w
On 23/07/14 22:50, Dmitry Torokhov wrote:
> I think having control flow with 2 goto/labels/flags is quite hard to read,
> this version is a bit more readable IMO.
>
> Signed-off-by: Dmitry Torokhov
Yes, this looks much clearer to me. Although I can't see anything wrong
looking at it, I think I s
On 24/07/14 00:29, Dmitry Torokhov wrote:
> Let's split config update code a bit so it is hopefully a bit easier to
> read. Also, the firmware update callback should be the entity releasing
> firmware blob, not lower layers.
>
> Signed-off-by: Dmitry Torokhov
Thanks, this is obviously sensible.
On 23/07/14 22:36, Stephen Warren wrote:
> Hmm. It looks like the version of this patch that was actually applied
> varies quite a bit from what was posted, in particular in the
> implementation and call site of mxt_parse_dt(). It'd be nice if the
> commit log had been adjusted to mention this, so
On 23/07/14 18:22, Stephen Warren wrote:
> That didn't make any difference.
>
> I also tried the tool interactively. the "Display raw (M)essages" option
> never displayed anything, and the couple of self-tests I tried just
> timed out. "Read (I)nfo block" did display some values that seemed like
>
On 22/07/14 21:34, Stephen Warren wrote:
> Unfortunately, I still can't get these to work on my system.
>
> Per your "Re: atmel_mxt_ts: defaulting irqflags to
> IRQF_TRIGGER_FALLING", I set up the IRQ type in the Tegra DT file, and
> then applied this series on top of next-20140721. The driver app
On 22/07/14 21:37, Stephen Warren wrote:
> On 07/03/2014 09:01 AM, nick.d...@itdev.co.uk wrote:
>> From: Stephen Warren
>
>> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
>> b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
>
>> +touch@4b {
>> +
On 07/07/14 12:21, Sekhar Nori wrote:
> I was unable to get the touchscreen working on my board after applying
> just these patches. It does work correctly with your for-next branch so
> I guess I need to wait for you to post the rest of your patches too.
>
> Here are the relevant messages at bo
From: Nick Dyer
The MXT device may be in bootloader mode on probe, due to:
1) APP CRC failure, either:
a) flash corruption
b) bad power or other intermittent problem while checking CRC
2) If the device has been reset 10 or more times without accessing comms
3) Warm probe, device was in
From: Nick Dyer
This is in preparation for support of the T44 message count object.
Also, cache T5 address to avoid lookup on every interrupt cycle.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
---
drivers/input/touchscreen/atmel_mxt_ts.c | 123
From: Nick Dyer
By storing the previous T6 status byte multiple debug output of the same
status can be suppressed (for example CFGERR).
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
---
drivers/input/touchscreen/atmel_mxt_ts.c | 60 +---
1
From: Nick Dyer
maXTouch chips allow the reading of multiple messages in a single I2C
transaction, which reduces bus overhead and improves performance/latency. The
number of messages available to be read is given by the value in the T44
object which is located directly before the T5 object
From: Nick Dyer
Later chips (for example mXT1664S) different mappings for bootloader addresses.
This means that we must look at the family ID to determine which address to
use.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
---
drivers/input/touchscreen/atmel_mxt_ts.c
From: Nick Dyer
If the bootloader on the touchscreen controller fails to initialise the
firmware image, it stays in bootloader mode and reports a failure. It is
possible to reflash a working firmware image from this state.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
From: Nick Dyer
On a warm probe, the device might be in a state where an flash operation was
not completed.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
---
drivers/input/touchscreen/atmel_mxt_ts.c | 27 ++-
1 file changed, 18 insertions
From: Nick Dyer
The T5 object may have various sizes depending on the objects used on the
particular maXTouch chip and firmware version, therefore it can't be hardcoded
in the driver. Allocate a buffer on probe instead.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng
From: Nick Dyer
By writing zero to both the active and idle cycle times the maXTouch device
is put into a deep sleep mode when it consumes minimal power. It is
unnecessary to change the configuration of any other objects (for example
to disable T9 touchscreen).
It is counterproductive to reset
From: Nick Dyer
By validating the checksum, we can identify if the configuration is
corrupt. In addition, this patch writes the configuration in a short
series of block writes rather than as many individual values.
Signed-off-by: Nick Dyer
Acked-by: Benson Leung
Acked-by: Yufeng Shen
Signed
From: Nick Dyer
The maXTouch chips use the CHG line to generate status events in bootloader
mode, and during configuration download, before there is enough information to
configure the input device. Therefore set up the interrupt handler earlier.
However, this introduces states where parts of
From: Nick Dyer
It is useful to initialise the input device later:
- Screen parameters may not be not known yet, for instance if waiting for
firmware loader to return.
- Device may be in bootloader mode on probe (but could still be recovered by
firmware download).
In addition, later devices
From: Benson Leung
Touchpads are pointers, so make sure to pass the correct values to
input_mt_report_pointer_emulation(). Without this, tap-to-click doesn't
work.
Signed-off-by: Benson Leung
Signed-off-by: Stephen Warren
Signed-off-by: Nick Dyer
---
drivers/input/touchscreen/atmel_mxt
From: Nick Dyer
The existing implementation which encodes the configuration as a binary
blob in platform data is unsatisfactory since it requires a kernel
recompile for the configuration to be changed, and it doesn't deal well
with firmware changes that move values around on the chip.
From: Stephen Warren
Signed-off-by: Stephen Warren
Signed-off-by: Nick Dyer
---
.../devicetree/bindings/input/atmel,maxtouch.txt | 25 +++
drivers/input/touchscreen/atmel_mxt_ts.c | 48 ++
2 files changed, 73 insertions(+)
create mode 100644
Hi Dimitry-
Here is another set of atmel_mxt_ts patches for upstream. There are some
really useful new features, but I hope nothing too controversial.
thanks
Nick Dyer
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message
On 02/07/14 18:25, Dmitry Torokhov wrote:
> In this case board code should take care of setting up the interrupt
> properly and the driver should simply use 0 as flags in request_irq().
> By the way, doesn't generic DT infrastructure already allow specifying
> interrupt triggers and sets them up pr
On 02/07/14 11:49, Sekhar Nori wrote:
> On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
>> On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
>> least a valid) choice. That's probably because the Atmel IRQ signal is
>> routed to our GPIO controller, which is also an IRQ
Stephen Warren wrote:
>> I will test this on my setup and see if I can figure out what is causing
>> the problem.
>
> Nick, did you get anywhere reproducing my problem? Unfortunately with
> your recent patches merged, I can't get the touchpad working at all,
> whereas before I had a few simple pat
1 - 100 of 313 matches
Mail list logo
