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";
+        };