Re: [RFC 10/11] iio: Add OF support
On Sun, Feb 03, 2013 at 11:57:53AM +, Jonathan Cameron wrote:
> On 02/03/2013 11:52 AM, Lars-Peter Clausen wrote:
> > On 02/03/2013 12:47 PM, Lars-Peter Clausen wrote:
> >> On 02/03/2013 12:39 PM, Jonathan Cameron wrote:
> >>> On 02/02/2013 04:10 PM, Guenter Roeck wrote:
> On Sat, Feb 02, 2013 at 10:29:02AM +, Jonathan Cameron wrote:
> > On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> >> Provide bindings, new API access functions, and parse OF data
> >> during initialization.
> >>
> > Firstly thanks for working on this Guenter, it's been a big hole
> > for a while largely because non of our largest developers were
> > actually using development platforms with device tree support.
> >
> > Given my knowledge of device tree is based on the odd article
> > and looking at similar sets of bindings this morning, my comments
> > are likely to be somewhat superficial and uninformed ;)
> >
> > Mostly on this one I'll take a back seat and let those who
> > know this stuff better come to a consensus.
> >
> > Jonathan
> >
> >> Signed-off-by: Guenter Roeck
> >> ---
> >> .../devicetree/bindings/iio/iio-bindings.txt | 97
> >> drivers/iio/inkern.c | 241
> >>
> >> include/linux/iio/consumer.h |8 +
> >> 3 files changed, 299 insertions(+), 47 deletions(-)
> >> create mode 100644
> >> Documentation/devicetree/bindings/iio/iio-bindings.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> >> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> >> new file mode 100644
> >> index 000..0f51c95
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> >> @@ -0,0 +1,97 @@
> >> +This binding is a work-in-progress, and are based on clock bindings
> >> and
> >> +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 more 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 clock 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.
> >> +
> >> +Optional properties:
> >> +io-channel-output-names:
> >> + Recommended to be a list of strings of IIO output
> >> signal
> >> + names indexed by the first cell in the IIO
> >> specifier.
> >> + However, the meaning of io-channel-output-names is
> >> domain
> >> + specific to the IIO provider, and is only provided
> >> to
> >> + encourage using the same meaning for the majority
> >> of IIO
> >> + providers. This format may not work for IIO
> >> providers
> >> + using a complex IIO specifier format. In those
> >> cases it
> >> + is recommended to omit this property and create a
> >> binding
> >> + specific names property.
> >> +
> >> + IIO consumer nodes must never directly reference
> >> + the provider's io-channel-output-names property.
> >> +
> >> +For example:
> >> +
> >> +adc: adc@35 {
> >> + compatible = "maxim,max1139";
> >> + reg = <0x35>;
> >> +#io-channel-cells = <1>;
> >> +io-channel-output-names = "adc1", "adc2";
> >> +};
> >> +
> >> +- this node defines a device with two named IIO outputs, the first
> >> named
> >> + "adc1" and the second named "adc2". Consumer nodes always reference
> >> + IIO channels by index. The names should reflect the IIO output
> >> signal
> >> + names for the device.
> >> +
> >> +==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 #clock-cells, then
> >> + only the phandle portion of the pair will appear.
> >> +
> >> +Opt
Re: [RFC 10/11] iio: Add OF support
On 02/03/2013 11:52 AM, Lars-Peter Clausen wrote:
> On 02/03/2013 12:47 PM, Lars-Peter Clausen wrote:
>> On 02/03/2013 12:39 PM, Jonathan Cameron wrote:
>>> On 02/02/2013 04:10 PM, Guenter Roeck wrote:
On Sat, Feb 02, 2013 at 10:29:02AM +, Jonathan Cameron wrote:
> On 01/31/2013 09:43 PM, Guenter Roeck wrote:
>> Provide bindings, new API access functions, and parse OF data
>> during initialization.
>>
> Firstly thanks for working on this Guenter, it's been a big hole
> for a while largely because non of our largest developers were
> actually using development platforms with device tree support.
>
> Given my knowledge of device tree is based on the odd article
> and looking at similar sets of bindings this morning, my comments
> are likely to be somewhat superficial and uninformed ;)
>
> Mostly on this one I'll take a back seat and let those who
> know this stuff better come to a consensus.
>
> Jonathan
>
>> Signed-off-by: Guenter Roeck
>> ---
>> .../devicetree/bindings/iio/iio-bindings.txt | 97
>> drivers/iio/inkern.c | 241
>>
>> include/linux/iio/consumer.h |8 +
>> 3 files changed, 299 insertions(+), 47 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/iio/iio-bindings.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
>> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
>> new file mode 100644
>> index 000..0f51c95
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
>> @@ -0,0 +1,97 @@
>> +This binding is a work-in-progress, and are based on clock bindings and
>> +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 more 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 clock 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.
>> +
>> +Optional properties:
>> +io-channel-output-names:
>> +Recommended to be a list of strings of IIO output
>> signal
>> +names indexed by the first cell in the IIO
>> specifier.
>> +However, the meaning of io-channel-output-names is
>> domain
>> +specific to the IIO provider, and is only provided
>> to
>> +encourage using the same meaning for the majority
>> of IIO
>> +providers. This format may not work for IIO
>> providers
>> +using a complex IIO specifier format. In those
>> cases it
>> +is recommended to omit this property and create a
>> binding
>> +specific names property.
>> +
>> +IIO consumer nodes must never directly reference
>> +the provider's io-channel-output-names property.
>> +
>> +For example:
>> +
>> +adc: adc@35 {
>> +compatible = "maxim,max1139";
>> +reg = <0x35>;
>> +#io-channel-cells = <1>;
>> +io-channel-output-names = "adc1", "adc2";
>> +};
>> +
>> +- this node defines a device with two named IIO outputs, the first named
>> + "adc1" and the second named "adc2". Consumer nodes always reference
>> + IIO channels by index. The names should reflect the IIO output signal
>> + names for the device.
>> +
>> +==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 #clock-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
>
Re: [RFC 10/11] iio: Add OF support
On 02/03/2013 12:47 PM, Lars-Peter Clausen wrote:
> On 02/03/2013 12:39 PM, Jonathan Cameron wrote:
>> On 02/02/2013 04:10 PM, Guenter Roeck wrote:
>>> On Sat, Feb 02, 2013 at 10:29:02AM +, Jonathan Cameron wrote:
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Provide bindings, new API access functions, and parse OF data
> during initialization.
>
Firstly thanks for working on this Guenter, it's been a big hole
for a while largely because non of our largest developers were
actually using development platforms with device tree support.
Given my knowledge of device tree is based on the odd article
and looking at similar sets of bindings this morning, my comments
are likely to be somewhat superficial and uninformed ;)
Mostly on this one I'll take a back seat and let those who
know this stuff better come to a consensus.
Jonathan
> Signed-off-by: Guenter Roeck
> ---
> .../devicetree/bindings/iio/iio-bindings.txt | 97
> drivers/iio/inkern.c | 241
>
> include/linux/iio/consumer.h |8 +
> 3 files changed, 299 insertions(+), 47 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> new file mode 100644
> index 000..0f51c95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -0,0 +1,97 @@
> +This binding is a work-in-progress, and are based on clock bindings and
> +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 more 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 clock 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.
> +
> +Optional properties:
> +io-channel-output-names:
> + Recommended to be a list of strings of IIO output signal
> + names indexed by the first cell in the IIO specifier.
> + However, the meaning of io-channel-output-names is domain
> + specific to the IIO provider, and is only provided to
> + encourage using the same meaning for the majority of IIO
> + providers. This format may not work for IIO providers
> + using a complex IIO specifier format. In those cases it
> + is recommended to omit this property and create a binding
> + specific names property.
> +
> + IIO consumer nodes must never directly reference
> + the provider's io-channel-output-names property.
> +
> +For example:
> +
> +adc: adc@35 {
> + compatible = "maxim,max1139";
> + reg = <0x35>;
> +#io-channel-cells = <1>;
> +io-channel-output-names = "adc1", "adc2";
> +};
> +
> +- this node defines a device with two named IIO outputs, the first named
> + "adc1" and the second named "adc2". Consumer nodes always reference
> + IIO channels by index. The names should reflect the IIO output signal
> + names for the device.
> +
> +==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 #clock-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>;
>
Re: [RFC 10/11] iio: Add OF support
On 02/03/2013 12:39 PM, Jonathan Cameron wrote:
> On 02/02/2013 04:10 PM, Guenter Roeck wrote:
>> On Sat, Feb 02, 2013 at 10:29:02AM +, Jonathan Cameron wrote:
>>> On 01/31/2013 09:43 PM, Guenter Roeck wrote:
Provide bindings, new API access functions, and parse OF data
during initialization.
>>> Firstly thanks for working on this Guenter, it's been a big hole
>>> for a while largely because non of our largest developers were
>>> actually using development platforms with device tree support.
>>>
>>> Given my knowledge of device tree is based on the odd article
>>> and looking at similar sets of bindings this morning, my comments
>>> are likely to be somewhat superficial and uninformed ;)
>>>
>>> Mostly on this one I'll take a back seat and let those who
>>> know this stuff better come to a consensus.
>>>
>>> Jonathan
>>>
Signed-off-by: Guenter Roeck
---
.../devicetree/bindings/iio/iio-bindings.txt | 97
drivers/iio/inkern.c | 241
include/linux/iio/consumer.h |8 +
3 files changed, 299 insertions(+), 47 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000..0f51c95
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,97 @@
+This binding is a work-in-progress, and are based on clock bindings and
+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 more 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 clock 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.
+
+Optional properties:
+io-channel-output-names:
+ Recommended to be a list of strings of IIO output signal
+ names indexed by the first cell in the IIO specifier.
+ However, the meaning of io-channel-output-names is domain
+ specific to the IIO provider, and is only provided to
+ encourage using the same meaning for the majority of IIO
+ providers. This format may not work for IIO providers
+ using a complex IIO specifier format. In those cases it
+ is recommended to omit this property and create a binding
+ specific names property.
+
+ IIO consumer nodes must never directly reference
+ the provider's io-channel-output-names property.
+
+For example:
+
+adc: adc@35 {
+ compatible = "maxim,max1139";
+ reg = <0x35>;
+#io-channel-cells = <1>;
+io-channel-output-names = "adc1", "adc2";
+};
+
+- this node defines a device with two named IIO outputs, the first named
+ "adc1" and the second named "adc2". Consumer nodes always reference
+ IIO channels by index. The names should reflect the IIO output signal
+ names for the device.
+
+==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 #clock-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
Re: [RFC 10/11] iio: Add OF support
On 02/02/2013 04:10 PM, Guenter Roeck wrote:
> On Sat, Feb 02, 2013 at 10:29:02AM +, Jonathan Cameron wrote:
>> On 01/31/2013 09:43 PM, Guenter Roeck wrote:
>>> Provide bindings, new API access functions, and parse OF data
>>> during initialization.
>>>
>> Firstly thanks for working on this Guenter, it's been a big hole
>> for a while largely because non of our largest developers were
>> actually using development platforms with device tree support.
>>
>> Given my knowledge of device tree is based on the odd article
>> and looking at similar sets of bindings this morning, my comments
>> are likely to be somewhat superficial and uninformed ;)
>>
>> Mostly on this one I'll take a back seat and let those who
>> know this stuff better come to a consensus.
>>
>> Jonathan
>>
>>> Signed-off-by: Guenter Roeck
>>> ---
>>> .../devicetree/bindings/iio/iio-bindings.txt | 97
>>> drivers/iio/inkern.c | 241
>>>
>>> include/linux/iio/consumer.h |8 +
>>> 3 files changed, 299 insertions(+), 47 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
>>> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
>>> new file mode 100644
>>> index 000..0f51c95
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
>>> @@ -0,0 +1,97 @@
>>> +This binding is a work-in-progress, and are based on clock bindings and
>>> +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 more 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 clock 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.
>>> +
>>> +Optional properties:
>>> +io-channel-output-names:
>>> + Recommended to be a list of strings of IIO output signal
>>> + names indexed by the first cell in the IIO specifier.
>>> + However, the meaning of io-channel-output-names is domain
>>> + specific to the IIO provider, and is only provided to
>>> + encourage using the same meaning for the majority of IIO
>>> + providers. This format may not work for IIO providers
>>> + using a complex IIO specifier format. In those cases it
>>> + is recommended to omit this property and create a binding
>>> + specific names property.
>>> +
>>> + IIO consumer nodes must never directly reference
>>> + the provider's io-channel-output-names property.
>>> +
>>> +For example:
>>> +
>>> +adc: adc@35 {
>>> + compatible = "maxim,max1139";
>>> + reg = <0x35>;
>>> +#io-channel-cells = <1>;
>>> +io-channel-output-names = "adc1", "adc2";
>>> +};
>>> +
>>> +- this node defines a device with two named IIO outputs, the first named
>>> + "adc1" and the second named "adc2". Consumer nodes always reference
>>> + IIO channels by index. The names should reflect the IIO output signal
>>> + names for the device.
>>> +
>>> +==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 #clock-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 devi
Re: [RFC 10/11] iio: Add OF support
On Sat, Feb 02, 2013 at 03:37:46PM +0100, Lars-Peter Clausen wrote: > On 02/01/2013 08:42 PM, Guenter Roeck wrote: > > On Fri, Feb 01, 2013 at 03:59:17PM +0100, Lars-Peter Clausen wrote: > >> On 02/01/2013 03:33 PM, Guenter Roeck wrote: > >>> On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote: > 013 10:43 PM, Guenter Roeck wrote: > > Provide bindings, new API access functions, and parse OF data > > during initialization. > > > > Hi Guenter, > > Thanks for taking care of this. > > I'd prefer to have only one iio_get_channel which handles both the dt > and the > non-dt case. Otherwise we'll soon have constructs like > > if (dev->of_node) > chan = of_iio_get_channel(dev->of_node, 1); > else > chan = iio_get_channel(dev_name(dev), "vcc"); > > > > > Clock code has of_clk_get_by_name(node *, name), clk_get(dev, name), and > > of_clk_get(node *, index). Right now of_iio_get_channel matches of_clk_get, > > and iio_get_channel matches clk_get. > > > > Question is really how we want to API to look like. I am open to > > suggestions. > > I'm not necessarily against having a separate of_iio_get_channe function, but > I'm not sure if we really need it, maybe use it internally as a helper and if > we really need it in some driver make it public and export it. clk_get first > calls of_clk_get_by_name, and only if didn't find a clk it falls back to the > map based lookup. I think iio_get_channel should behave the similar. > of_clk_get > is kind of just a helper function for of_clk_get_by_name, not sure if we need > it as a separate function in IIO. If we find out we need it we can probably > still add it later. > You are right. If I modify iio_get_channel to take the device pointer as argument, it should work for both OF and non-OF with the approach you outlined above. Thanks, Guenter ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 10/11] iio: Add OF support
On Sat, Feb 02, 2013 at 10:29:02AM +, Jonathan Cameron wrote:
> On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> > Provide bindings, new API access functions, and parse OF data
> > during initialization.
> >
> Firstly thanks for working on this Guenter, it's been a big hole
> for a while largely because non of our largest developers were
> actually using development platforms with device tree support.
>
> Given my knowledge of device tree is based on the odd article
> and looking at similar sets of bindings this morning, my comments
> are likely to be somewhat superficial and uninformed ;)
>
> Mostly on this one I'll take a back seat and let those who
> know this stuff better come to a consensus.
>
> Jonathan
>
> > Signed-off-by: Guenter Roeck
> > ---
> > .../devicetree/bindings/iio/iio-bindings.txt | 97
> > drivers/iio/inkern.c | 241
> >
> > include/linux/iio/consumer.h |8 +
> > 3 files changed, 299 insertions(+), 47 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> > b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> > new file mode 100644
> > index 000..0f51c95
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> > @@ -0,0 +1,97 @@
> > +This binding is a work-in-progress, and are based on clock bindings and
> > +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 more 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 clock 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.
> > +
> > +Optional properties:
> > +io-channel-output-names:
> > + Recommended to be a list of strings of IIO output signal
> > + names indexed by the first cell in the IIO specifier.
> > + However, the meaning of io-channel-output-names is domain
> > + specific to the IIO provider, and is only provided to
> > + encourage using the same meaning for the majority of IIO
> > + providers. This format may not work for IIO providers
> > + using a complex IIO specifier format. In those cases it
> > + is recommended to omit this property and create a binding
> > + specific names property.
> > +
> > + IIO consumer nodes must never directly reference
> > + the provider's io-channel-output-names property.
> > +
> > +For example:
> > +
> > +adc: adc@35 {
> > + compatible = "maxim,max1139";
> > + reg = <0x35>;
> > +#io-channel-cells = <1>;
> > +io-channel-output-names = "adc1", "adc2";
> > +};
> > +
> > +- this node defines a device with two named IIO outputs, the first named
> > + "adc1" and the second named "adc2". Consumer nodes always reference
> > + IIO channels by index. The names should reflect the IIO output signal
> > + names for the device.
> > +
> > +==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 #clock-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@3
Re: [RFC 10/11] iio: Add OF support
On 02/01/2013 08:42 PM, Guenter Roeck wrote:
> On Fri, Feb 01, 2013 at 03:59:17PM +0100, Lars-Peter Clausen wrote:
>> On 02/01/2013 03:33 PM, Guenter Roeck wrote:
>>> On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote:
013 10:43 PM, Guenter Roeck wrote:
> Provide bindings, new API access functions, and parse OF data
> during initialization.
>
Hi Guenter,
Thanks for taking care of this.
I'd prefer to have only one iio_get_channel which handles both the dt and
the
non-dt case. Otherwise we'll soon have constructs like
if (dev->of_node)
chan = of_iio_get_channel(dev->of_node, 1);
else
chan = iio_get_channel(dev_name(dev), "vcc");
>
> Clock code has of_clk_get_by_name(node *, name), clk_get(dev, name), and
> of_clk_get(node *, index). Right now of_iio_get_channel matches of_clk_get,
> and iio_get_channel matches clk_get.
>
> Question is really how we want to API to look like. I am open to suggestions.
I'm not necessarily against having a separate of_iio_get_channe function, but
I'm not sure if we really need it, maybe use it internally as a helper and if
we really need it in some driver make it public and export it. clk_get first
calls of_clk_get_by_name, and only if didn't find a clk it falls back to the
map based lookup. I think iio_get_channel should behave the similar. of_clk_get
is kind of just a helper function for of_clk_get_by_name, not sure if we need
it as a separate function in IIO. If we find out we need it we can probably
still add it later.
- Lars
>
appearing all over the place in drivers code. I'd keep the actual
implementation pretty close to what the clk framework does. E.g. take a
look at
of_clk_get_by_name() and clk_get() in clkdev.c. And don't take a detour
via the
iio_map lookup for the devicetree case, just loop over all IIO devices and
match by of_node. This should allow us to simplify the code quite a bit.
>>> Yes, I just could not figure out how to loop over the list of iio devices.
>>> That
>>> is why I hijacked iio_map which does provide a list.
>>>
>>> Any hints ?
>>
>> Yes, use bus_find_device on iio_bus_type. A nice example how to use this to
>> lookup device by of node is of_find_i2c_device_by_node. For IIO you also need
>> to make sure that dev->type is iio_dev_type, since both devices and triggers
>> are registered on the same bus.
>>
> Great, that works nicely, and, yes, the code is now much simpler.
>
> +static struct iio_map *iio_map_of_init(struct iio_dev *idev)
> +{
To be honest I find this whole function a bit confusing. If we are using
devicetree, we shouldn't need to register iio_map. Maybe just skip over
io-channel-output-names for now, until we figure out if we really need
this and
what for.
> Correct, I don't need this anymore after implementing the above.
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 10/11] iio: Add OF support
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Provide bindings, new API access functions, and parse OF data
> during initialization.
>
Firstly thanks for working on this Guenter, it's been a big hole
for a while largely because non of our largest developers were
actually using development platforms with device tree support.
Given my knowledge of device tree is based on the odd article
and looking at similar sets of bindings this morning, my comments
are likely to be somewhat superficial and uninformed ;)
Mostly on this one I'll take a back seat and let those who
know this stuff better come to a consensus.
Jonathan
> Signed-off-by: Guenter Roeck
> ---
> .../devicetree/bindings/iio/iio-bindings.txt | 97
> drivers/iio/inkern.c | 241
>
> include/linux/iio/consumer.h |8 +
> 3 files changed, 299 insertions(+), 47 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> new file mode 100644
> index 000..0f51c95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -0,0 +1,97 @@
> +This binding is a work-in-progress, and are based on clock bindings and
> +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 more 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 clock 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.
> +
> +Optional properties:
> +io-channel-output-names:
> + Recommended to be a list of strings of IIO output signal
> + names indexed by the first cell in the IIO specifier.
> + However, the meaning of io-channel-output-names is domain
> + specific to the IIO provider, and is only provided to
> + encourage using the same meaning for the majority of IIO
> + providers. This format may not work for IIO providers
> + using a complex IIO specifier format. In those cases it
> + is recommended to omit this property and create a binding
> + specific names property.
> +
> + IIO consumer nodes must never directly reference
> + the provider's io-channel-output-names property.
> +
> +For example:
> +
> +adc: adc@35 {
> + compatible = "maxim,max1139";
> + reg = <0x35>;
> +#io-channel-cells = <1>;
> +io-channel-output-names = "adc1", "adc2";
> +};
> +
> +- this node defines a device with two named IIO outputs, the first named
> + "adc1" and the second named "adc2". Consumer nodes always reference
> + IIO channels by index. The names should reflect the IIO output signal
> + names for the device.
> +
> +==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 #clock-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>, <
Re: [RFC 10/11] iio: Add OF support
On Fri, Feb 01, 2013 at 03:59:17PM +0100, Lars-Peter Clausen wrote:
> On 02/01/2013 03:33 PM, Guenter Roeck wrote:
> > On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote:
> >> 013 10:43 PM, Guenter Roeck wrote:
> >>> Provide bindings, new API access functions, and parse OF data
> >>> during initialization.
> >>>
> >>
> >> Hi Guenter,
> >>
> >> Thanks for taking care of this.
> >>
> >> I'd prefer to have only one iio_get_channel which handles both the dt and
> >> the
> >> non-dt case. Otherwise we'll soon have constructs like
> >>
> >> if (dev->of_node)
> >>chan = of_iio_get_channel(dev->of_node, 1);
> >> else
> >>chan = iio_get_channel(dev_name(dev), "vcc");
> >>
Clock code has of_clk_get_by_name(node *, name), clk_get(dev, name), and
of_clk_get(node *, index). Right now of_iio_get_channel matches of_clk_get,
and iio_get_channel matches clk_get.
Question is really how we want to API to look like. I am open to suggestions.
> >> appearing all over the place in drivers code. I'd keep the actual
> >> implementation pretty close to what the clk framework does. E.g. take a
> >> look at
> >> of_clk_get_by_name() and clk_get() in clkdev.c. And don't take a detour
> >> via the
> >> iio_map lookup for the devicetree case, just loop over all IIO devices and
> >> match by of_node. This should allow us to simplify the code quite a bit.
> >>
> > Yes, I just could not figure out how to loop over the list of iio devices.
> > That
> > is why I hijacked iio_map which does provide a list.
> >
> > Any hints ?
>
> Yes, use bus_find_device on iio_bus_type. A nice example how to use this to
> lookup device by of node is of_find_i2c_device_by_node. For IIO you also need
> to make sure that dev->type is iio_dev_type, since both devices and triggers
> are registered on the same bus.
>
Great, that works nicely, and, yes, the code is now much simpler.
> >>> +static struct iio_map *iio_map_of_init(struct iio_dev *idev)
> >>> +{
> >>
> >> To be honest I find this whole function a bit confusing. If we are using
> >> devicetree, we shouldn't need to register iio_map. Maybe just skip over
> >> io-channel-output-names for now, until we figure out if we really need
> >> this and
> >> what for.
> >>
Correct, I don't need this anymore after implementing the above.
Thanks,
Guenter
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 10/11] iio: Add OF support
On 02/01/2013 03:33 PM, Guenter Roeck wrote:
> On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote:
>> 013 10:43 PM, Guenter Roeck wrote:
>>> Provide bindings, new API access functions, and parse OF data
>>> during initialization.
>>>
>>
>> Hi Guenter,
>>
>> Thanks for taking care of this.
>>
>> I'd prefer to have only one iio_get_channel which handles both the dt and the
>> non-dt case. Otherwise we'll soon have constructs like
>>
>> if (dev->of_node)
>> chan = of_iio_get_channel(dev->of_node, 1);
>> else
>> chan = iio_get_channel(dev_name(dev), "vcc");
>>
>> appearing all over the place in drivers code. I'd keep the actual
>> implementation pretty close to what the clk framework does. E.g. take a look
>> at
>> of_clk_get_by_name() and clk_get() in clkdev.c. And don't take a detour via
>> the
>> iio_map lookup for the devicetree case, just loop over all IIO devices and
>> match by of_node. This should allow us to simplify the code quite a bit.
>>
> Yes, I just could not figure out how to loop over the list of iio devices.
> That
> is why I hijacked iio_map which does provide a list.
>
> Any hints ?
Yes, use bus_find_device on iio_bus_type. A nice example how to use this to
lookup device by of node is of_find_i2c_device_by_node. For IIO you also need
to make sure that dev->type is iio_dev_type, since both devices and triggers
are registered on the same bus.
>
> Thanks,
> Guenter
>
>> - Lars
>>
>> On 01/31/2
>>
>>> Signed-off-by: Guenter Roeck
>>> ---
>>> .../devicetree/bindings/iio/iio-bindings.txt | 97
>>> drivers/iio/inkern.c | 241
>>>
>>> include/linux/iio/consumer.h |8 +
>>> 3 files changed, 299 insertions(+), 47 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
>>> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
>>> new file mode 100644
>>> index 000..0f51c95
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
>>> @@ -0,0 +1,97 @@
>>> +This binding is a work-in-progress, and are based on clock bindings and
>>> +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 more 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 clock 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.
>>> +
>>> +Optional properties:
>>> +io-channel-output-names:
>>> + Recommended to be a list of strings of IIO output signal
>>> + names indexed by the first cell in the IIO specifier.
>>> + However, the meaning of io-channel-output-names is domain
>>> + specific to the IIO provider, and is only provided to
>>> + encourage using the same meaning for the majority of IIO
>>> + providers. This format may not work for IIO providers
>>> + using a complex IIO specifier format. In those cases it
>>> + is recommended to omit this property and create a binding
>>> + specific names property.
>>> +
>>> + IIO consumer nodes must never directly reference
>>> + the provider's io-channel-output-names property.
>>> +
>>> +For example:
>>> +
>>> +adc: adc@35 {
>>> + compatible = "maxim,max1139";
>>> + reg = <0x35>;
>>> +#io-channel-cells = <1>;
>>> +io-channel-output-names = "adc1", "adc2";
>>> +};
>>> +
>>> +- this node defines a device with two named IIO outputs, the first named
>>> + "adc1" and the second named "adc2". Consumer nodes always reference
>>> + IIO channels by index. The names should reflect the IIO output signal
>>> + names for the device.
>>> +
>>> +==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 #clock-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
>>> +
Re: [RFC 10/11] iio: Add OF support
On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote:
> 013 10:43 PM, Guenter Roeck wrote:
> > Provide bindings, new API access functions, and parse OF data
> > during initialization.
> >
>
> Hi Guenter,
>
> Thanks for taking care of this.
>
> I'd prefer to have only one iio_get_channel which handles both the dt and the
> non-dt case. Otherwise we'll soon have constructs like
>
> if (dev->of_node)
> chan = of_iio_get_channel(dev->of_node, 1);
> else
> chan = iio_get_channel(dev_name(dev), "vcc");
>
> appearing all over the place in drivers code. I'd keep the actual
> implementation pretty close to what the clk framework does. E.g. take a look
> at
> of_clk_get_by_name() and clk_get() in clkdev.c. And don't take a detour via
> the
> iio_map lookup for the devicetree case, just loop over all IIO devices and
> match by of_node. This should allow us to simplify the code quite a bit.
>
Yes, I just could not figure out how to loop over the list of iio devices. That
is why I hijacked iio_map which does provide a list.
Any hints ?
Thanks,
Guenter
> - Lars
>
> On 01/31/2
>
> > Signed-off-by: Guenter Roeck
> > ---
> > .../devicetree/bindings/iio/iio-bindings.txt | 97
> > drivers/iio/inkern.c | 241
> >
> > include/linux/iio/consumer.h |8 +
> > 3 files changed, 299 insertions(+), 47 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> > b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> > new file mode 100644
> > index 000..0f51c95
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> > @@ -0,0 +1,97 @@
> > +This binding is a work-in-progress, and are based on clock bindings and
> > +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 more 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 clock 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.
> > +
> > +Optional properties:
> > +io-channel-output-names:
> > + Recommended to be a list of strings of IIO output signal
> > + names indexed by the first cell in the IIO specifier.
> > + However, the meaning of io-channel-output-names is domain
> > + specific to the IIO provider, and is only provided to
> > + encourage using the same meaning for the majority of IIO
> > + providers. This format may not work for IIO providers
> > + using a complex IIO specifier format. In those cases it
> > + is recommended to omit this property and create a binding
> > + specific names property.
> > +
> > + IIO consumer nodes must never directly reference
> > + the provider's io-channel-output-names property.
> > +
> > +For example:
> > +
> > +adc: adc@35 {
> > + compatible = "maxim,max1139";
> > + reg = <0x35>;
> > +#io-channel-cells = <1>;
> > +io-channel-output-names = "adc1", "adc2";
> > +};
> > +
> > +- this node defines a device with two named IIO outputs, the first named
> > + "adc1" and the second named "adc2". Consumer nodes always reference
> > + IIO channels by index. The names should reflect the IIO output signal
> > + names for the device.
> > +
> > +==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 #clock-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:
> >
Re: [RFC 10/11] iio: Add OF support
013 10:43 PM, Guenter Roeck wrote:
> Provide bindings, new API access functions, and parse OF data
> during initialization.
>
Hi Guenter,
Thanks for taking care of this.
I'd prefer to have only one iio_get_channel which handles both the dt and the
non-dt case. Otherwise we'll soon have constructs like
if (dev->of_node)
chan = of_iio_get_channel(dev->of_node, 1);
else
chan = iio_get_channel(dev_name(dev), "vcc");
appearing all over the place in drivers code. I'd keep the actual
implementation pretty close to what the clk framework does. E.g. take a look at
of_clk_get_by_name() and clk_get() in clkdev.c. And don't take a detour via the
iio_map lookup for the devicetree case, just loop over all IIO devices and
match by of_node. This should allow us to simplify the code quite a bit.
- Lars
On 01/31/2
> Signed-off-by: Guenter Roeck
> ---
> .../devicetree/bindings/iio/iio-bindings.txt | 97
> drivers/iio/inkern.c | 241
>
> include/linux/iio/consumer.h |8 +
> 3 files changed, 299 insertions(+), 47 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/iio-bindings.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> new file mode 100644
> index 000..0f51c95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -0,0 +1,97 @@
> +This binding is a work-in-progress, and are based on clock bindings and
> +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 more 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 clock 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.
> +
> +Optional properties:
> +io-channel-output-names:
> + Recommended to be a list of strings of IIO output signal
> + names indexed by the first cell in the IIO specifier.
> + However, the meaning of io-channel-output-names is domain
> + specific to the IIO provider, and is only provided to
> + encourage using the same meaning for the majority of IIO
> + providers. This format may not work for IIO providers
> + using a complex IIO specifier format. In those cases it
> + is recommended to omit this property and create a binding
> + specific names property.
> +
> + IIO consumer nodes must never directly reference
> + the provider's io-channel-output-names property.
> +
> +For example:
> +
> +adc: adc@35 {
> + compatible = "maxim,max1139";
> + reg = <0x35>;
> +#io-channel-cells = <1>;
> +io-channel-output-names = "adc1", "adc2";
> +};
> +
> +- this node defines a device with two named IIO outputs, the first named
> + "adc1" and the second named "adc2". Consumer nodes always reference
> + IIO channels by index. The names should reflect the IIO output signal
> + names for the device.
> +
> +==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 #clock-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";
