Merge v3.13-rc2 into staging-next

as root before you can use this.  You'll probably also want to

get the user-space microcode_ctl utility to use with this.

Powertweak

----------

If you are running v0.1.17 or earlier, you should upgrade to

version v0.99.0 or higher. Running old versions may cause problems

with programs using shared memory.

udev

----

udev is a userspace application for populating /dev dynamically with

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

o  <http://www.urbanmyth.org/microcode/>

Powertweak

----------

o  <http://powertweak.sourceforge.net/>

udev

----

o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html>

     </sect1>

     <sect1><title>Wait queues and Wake events</title>

!Iinclude/linux/wait.h

!Ekernel/wait.c

!Ekernel/sched/wait.c

     </sect1>

     <sect1><title>High-resolution timers</title>

!Iinclude/linux/ktime.h

I2C for OMAP platforms

Required properties :

- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"

- compatible : Must be "ti,omap2420-i2c", "ti,omap2430-i2c", "ti,omap3-i2c"

  or "ti,omap4-i2c"

- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)

- #address-cells = <1>;

- #size-cells = <0>;

Qualcomm MSM pseudo random number generator.

Required properties:

- compatible  : should be "qcom,prng"

- reg         : specifies base physical address and size of the registers map

- clocks      : phandle to clock-controller plus clock-specifier pair

- clock-names : "core" clocks all registers, FIFO and circuits in PRNG IP block

Example:

	rng@f9bff000 {

		compatible = "qcom,prng";

		reg = <0xf9bff000 0x200>;

		clocks = <&clock GCC_PRNG_AHB_CLK>;

		clock-names = "core";

	};

GPIO Mappings

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

This document explains how GPIOs can be assigned to given devices and functions.

Note that it only applies to the new descriptor-based interface. For a

description of the deprecated integer-based GPIO interface please refer to

gpio-legacy.txt (actually, there is no real mapping possible with the old

interface; you just fetch an integer from somewhere and request the

corresponding GPIO.

Platforms that make use of GPIOs must select ARCH_REQUIRE_GPIOLIB (if GPIO usage

is mandatory) or ARCH_WANT_OPTIONAL_GPIOLIB (if GPIO support can be omitted) in

their Kconfig. Then, how GPIOs are mapped depends on what the platform uses to

describe its hardware layout. Currently, mappings can be defined through device

tree, ACPI, and platform data.

Device Tree

-----------

GPIOs can easily be mapped to devices and functions in the device tree. The

exact way to do it depends on the GPIO controller providing the GPIOs, see the

device tree bindings for your controller.

GPIOs mappings are defined in the consumer device's node, in a property named

<function>-gpios, where <function> is the function the driver will request

through gpiod_get(). For example:

	foo_device {

		compatible = "acme,foo";

		...

		led-gpios = <&gpio 15 GPIO_ACTIVE_HIGH>, /* red */

			    <&gpio 16 GPIO_ACTIVE_HIGH>, /* green */

			    <&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */

		power-gpio = <&gpio 1 GPIO_ACTIVE_LOW>;

	};

This property will make GPIOs 15, 16 and 17 available to the driver under the

"led" function, and GPIO 1 as the "power" GPIO:

	struct gpio_desc *red, *green, *blue, *power;

	red = gpiod_get_index(dev, "led", 0);

	green = gpiod_get_index(dev, "led", 1);

	blue = gpiod_get_index(dev, "led", 2);

	power = gpiod_get(dev, "power");

The led GPIOs will be active-high, while the power GPIO will be active-low (i.e.

gpiod_is_active_low(power) will be true).

ACPI

----

ACPI does not support function names for GPIOs. Therefore, only the "idx"

argument of gpiod_get_index() is useful to discriminate between GPIOs assigned

to a device. The "con_id" argument can still be set for debugging purposes (it

will appear under error messages as well as debug and sysfs nodes).

Platform Data

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

Finally, GPIOs can be bound to devices and functions using platform data. Board

files that desire to do so need to include the following header:

	#include <linux/gpio/driver.h>

GPIOs are mapped by the means of tables of lookups, containing instances of the

gpiod_lookup structure. Two macros are defined to help declaring such mappings:

	GPIO_LOOKUP(chip_label, chip_hwnum, dev_id, con_id, flags)

	GPIO_LOOKUP_IDX(chip_label, chip_hwnum, dev_id, con_id, idx, flags)

where

  - chip_label is the label of the gpiod_chip instance providing the GPIO

  - chip_hwnum is the hardware number of the GPIO within the chip

  - dev_id is the identifier of the device that will make use of this GPIO. If

	NULL, the GPIO will be available to all devices.

  - con_id is the name of the GPIO function from the device point of view. It

	can be NULL.

  - idx is the index of the GPIO within the function.

  - flags is defined to specify the following properties:

	* GPIOF_ACTIVE_LOW	- to configure the GPIO as active-low

	* GPIOF_OPEN_DRAIN	- GPIO pin is open drain type.

	* GPIOF_OPEN_SOURCE	- GPIO pin is open source type.

In the future, these flags might be extended to support more properties.

Note that GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0.

A lookup table can then be defined as follows:

	struct gpiod_lookup gpios_table[] = {

	GPIO_LOOKUP_IDX("gpio.0", 15, "foo.0", "led", 0, GPIO_ACTIVE_HIGH),

	GPIO_LOOKUP_IDX("gpio.0", 16, "foo.0", "led", 1, GPIO_ACTIVE_HIGH),

	GPIO_LOOKUP_IDX("gpio.0", 17, "foo.0", "led", 2, GPIO_ACTIVE_HIGH),

	GPIO_LOOKUP("gpio.0", 1, "foo.0", "power", GPIO_ACTIVE_LOW),

	};

And the table can be added by the board code as follows:

	gpiod_add_table(gpios_table, ARRAY_SIZE(gpios_table));

The driver controlling "foo.0" will then be able to obtain its GPIOs as follows:

	struct gpio_desc *red, *green, *blue, *power;

	red = gpiod_get_index(dev, "led", 0);

	green = gpiod_get_index(dev, "led", 1);

	blue = gpiod_get_index(dev, "led", 2);

	power = gpiod_get(dev, "power");

	gpiod_direction_output(power, 1);

Since the "power" GPIO is mapped as active-low, its actual signal will be 0

after this code. Contrary to the legacy integer GPIO interface, the active-low

property is handled during mapping and is thus transparent to GPIO consumers.