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 have a different touchscreen object (T100) which
requires handling differently.

This also reduces the complexity of the probe function.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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 the interrupt processing
must not run. Use data->object_table as a way to tell whether the chip
information is valid, and data->input_dev as a way to tell whether it is
valid to generate input report.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The patch e57a66aa: "Input: atmel_mxt_ts - read and report
bootloader version" from May 18, 2014, leads to the following static
checker warning:

	drivers/input/touchscreen/atmel_mxt_ts.c:437 mxt_get_bootloader_version()
	warn: signedness bug returning '(-5)'

drivers/input/touchscreen/atmel_mxt_ts.c
   429  static u8 mxt_get_bootloader_version(struct mxt_data *data, u8 val)
   430  {
   431          struct device *dev = &data->client->dev;
   432          u8 buf[3];
   433
   434          if (val & MXT_BOOT_EXTENDED_ID) {
   435                  if (mxt_bootloader_read(data, &buf[0], 3) != 0) {
   436                          dev_err(dev, "%s: i2c failure\n", __func__);
   437                          return -EIO;
                                       ^^^^
This gets truncated into a number from 0-255 and anyway the caller
doesn't check for errors.

(reported by Dan Carpenter)
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This avoids confusion with the newer T100 touchscreen object.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

By reading the touchscreen configuration from the settings that the
maXTouch chip is actually using, we can remove some platform data.

The matrix size is not used for anything, and results in some rather
confusing code to re-read it because it may change when configuration
is downloaded, so don't print it out.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Atmel supplies firmware files in ASCII HEX format (.enc) which must be
converted before they can be loaded by kernel driver. Try to detect
the error and print a friendly error message rather than feeding junk
to the bootloader.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

By implementing a frame counter, print out fewer debug messages (the
firmware may contain hundreds of frames).
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Move bootloaders reads/writes into separate functions. Instead of switching
client->addr, define new field bootloader_addr in mxt_data. Implement
lookup calculation for bootloader addresses.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The configuration is stored in NVRAM on the maXTouch chip. When the device
is reset it reports a CRC of the stored configuration values. Therefore it
isn't necessary to send the configuration on each probe - we can check the
CRC matches and avoid a timeconsuming backup/reset cycle.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

- Add error messages for probe errors
- Report type in invalid object type
- Tweak some other debug output messages
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The delay before the chip can be accessed after reset varies between
different chips in maXTouch family. Waiting for an interrupt and a T6
status message with the RESET bit set is a better behaviour.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Rather than msleep for MXT_RESET_TIME and MXT_FWRESET_TIME during the
transition to bootloader mode and the transition back from app, wait for
the CHG assert to indicate that the transition is done.

This change replaces the msleep with a wait for completion that the
mxt_interrupt handler signals.

Also add CHG poll after last firmware frame - some bootloader versions will
assert the interrupt line after the final frame, in testing this meant that
the driver attempts to read the info block too early whilst the chip is
still resetting.

This improves firmware update time as we no longer wait longer than
necessary for each reset.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The driver should not immediately read bootloader status when in
Application Update Mode. The CHG line will assert when the device has made
a state transition and is ready to report a new status via i2c.

This change adds a wait for completion in mxt_check_bootloader, and changes
the mxt_interrupt handler to signal the completion.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

These two object table entry fields are reported 1 less than their value.
When used, however, we always want the actual size and instances.

To keep the object size and instances 1-byte fields, and thus preserve
the object-table struct's 6-byte packed alignment, add some convenient
accessor functions that do the +1 every time these fields are accessed.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

 * The mapping of the GPIO numbers into the T19 status byte varies between
   different maXTouch chips. Some have up to 7 GPIOs. Allowing a keycode array
   of up to 8 items is simpler and more generic. So replace #define with
   configurable number of keys which also allows the removal of is_tp.
 * Rename platform data parameters to include "t19" to prevent confusion with
   T15 key array.
 * Probe aborts early on when pdata is NULL, so no need to check.
 * Move "int i" to beginning of function (mixed declarations and code)
 * Use API calls rather than __set_bit()
 * Remove unused dev variable.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NYufeng Shen <miletus@chromium.org>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

It is not necessary to download these values to the maXTouch chip on every
probe, since they are stored in NVRAM. It makes life difficult when tuning
the device to keep them in sync with the config array/file, and requires a
new kernel build for minor tweaks.

These parameters only represent a tiny subset of the available
configuration options, tracking all of these options in platform data would
be a endless task. In addition, different versions of maXTouch chips may
have these values in different places or may not even have them at all.

Having these values also makes life more complex for device tree and other
platforms where having to define a static configuration isn't helpful.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Use the wrapper function for retrieving the platform data instead
of accessing dev->platform_data directly. This is a cosmetic change
to make the code simpler and enhance the readability.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NFugang Duan <B38611@freescale.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

There is a more complete atmel patch-series out by Nick Dyer that fixes
this and other things, but in the meantime this is the minimal thing to
get the touchscreen going on (at least my) Pixel Chromebook.

Not that I want my dirty fingers near that beautiful screen, but it
seems that a non-initialized touchscreen will also end up being a
constant wakeup source, so you have to disable it to go to sleep.  And
it's easier to just fix the initialization sequence.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This same driver can be used by atmel based touchscreens and touchpads
(buttonpads). Platform data may specify a device is a touchpad
using the is_tp flag.

This will cause the driver to perform some touchpad specific
initializations, such as:
  * register input device name "Atmel maXTouch Touchpad" instead of
  Touchscreen.
  * register BTN_LEFT & BTN_TOOL_* event types.
  * register axis resolution (as a fixed constant, for now)
  * register BUTTONPAD property
  * process GPIO buttons using reportid T19

Input event GPIO mapping is done by the platform data key_map array.

key_map[x] should contain the KEY or BTN code to send when processing
GPIOx from T19. To specify a GPIO as not an input source, populate
with KEY_RESERVED, or 0.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Tested-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Use %*ph format specifier to print small buffer.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Preparing to move more repeated code into the mt core, add a flags
argument to the input_mt_slots_init() function.
Reviewed-and-tested-by: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Tested-by: NPing Cheng <pingc@wacom.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

Dmitry: I understand that I am a bit late to the party :) but I do not
agree with this change. Failure to create attributes is not sometihng
that user could cause (at least not easily) and thus would not be a
setup issue but something more severe. I believe we should fail
loading the driver so sysfs attribute breakage will be noticed as soon
as possible, instead of discovering it much much later in the process.

This reverts commit 63990038.
Requested-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

Since commit 1c6c6952 ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail. This patch adds the
IRQF_ONESHOT to input drivers where it is missing. Not modified by
this patch are those drivers where the requested IRQ will always be a
nested IRQ (e.g. because it's part of an MFD), since for this special
case IRQF_ONESHOT is not required to be specified when requesting the
IRQ.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The normal messages sent after boot or NVRAM update are T6 reports,
containing a status, and the config memory checksum.  Parse them and dump
a useful info message.

This patch tested on an MXT224E.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

Each interrupt contains information for all contacts with changing
properties.  Process all of this information at once, and send it all in a
a single input report (ie input events ending in EV_SYN/SYN_REPORT).

This patch was tested using an MXT224E.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

Atmel mxt devices can report one finger for each T9 reportid.
Therefore, this range can be used to report the max number of MT-B slots
to userspace instead of assuming a fixed 10.

Note that mxt_initialized() must complete early, since the input_dev
properties now depend on values in the object table.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

This small refactor is in preparation for checking more report types
in the mxt_interrupt message processing loop.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

Streamline interrupt processing by caching the T9 reportid range when
first reading the object table.

In the process, refactor reading the object descriptor table.
First, since the object_table entries are now exactly the same layout
in device memory and in the driver, allocate an appropriately sized
array and fetch the entire table directly into it in a single i2c
transaction.  Since a 6 byte table object requires 10 bytes to read,
doing this dramatically reduces overhead.

Note: The cached T9 reportid's are initialized to 0, which is an invalid
reportid.  Thus, the checks in the interrupt handler will always fail for
devices that do not support the T9 object.  Therefore, after doing a
firmware update, the old object table is destroyed and all cached object
values are reset to 0, before reading the new object table, in case
the new firmware does not have the old objects.

This patch tested on an MXT224E.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

The Object Table is freed in three cases:
  1) When the driver is being removed.
  2) In the error path of mxt_initialize().
  3) Just after a firmware update, when a new object table is
     about to be read.

For cases 2 & 3, the driver is not immediately unloaded, so this patch
refactors these cases to use a common cleanup function.  It also refactors
the mxt_initialize error paths to ensure that this cleanup happens.

Note: mxt_update_fw_store() does not handle errors during mxt_initialize().
A proposed fix for this is in a subsequent patchset.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

Update the debug message:
 * print inidividual status bits
 * print the pressure value
 * use '%u' for unsigned quantities
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

Instead of carrying around per-finger state in the driver instance, just
report each finger as it arrives to the input layer, and let the input
layer (evdev) hold the event state (which it does anyway).

Note: this driver does not really do MT-B properly. Each input report
(a group of input events followed by a SYN_REPORT) only contains data for
a single contact.  When multiple fingers are present on a device, each is
properly reported in its own MT_SLOT.  However, there is only ever one
MT_SLOT per SYN_REPORT.  This is fixed in a subsequent patch.

This patch was tested with an mXT224E.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>