input: Add Atmel maXTouch touchscreen driver

Add Atmel maXTouch touchscreen driver (I2C interface). The MT slots protocol will be implemented later.

---
 drivers/input/touchscreen/Kconfig          |   13 +
 drivers/input/touchscreen/Makefile         |    1 +
 drivers/input/touchscreen/atmel_maxtouch.c | 2104 ++++++++++++++++++++++++++++
 include/linux/atmel_maxtouch.h             |  310 ++++
 4 files changed, 2428 insertions(+), 0 deletions(-)
 create mode 100644 drivers/input/touchscreen/atmel_maxtouch.c
 create mode 100644 include/linux/atmel_maxtouch.h

index 06ea8da..a0cec0d 100644
@@ -395,6 +395,19 @@ config TOUCHSCREEN_TOUCHWIN
 	  To compile this driver as a module, choose M here: the
 	  module will be called touchwin.
 
+config TOUCHSCREEN_ATMEL_MAXTOUCH
+ 	tristate "Atmel maXTouch based touchscreen: I2C Interface"
+ 	depends on I2C
+ 	help
+ 	  Say Y here if you have a touchscreen interface using an
+ 	  Amel maXTouch controller, and your board-specific initialization
+ 	  code includes that in its table of I2C devices.
+
+ 	  If unsure, say N (but it's safe to say "Y").
+
+ 	  To compile this driver as a module, choose M here: the
+ 	  module will be called maXTouch.
+
 config TOUCHSCREEN_ATMEL_TSADCC
 	tristate "Atmel Touchscreen Interface"
 	depends on ARCH_AT91SAM9RL || ARCH_AT91SAM9G45

index 7cc1b4f..861941d 100644
@@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879)	+= ad7879.o
 obj-$(CONFIG_TOUCHSCREEN_AD7879_I2C)	+= ad7879-i2c.o
 obj-$(CONFIG_TOUCHSCREEN_AD7879_SPI)	+= ad7879-spi.o
 obj-$(CONFIG_TOUCHSCREEN_ADS7846)	+= ads7846.o
+obj-$(CONFIG_TOUCHSCREEN_ATMEL_MAXTOUCH)+= atmel_maxtouch.o
 obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC)	+= atmel_tsadcc.o
 obj-$(CONFIG_TOUCHSCREEN_BITSY)		+= h3600_ts_input.o
 obj-$(CONFIG_TOUCHSCREEN_BU21013)       += bu21013_ts.o

1.7.0.4

Hi Iiro,

I believe there is already a driver for this hardware in the tree (qt602240.c). Could you tell me what additional features your driver implements and why can't they be added to the existing driver.

Thanks.

Dmitry

Hi Dmitry,

the current driver is written for one maXTouch chip, mXT224. The driver that I submitted will support all current maXTouch chips, and it is built to be future-proof so it should work with yet to be released chips too, with minor or no changes. This shows in the naming too, part name "qt602240" is deprecated and it shouldn't be used. As the driver should work with all chips in the maXTouch family, a more generic naming convention in the driver name itself and all the code inside the driver would be more appropriate.

Atmel would like to be the maintainer of this driver, and it would be easiest if we could use the code I submitted. Of course we would be happy to implement any improvements like the threaded IRQs.

Best Regards,

Iiro Valkonen
Application Engineer / Atmel Corporation
Tel: +358(9)45208250 / Mobile: +358(40)5820012
[email protected] / www.atmel.com

Hi Dmitry

Having written this same driver for this IC I agree with Iiro that we should have one driver that would support multiple IC firmware revisions. Once we had the base driver completed adding functionality to the driver was a snap.

Can these two drivers co-exist and let the developer decide which driver to use? Of course the Atmel driver needs to be scrubbed for problems.

Now. I also strongly agree with Dmitry that the driver you are submitting is IMHO really rough and needs work. Without even reviewing the complete functionality I have many concerns about the code.

For instance the header file spacing is really crazy. I am not sure if the spacing was intended but it is really hard to follow. In the source it seems like there is more debug code then functional working code. The driver should be updated to use the request_threaded_irq call and not the request_irq then there is no need for scheduling work queues. I can go on and on.... But I won't do a complete review on this driver unless Dmitry indicates that he will merge it once complete.

I would prefer Atmel be the maintainer as they can expedite future changes into the driver prior to releasing the support firmware.

Dan

------------------------------------------------------------------------------------
Dan Murphy
Texas Instruments

The name of the driver is not important and can easily be changed, just send me a patch.

No, that would cause duplicate effort. Just witness patches form Intel submitted for the mainline driver a few days ago.

Development process in Linux kernel is rarely revolutionary but rather evolutionary. That is why I asked Iiro to enumerate the changes needed for qt602240 to support entire line of maXTouch chips.

Like I said, I will not take the driver wholesale but I will take it piecemeal, feature by feature transforming qt602240.

BTW, what is up with needing 2 custom character devices?

I will be delighted if Atmel takes over the driver, as long as they follow the standard kernel practices.

Thanks.

Dmitry