Merge tag 'iio-for-3.10a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next

Jonathan writes:

First set of IIO new drivers and cleanup for the 3.10 cycle.

New stuff

1) Add OF support for specifying mappings between iio devices and their
   in kernel consumers.
2) Driver for AD7923 (extra functionality and support for ad7904, ad7914 and
   ad7924 added later in series)
3) Driver for Exynos adc (dt suppor for phy added later in series).
4) Make iio_push_event save IRQ context - necessary if it is to be used
   within an interrupt handler.  Users of this functionality to follow.
5) For iio use the device tree node name to provide the hwmon name attribute
   if available.

Removal and moves out of staging

1) Drop the adt7410 driver from IIO now that there is a hmwon driver with
   equivalent support. This device is very much targeted at hardware
   monitoring so hwmon is a more appropriate host for the driver.
2) Move iio_hwmon driver to drivers/hwmon.

Cleanups

1) Minor cleanup in ST common library.
2) Large set of patches to break the info_mask element which previously used
odd and even bits to specify if a channel attribute was either shared across
similar channels or specific to only one.  Now we have two bitmaps, one for
those parameters that are specific to this channel and one for those shared
by all channels with the same type as this one.  This has no effect on the
userspace abi. It simplifies the core code and provides more space for new
channel parameters. It has been on the todo list for a long time!

Conflicts:
	drivers/iio/dac/ad5064.c

2 files changed, 149 insertions, 0 deletions

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
new file mode 100644
index 000000000000..05e9d95ede5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -0,0 +1,52 @@
+Samsung Exynos Analog to Digital Converter bindings
+
+This devicetree binding are for the new adc driver written fori
+Exynos4 and upward SoCs from Samsung.
+
+New driver handles the following
+1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
+   and future SoCs from Samsung
+2. Add ADC driver under iio/adc framework
+3. Also adds the Documentation for device tree bindings
+
+Required properties:
+- compatible:           Must be "samsung,exynos-adc-v1"
+                                for exynos4412/5250 controllers.
+                        Must be "samsung,exynos-adc-v2" for
+                                future controllers.
+- reg:                  Contains ADC register address range (base address and
+                        length) and the address of the phy enable register.
+- interrupts:           Contains the interrupt information for the timer. The
+                        format is being dependent on which interrupt controller
+                        the Samsung device uses.
+- #io-channel-cells = <1>; As ADC has multiple outputs
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc: adc@12D10000 {
+        compatible = "samsung,exynos-adc-v1";
+        reg = <0x12D10000 0x100>, <0x10040718 0x4>;
+        interrupts = <0 106 0>;
+        #io-channel-cells = <1>;
+        io-channel-ranges;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D10000 {
+
+        /* NTC thermistor is a hwmon device */
+        ncp15wb473@0 {
+                compatible = "ntc,ncp15wb473";
+                pullup-uV = <1800000>;
+                pullup-ohm = <47000>;
+                pulldown-ohm = <0>;
+                io-channels = <&adc 4>;
+        };
+};
+
+Note: Does not apply to ADC driver under arch/arm/plat-samsung/
+Note: The child node can be added under the adc node or seperately.
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000000000000..0b447d9ad196
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,97 @@
+This binding is derived from clock bindings, and based on suggestions
+from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
+                   with a single IIO output and 1 for nodes with multiple
+                   IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+        adc: voltage-sensor@35 {
+                compatible = "maxim,max1139";
+                reg = <0x35>;
+                #io-channel-cells = <1>;
+        };
+
+Example for a configuration with trigger:
+
+        adc@35 {
+                compatible = "some-vendor,some-adc";
+                reg = <0x35>;
+
+                adc1: iio-device@0 {
+                        #io-channel-cells = <1>;
+                        /* other properties */
+                };
+                adc2: iio-device@1 {
+                        #io-channel-cells = <1>;
+                        /* other properties */
+                };
+        };
+
+==IIO consumers==
+
+Required properties:
+io-channels:    List of phandle and IIO specifier pairs, one pair
+                for each IIO input to the device. Note: if the
+                IIO provider specifies '0' for #io-channel-cells,
+                then only the phandle portion of the pair will appear.
+
+Optional properties:
+io-channel-names:
+                List of IIO input name strings sorted in the same
+                order as the io-channels property. Consumers drivers
+                will use io-channel-names to match IIO input names
+                with IIO specifiers.
+io-channel-ranges:
+                Empty property indicating that child nodes can inherit named
+                IIO channels from this node. Useful for bus nodes to provide
+                and IIO channel to their children.
+
+For example:
+
+        device {
+                io-channels = <&adc 1>, <&ref 0>;
+                io-channel-names = "vcc", "vdd";
+        };
+
+This represents a device with two IIO inputs, named "vcc" and "vdd".
+The vcc channel is connected to output 1 of the &adc device, and the
+vdd channel is connected to output 0 of the &ref device.
+
+==Example==
+
+        adc: max1139@35 {
+                compatible = "maxim,max1139";
+                reg = <0x35>;
+                #io-channel-cells = <1>;
+        };
+
+        ...
+
+        iio_hwmon {
+                compatible = "iio-hwmon";
+                io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
+                        <&adc 3>, <&adc 4>, <&adc 5>,
+                        <&adc 6>, <&adc 7>, <&adc 8>,
+                        <&adc 9>;
+        };
+
+        some_consumer {
+                compatible = "some-consumer";
+                io-channels = <&adc 10>, <&adc 11>;
+                io-channel-names = "adc1", "adc2";
+        };