Merge branch 'v3.3-samsung-fixes-3' of...

!Iinclude/linux/device.h

     </sect1>

     <sect1><title>Device Drivers Base</title>

!Idrivers/base/init.c

!Edrivers/base/driver.c

!Edrivers/base/core.c

!Edrivers/base/syscore.c

!Edrivers/base/class.c

!Idrivers/base/node.c

!Edrivers/base/firmware_class.c

!Edrivers/base/transport_class.c

<!-- Cannot be included, because

     exceed allowed 44 characters maximum

X!Edrivers/base/attribute_container.c

-->

!Edrivers/base/sys.c

!Edrivers/base/dd.c

<!--

X!Edrivers/base/interface.c

-->

!Iinclude/linux/platform_device.h

!Edrivers/base/platform.c

!Edrivers/base/bus.c

     </sect1>

     <sect1><title>Device Drivers DMA Management</title>

!Edrivers/base/dma-buf.c

!Edrivers/base/dma-coherent.c

!Edrivers/base/dma-mapping.c

     </sect1>

     <sect1><title>Device Drivers Power Management</title>

!Edrivers/base/power/main.c

  <chapter id="uart16x50">

     <title>16x50 UART Driver</title>

!Edrivers/tty/serial/serial_core.c

!Edrivers/tty/serial/8250.c

!Edrivers/tty/serial/8250/8250.c

  </chapter>

  <chapter id="fbdev">

  6. List of managed interfaces

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

MEM

  devm_kzalloc()

  devm_kfree()

IO region

  devm_request_region()

  devm_request_mem_region()

class/input/event*/device/capabilities/, and the properties of a device are

provided in class/input/event*/device/properties.

Types:

==========

Types are groupings of codes under a logical input construct. Each type has a

set of applicable codes to be used in generating events. See the Codes section

for details on valid codes for each type.

Event types:

===========

Event types are groupings of codes under a logical input construct. Each

type has a set of applicable codes to be used in generating events. See the

Codes section for details on valid codes for each type.

* EV_SYN:

  - Used as markers to separate events. Events may be separated in time or in

* EV_FF_STATUS:

  - Used to receive force feedback device status.

Codes:

==========

Codes define the precise type of event.

Event codes:

===========

Event codes define the precise type of event.

EV_SYN:

----------

EV_PWR events are a special type of event used specifically for power

mangement. Its usage is not well defined. To be addressed later.

Device properties:

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

Normally, userspace sets up an input device based on the data it emits,

i.e., the event types. In the case of two devices emitting the same event

types, additional information can be provided in the form of device

properties.

INPUT_PROP_DIRECT + INPUT_PROP_POINTER:

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

The INPUT_PROP_DIRECT property indicates that device coordinates should be

directly mapped to screen coordinates (not taking into account trivial

transformations, such as scaling, flipping and rotating). Non-direct input

devices require non-trivial transformation, such as absolute to relative

transformation for touchpads. Typical direct input devices: touchscreens,

drawing tablets; non-direct devices: touchpads, mice.

The INPUT_PROP_POINTER property indicates that the device is not transposed

on the screen and thus requires use of an on-screen pointer to trace user's

movements.  Typical pointer devices: touchpads, tablets, mice; non-pointer

device: touchscreen.

If neither INPUT_PROP_DIRECT or INPUT_PROP_POINTER are set, the property is

considered undefined and the device type should be deduced in the

traditional way, using emitted event types.

INPUT_PROP_BUTTONPAD:

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

For touchpads where the button is placed beneath the surface, such that

pressing down on the pad causes a button click, this property should be

set. Common in clickpad notebooks and macbooks from 2009 and onwards.

Originally, the buttonpad property was coded into the bcm5974 driver

version field under the name integrated button. For backwards

compatibility, both methods need to be checked in userspace.

INPUT_PROP_SEMI_MT:

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

Some touchpads, most common between 2008 and 2011, can detect the presence

of multiple contacts without resolving the individual positions; only the

number of contacts and a rectangular shape is known. For such

touchpads, the semi-mt property should be set.

Depending on the device, the rectangle may enclose all touches, like a

bounding box, or just some of them, for instance the two most recent

touches. The diversity makes the rectangle of limited use, but some

gestures can normally be extracted from it.

If INPUT_PROP_SEMI_MT is not set, the device is assumed to be a true MT

device.

Guidelines:

==========

The guidelines below ensure proper single-touch and multi-finger functionality.

BTN_{MOUSE,LEFT,MIDDLE,RIGHT} must not be reported as the result of touch

contact. BTN_TOOL_<name> events should be reported where possible.

For new hardware, INPUT_PROP_DIRECT should be set.

Trackpads:

----------

Legacy trackpads that only provide relative position information must report

on the trackpad. Where multi-finger support is available, BTN_TOOL_<name> should

be used to report the number of touches active on the trackpad.

For new hardware, INPUT_PROP_POINTER should be set.

Tablets:

----------

BTN_TOOL_<name> events must be reported when a stylus or other tool is active on

BTN_{0,1,2,etc} are good generic codes for unlabeled buttons. Do not use

meaningful buttons, like BTN_FORWARD, unless the button is labeled for that

purpose on the device.

For new hardware, both INPUT_PROP_DIRECT and INPUT_PROP_POINTER should be set.

...

{

	.name "2bit"

	.name = "2bit"

	.ctrl_dev_name = "pinctrl-foo",

	.function = "mmc0",

	.group = "mmc0_1_grp",

	.dev_name = "foo-mmc.0",

},

{

	.name "4bit"

	.name = "4bit"

	.ctrl_dev_name = "pinctrl-foo",

	.function = "mmc0",

	.group = "mmc0_1_grp",

	.dev_name = "foo-mmc.0",

},

{

	.name "4bit"

	.name = "4bit"

	.ctrl_dev_name = "pinctrl-foo",

	.function = "mmc0",

	.group = "mmc0_2_grp",

	.dev_name = "foo-mmc.0",

},

{

	.name "8bit"

	.name = "8bit"

	.ctrl_dev_name = "pinctrl-foo",

	.function = "mmc0",

	.group = "mmc0_1_grp",

	.dev_name = "foo-mmc.0",

},

{

	.name "8bit"

	.name = "8bit"

	.ctrl_dev_name = "pinctrl-foo",

	.function = "mmc0",

	.group = "mmc0_2_grp",

	.dev_name = "foo-mmc.0",

},

{

	.name "8bit"

	.name = "8bit"

	.ctrl_dev_name = "pinctrl-foo",

	.function = "mmc0",

	.group = "mmc0_3_grp",

like this:

{

	.name "POWERMAP"

	.name = "POWERMAP"

	.ctrl_dev_name = "pinctrl-foo",

	.function = "power_func",

	.hog_on_boot = true,

foo_switch()

{

	struct pinmux pmx;

	struct pinmux *pmx;

	/* Enable on position A */

	pmx = pinmux_get(&device, "spi0-pos-A");

 - Send the patch, after verifying that it follows the above rules, to

   stable@vger.kernel.org.  You must note the upstream commit ID in the

   changelog of your submission.

   changelog of your submission, as well as the kernel version you wish

   it to be applied to.

 - To have the patch automatically included in the stable tree, add the tag

     Cc: stable@vger.kernel.org

   in the sign-off area. Once the patch is merged it will be applied to