summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-03-25 10:50:03 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-03-25 10:50:03 -0700
commitef994fda44d6b55ffef7bfdf06f645ff2ab1ab1a (patch)
tree564a62822ebb1f6f7e1f86b0eefc34bc769dff7d /Documentation
parent25eeb667599b192ea850a062d69383ee864c06ab (diff)
parent51b53dc991ae7eebc5d45b06d576da6486fbf823 (diff)
downloadop-kernel-dev-ef994fda44d6b55ffef7bfdf06f645ff2ab1ab1a.zip
op-kernel-dev-ef994fda44d6b55ffef7bfdf06f645ff2ab1ab1a.tar.gz
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
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt52
-rw-r--r--Documentation/devicetree/bindings/iio/iio-bindings.txt97
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 0000000..05e9d95
--- /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 0000000..0b447d9
--- /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";
+ };
OpenPOWER on IntegriCloud