linux-kernel - Re: [PATCH 00/15] atmel_mxt_ts - device tree, bootloader, etc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53CFD50C.4040509@itdev.co.uk>
Date:	Wed, 23 Jul 2014 16:30:20 +0100
From:	Nick Dyer <nick.dyer@...ev.co.uk>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Yufeng Shen <miletus@...gle.com>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Alan Bowens <Alan.Bowens@...el.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Meerwald <pmeerw@...erw.net>,
	Benson Leung <bleung@...omium.org>,
	Olof Johansson <olofj@...omium.org>,
	Sekhar Nori <nsekhar@...com>
Subject: Re: [PATCH 00/15] atmel_mxt_ts - device tree, bootloader, etc

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 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.

> 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.

> 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)

If this works, then we need to adjust the board file that powers it on, the
correct power on sequence is contained in this later patch:
https://github.com/ndyer/linux/commit/97e938fa5863

>> [    1.831998] atmel_mxt_ts 1-004b: Interrupt triggered but zero messages

FWIW, this warning generally means you should be using the CHG line mode 1
in T18 COMMSCONFIG. It's benign, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/