Merge branch 'next' into for-linus

!Edrivers/input/input.c

!Edrivers/input/ff-core.c

!Edrivers/input/ff-memless.c

     </sect1>

     <sect1><title>Multitouch Library</title>

!Iinclude/linux/input/mt.h

!Edrivers/input/input-mt.c

     </sect1>

     <sect1><title>Polled input devices</title>

!Iinclude/linux/input-polldev.h

Kernel driver for CMA3000-D0x

============================

Supported chips:

* VTI CMA3000-D0x

Datasheet:

  CMA3000-D0X Product Family Specification 8281000A.02.pdf

  <http://www.vti.fi/en/>

Author: Hemanth V <hemanthv@ti.com>

Description

-----------

CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and

Free fall modes.

Motion Detect Mode: Its the low power mode where interrupts are generated only

when motion exceeds the defined thresholds.

Measurement Mode: This mode is used to read the acceleration data on X,Y,Z

axis and supports 400, 100, 40 Hz sample frequency.

Free fall Mode: This mode is intended to save system resources.

Threshold values: Chip supports defining threshold values for above modes

which includes time and g value. Refer product specifications for more details.

CMA3000 chip supports mutually exclusive I2C and SPI interfaces for

communication, currently the driver supports I2C based communication only.

Initial configuration for bus mode is set in non volatile memory and can later

be modified through bus interface command.

Driver reports acceleration data through input subsystem. It generates ABS_MISC

event with value 1 when free fall is detected.

Platform data need to be configured for initial default values.

Platform Data

-------------

fuzz_x: Noise on X Axis

fuzz_y: Noise on Y Axis

fuzz_z: Noise on Z Axis

g_range: G range in milli g i.e 2000 or 8000

mode: Default Operating mode

mdthr: Motion detect g range threshold value

mdfftmr: Motion detect and free fall time threshold value

ffthr: Free fall g range threshold value

Input Interface

--------------

Input driver version is 1.0.0

Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0

Input device name: "cma3000-accelerometer"

Supported events:

  Event type 0 (Sync)

  Event type 3 (Absolute)

    Event code 0 (X)

      Value     47

      Min    -8000

      Max     8000

      Fuzz     200

    Event code 1 (Y)

      Value    -28

      Min    -8000

      Max     8000

      Fuzz     200

    Event code 2 (Z)

      Value    905

      Min    -8000

      Max     8000

      Fuzz     200

    Event code 40 (Misc)

      Value      0

      Min        0

      Max        1

  Event type 4 (Misc)

Register/Platform parameters Description

----------------------------------------

mode:

	0: power down mode

	1: 100 Hz Measurement mode

	2: 400 Hz Measurement mode

	3: 40 Hz Measurement mode

	4: Motion Detect mode (default)

	5: 100 Hz Free fall mode

	6: 40 Hz Free fall mode

	7: Power off mode

grange:

	2000: 2000 mg or 2G Range

	8000: 8000 mg or 8G Range

mdthr:

	X: X * 71mg (8G Range)

	X: X * 18mg (2G Range)

mdfftmr:

	X: (X & 0x70) * 100 ms (MDTMR)

	   (X & 0x0F) * 2.5 ms (FFTMR 400 Hz)

	   (X & 0x0F) * 10 ms  (FFTMR 100 Hz)

ffthr:

       X: (X >> 2) * 18mg (2G Range)

       X: (X & 0x0F) * 71 mg (8G Range)

Multi-touch (MT) Protocol

-------------------------

	Copyright (C) 2009	Henrik Rydberg <rydberg@euromail.se>

	Copyright (C) 2009-2010	Henrik Rydberg <rydberg@euromail.se>

Introduction

ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than

unity, is related to the contact pressure. For pressure-based devices,

ABS_MT_PRESSURE may be used to provide the pressure on the contact area

instead.

instead. Devices capable of contact hovering can use ABS_MT_DISTANCE to

indicate the distance between the contact and the surface.

In addition to the MAJOR parameters, the oval shape of the contact can be

described by adding the MINOR parameters, such that MAJOR and MINOR are the

major and minor axis of an ellipse. Finally, the orientation of the oval

shape can be describe with the ORIENTATION parameter.

For type A devices, further specification of the touch shape is possible

via ABS_MT_BLOB_ID.

The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a

contact or a pen or something else.  Devices with more granular information

may specify general shapes as blobs, i.e., as a sequence of rectangular

shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices

that currently support it, the ABS_MT_TRACKING_ID event may be used to

report contact tracking from hardware [5].

finger or a pen or something else. Finally, the ABS_MT_TRACKING_ID event

may be used to track identified contacts over time [5].

In the type B protocol, ABS_MT_TOOL_TYPE and ABS_MT_TRACKING_ID are

implicitly handled by input core; drivers should instead call

input_mt_report_slot_state().

Event Semantics

of TOUCH and WIDTH for pressure-based devices or any device with a spatial

signal intensity distribution.

ABS_MT_DISTANCE

The distance, in surface units, between the contact and the surface. Zero

distance means the contact is touching the surface. A positive number means

the contact is hovering above the surface.

ABS_MT_ORIENTATION

The orientation of the ellipse. The value should describe a signed quarter

The type of approaching tool. A lot of kernel drivers cannot distinguish

between different tool types, such as a finger or a pen. In such cases, the

event should be omitted. The protocol currently supports MT_TOOL_FINGER and

MT_TOOL_PEN [2].

MT_TOOL_PEN [2]. For type B devices, this event is handled by input core;

drivers should instead use input_mt_report_slot_state().

ABS_MT_BLOB_ID

The BLOB_ID groups several packets together into one arbitrarily shaped

contact. This is a low-level anonymous grouping for type A devices, and

contact. The sequence of points forms a polygon which defines the shape of

the contact. This is a low-level anonymous grouping for type A devices, and

should not be confused with the high-level trackingID [5]. Most type A

devices do not have blob capability, so drivers can safely omit this event.

ABS_MT_TRACKING_ID

The TRACKING_ID identifies an initiated contact throughout its life cycle

[5]. This event is mandatory for type B devices. The value range of the

TRACKING_ID should be large enough to ensure unique identification of a

contact maintained over an extended period of time.

[5]. The value range of the TRACKING_ID should be large enough to ensure

unique identification of a contact maintained over an extended period of

time. For type B devices, this event is handled by input core; drivers

should instead use input_mt_report_slot_state().

Event Computation

Notes

-----

In order to stay compatible with existing applications, the data

reported in a finger packet must not be recognized as single-touch

events. In addition, all finger data must bypass input filtering,

since subsequent events of the same type refer to different fingers.

In order to stay compatible with existing applications, the data reported

in a finger packet must not be recognized as single-touch events.

For type A devices, all finger data bypasses input filtering, since

subsequent events of the same type refer to different fingers.

The first kernel driver to utilize the MT protocol is the bcm5974 driver,

where examples can be found.

For example usage of the type A protocol, see the bcm5974 driver. For

example usage of the type B protocol, see the hid-egalax driver.

[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the

difference between the contact position and the approaching tool position

could be used to derive tilt.

[2] The list can of course be extended.

[3] Multitouch X driver project: http://bitmath.org/code/multitouch/.

[3] The mtdev project: http://bitmath.org/code/mtdev/.

[4] See the section on event computation.

[5] See the section on finger tracking.

INPUT MULTITOUCH (MT) PROTOCOL

M:	Henrik Rydberg <rydberg@euromail.se>

L:	linux-input@vger.kernel.org

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rydberg/input-mt.git

S:	Maintained

F:	Documentation/input/multi-touch-protocol.txt

F:	drivers/input/input-mt.c

K:	\b(ABS|SYN)_MT_

INTEL IDLE DRIVER

/*

 * Copyright (C) 2010 ST Microelectronics

 * Rajeev Kumar<rajeev-dlh.kumar@st.com>

 *

 * This file is licensed under the terms of the GNU General Public

 * License version 2. This program is licensed "as is" without any

 * warranty of any kind, whether express or implied.

 */

#ifndef __PLAT_KEYBOARD_H

#define __PLAT_KEYBOARD_H

#include <linux/bitops.h>

#include <linux/input.h>

#include <linux/input/matrix_keypad.h>

#include <linux/types.h>

#define DECLARE_KEYMAP(_name) \

int _name[] = { \

	KEY(0, 0, KEY_ESC), \

	KEY(0, 1, KEY_1), \

	KEY(0, 2, KEY_2), \

	KEY(0, 3, KEY_3), \

	KEY(0, 4, KEY_4), \

	KEY(0, 5, KEY_5), \

	KEY(0, 6, KEY_6), \

	KEY(0, 7, KEY_7), \

	KEY(0, 8, KEY_8), \

	KEY(1, 0, KEY_9), \

	KEY(1, 1, KEY_MINUS), \

	KEY(1, 2, KEY_EQUAL), \

	KEY(1, 3, KEY_BACKSPACE), \

	KEY(1, 4, KEY_TAB), \

	KEY(1, 5, KEY_Q), \

	KEY(1, 6, KEY_W), \

	KEY(1, 7, KEY_E), \

	KEY(1, 8, KEY_R), \

	KEY(2, 0, KEY_T), \

	KEY(2, 1, KEY_Y), \

	KEY(2, 2, KEY_U), \

	KEY(2, 3, KEY_I), \

	KEY(2, 4, KEY_O), \

	KEY(2, 5, KEY_P), \

	KEY(2, 6, KEY_LEFTBRACE), \

	KEY(2, 7, KEY_RIGHTBRACE), \

	KEY(2, 8, KEY_ENTER), \

	KEY(3, 0, KEY_LEFTCTRL), \

	KEY(3, 1, KEY_A), \

	KEY(3, 2, KEY_S), \

	KEY(3, 3, KEY_D), \

	KEY(3, 4, KEY_F), \

	KEY(3, 5, KEY_G), \

	KEY(3, 6, KEY_H), \

	KEY(3, 7, KEY_J), \

	KEY(3, 8, KEY_K), \

	KEY(4, 0, KEY_L), \

	KEY(4, 1, KEY_SEMICOLON), \

	KEY(4, 2, KEY_APOSTROPHE), \

	KEY(4, 3, KEY_GRAVE), \

	KEY(4, 4, KEY_LEFTSHIFT), \

	KEY(4, 5, KEY_BACKSLASH), \

	KEY(4, 6, KEY_Z), \

	KEY(4, 7, KEY_X), \

	KEY(4, 8, KEY_C), \

	KEY(4, 0, KEY_L), \

	KEY(4, 1, KEY_SEMICOLON), \

	KEY(4, 2, KEY_APOSTROPHE), \

	KEY(4, 3, KEY_GRAVE), \

	KEY(4, 4, KEY_LEFTSHIFT), \

	KEY(4, 5, KEY_BACKSLASH), \

	KEY(4, 6, KEY_Z), \

	KEY(4, 7, KEY_X), \

	KEY(4, 8, KEY_C), \

	KEY(4, 0, KEY_L), \

	KEY(4, 1, KEY_SEMICOLON), \

	KEY(4, 2, KEY_APOSTROPHE), \

	KEY(4, 3, KEY_GRAVE), \

	KEY(4, 4, KEY_LEFTSHIFT), \

	KEY(4, 5, KEY_BACKSLASH), \

	KEY(4, 6, KEY_Z), \

	KEY(4, 7, KEY_X), \

	KEY(4, 8, KEY_C), \

	KEY(5, 0, KEY_V), \

	KEY(5, 1, KEY_B), \

	KEY(5, 2, KEY_N), \

	KEY(5, 3, KEY_M), \

	KEY(5, 4, KEY_COMMA), \

	KEY(5, 5, KEY_DOT), \

	KEY(5, 6, KEY_SLASH), \

	KEY(5, 7, KEY_RIGHTSHIFT), \

	KEY(5, 8, KEY_KPASTERISK), \

	KEY(6, 0, KEY_LEFTALT), \

	KEY(6, 1, KEY_SPACE), \

	KEY(6, 2, KEY_CAPSLOCK), \

	KEY(6, 3, KEY_F1), \

	KEY(6, 4, KEY_F2), \

	KEY(6, 5, KEY_F3), \

	KEY(6, 6, KEY_F4), \

	KEY(6, 7, KEY_F5), \

	KEY(6, 8, KEY_F6), \

	KEY(7, 0, KEY_F7), \

	KEY(7, 1, KEY_F8), \

	KEY(7, 2, KEY_F9), \

	KEY(7, 3, KEY_F10), \

	KEY(7, 4, KEY_NUMLOCK), \

	KEY(7, 5, KEY_SCROLLLOCK), \

	KEY(7, 6, KEY_KP7), \

	KEY(7, 7, KEY_KP8), \

	KEY(7, 8, KEY_KP9), \

	KEY(8, 0, KEY_KPMINUS), \

	KEY(8, 1, KEY_KP4), \

	KEY(8, 2, KEY_KP5), \

	KEY(8, 3, KEY_KP6), \

	KEY(8, 4, KEY_KPPLUS), \

	KEY(8, 5, KEY_KP1), \

	KEY(8, 6, KEY_KP2), \

	KEY(8, 7, KEY_KP3), \

	KEY(8, 8, KEY_KP0), \

}

/**

 * struct kbd_platform_data - spear keyboard platform data

 * keymap: pointer to keymap data (table and size)

 * rep: enables key autorepeat

 *

 * This structure is supposed to be used by platform code to supply

 * keymaps to drivers that implement keyboards.

 */

struct kbd_platform_data {

	const struct matrix_keymap_data *keymap;

	bool rep;

};

/* This function is used to set platform data field of pdev->dev */

static inline void

kbd_set_plat_data(struct platform_device *pdev, struct kbd_platform_data *data)

{

	pdev->dev.platform_data = data;

}

#endif /* __PLAT_KEYBOARD_H */