[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F68A46D.9020601@itdev.co.uk>
Date: Tue, 20 Mar 2012 08:38:21 -0700
From: Nick Dyer <nick.dyer@...ev.co.uk>
To: Daniel Kurtz <djkurtz@...omium.org>
CC: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Joonyoung Shim <jy0922.shim@...sung.com>,
Iiro Valkonen <iiro.valkonen@...el.com>,
Henrik Rydberg <rydberg@...omail.se>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
Benson Leung <bleung@...omium.org>,
Yufeng Shen <miletus@...omium.org>,
"Tiwari, Atul" <Atul.Tiwari@...el.com>,
"Bowens, Alan" <Alan.Bowens@...el.com>
Subject: Re: [PATCH 19/20] Input: atmel_mxt_ts - remove mxt_make_highchg and
parse T6 report
Daniel Kurtz wrote:
> This function attempts to make the CHG pin high by reading a bunch of
> messages until the device is happy. Instead of just blindly trying to
> read a fixed number of messages, let's actually read and process them.
>
> It turns out that the messages after boot or nvupdates are T6 reports,
> containing a status, and the config memory checksum. So, let's parse
> them and dump a useful info message.
>
> Signed-off-by: Daniel Kurtz <djkurtz@...omium.org>
mxt_make_highchg exists due to the interrupts being edge triggered. It
forces the CHG line to go high.
With this implementation, I suspect that if a new message arrives after you
have read T44 and before you finish processing messages, then the interrupt
handler will not ever be run. What testing have you done on this?
The printout of T6 messages looks OK, though. I'd prefer to see a lookup
table for the report IDs.
--
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-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/
Powered by blists - more mailing lists