On 07/23/2014 02:29 PM, Dmitry Torokhov wrote:

On Wed, Jul 23, 2014 at 11:22:54AM -0600, Stephen Warren wrote:

quoted

On 07/23/2014 09:30 AM, Nick Dyer wrote:

quoted

On 22/07/14 21:34, Stephen Warren wrote:

quoted

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 appears to
initialize OK, but neither X nor evtest see any events from the device.
The IRQ count in /proc/interrupts doesn't increase when I touch the
touchpad, but does when I press it hard enough to trigger the physical
button.

You're using the T19/GPIO support, then? In which case, there appears to be
something wrong on the touch controller rather than the driver itself.

I assume I'm using T19, since there's a physical click action on the
touchpad along with the normal touch detection.

quoted

quoted

A boot log with debug enabled follows. No additional kernel log
messages are generated by touches or clicks.

Perhaps I should add some debug to mxt_input_button() - currently it will
not debug the fact that a click is received, although I guess that you will
see it in getevent.

quoted

Do you have any idea what I should try?

I am suspicious that it may be that the power sequencing isn't quite right,
which sometimes leads to parts of the chip not working properly (eg GPIO
buttons working, but no touch).

The patch "use deep sleep when stopped" removes the reset on every resume
(which would otherwise kill resume performance). But that reset tends to
paper over a device which hasn't been powered up properly in the first place.

Could you try issuing a manual reset and see if the touch starts working? I
would normally do this by compiling our obp-utils software from
https://github.com/atmel-maxtouch/obp-utils using ndk-build and doing
something like:

mxt-app -d i2c-dev:1-004b --reset

(you need CONFIG_I2C_DEBUG to make /dev/i2c-1 appear)

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
they might be correct rather than random data.

Interestingly though, I did bisect the series and found "Input:
atmel_mxt_ts - use deep sleep mode when stopped" causes the problem. If
I apply the whole series and revert that one patch, the touchpad works
for mouse movement, but interestingly not for taps or physical clicks.

I ended up applying everything but the "deep sleep" patch. I wonder if
you have any keys defined to indicate that it is a touchpad and activate
tap-to-click support in userspace.

Yes, I have one GPIO defined in the keymap, for the physical
push-to-click button:

                trackpad@4b {
                        compatible = "atmel,maxtouch";
                        reg = <0x4b>;
                        interrupt-parent = <&gpio>;
                        interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>;
                        linux,gpio-keymap = <0 0 0 BTN_LEFT>;
                };

(at some point long ago, this did work fine, just by adding my DT
binding/parsing patch on top of what was in linux-next).