[PATCH v2 4/4] iio: Add OF support

[Lars-Peter Clausen]

On 02/03/2013 03:06 AM, Guenter Roeck wrote:
> On Sun, Feb 03, 2013 at 02:30:24AM +0100, Tomasz Figa wrote:
>> Hi Guenter,
>>
>> Some comments inline.
>>
>> On Saturday 02 of February 2013 16:59:40 Guenter Roeck wrote:
>>> Provide bindings and parse OF data during initialization.
>>>
>>> Signed-off-by: Guenter Roeck <linux at roeck-us.net>
>>> ---
>>> - Documentation update per feedback
>>> - Dropped io-channel-output-names from the bindings document. The
>>> property is not used in the code, and it is not entirely clear what it
>>> would be used for. If there is a need for it, we can add it back in
>>> later on.
>>> - Don't export OF specific API calls
>>> - For OF support, no longer depend on iio_map
>>> - Add #ifdef CONFIG_OF where appropriate, and ensure that the code still
>>> builds if it is not selected.
>>> - Change iio_channel_get to take device pointer as argument instead of
>>> device name. Retain old API as of_iio_channel_get_sys.
>>> - iio_channel_get now works for both OF and non-OF configurations.
>>>
>>>  .../devicetree/bindings/iio/iio-bindings.txt       |   76 ++++++++
>>>  drivers/iio/inkern.c                               |  186
>>> ++++++++++++++++++++ 2 files changed, 262 insertions(+)
>>>  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 0000000..58df5f6
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
>>> @@ -0,0 +1,76 @@
>>> +This binding is a work-in-progress. It 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 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.
>>> +
>>> +For example:
>>> +
>>> +    adc: adc at 35 {
>>> +	compatible = "maxim,max1139";
>>> +	reg = <0x35>;
>>> +        #io-channel-cells = <1>;
>>> +    };
>>> +
>>> +==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 at 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>, <&adc 10>, <&adc 11>;
>>> +		io-channel-names = "vcc", "vdd", "vref", "1.2V";
>>> +	};
>>> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
>>> index b289915..d48f2a8 100644
>>> --- a/drivers/iio/inkern.c
>>> +++ b/drivers/iio/inkern.c
>>> @@ -10,6 +10,7 @@
>>>  #include <linux/export.h>
>>>  #include <linux/slab.h>
>>>  #include <linux/mutex.h>
>>> +#include <linux/of.h>
>>>
>>>  #include <linux/iio/iio.h>
>>>  #include "iio_core.h"
>>> @@ -92,6 +93,179 @@ static const struct iio_chan_spec
>>>  	return chan;
>>>  }
>>>
>>> +#ifdef CONFIG_OF
>>> +
>>> +static int iio_dev_node_match(struct device *dev, void *data)
>>> +{
>>> +	return !strcmp(dev->type->name, "iio_device") && dev->of_node == 
>> data;
>>
>> Hmm, do you need to check type name here? One device node should rather 
>> represent only one device, making node an unique identifier.
>>
>> It this is meant to be a sanity check, it could be done one time after 
>> finding the device.
>>
> Hi Tomasz,
> 
> This is what Lars had suggested earlier:
> 
>> 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.
> 
> Is it really needed, or in other words would it be sufficient to check if
> of_node and data match each other ? Your reasoning makes sense to me, and I had
> thought about it as well, but I don't really know, and I don't know how I could
> test it and guarantee correctness either. I'll be happy to take the strcmp() out
> if someone tells me that it is definitely not needed ...

A IIO trigger and a IIO device may have the same of_node, e.g. if they both
belong to the same physical device. But you don't need to do the strcmp just
compare dev->type to iio_dev_type i.e. dev->type == &iio_dev_type. Although it
doesn't really matter in practice first check for the of_node then check for
the type, since the of_node will only match for a few devices at most, the type
will match for quite a few.


> 
>>> +}
>>> +
>>> +static struct iio_channel *of_iio_channel_get(struct device_node *np,
>>> int index) +{
>>> +	struct iio_channel *channel;
>>> +	struct device *idev;
>>> +	struct iio_dev *indio_dev;
>>> +	int err;
>>> +	struct of_phandle_args iiospec;
>>> +
>>> +	if (index < 0)
>>> +		return ERR_PTR(-EINVAL);
>>> +
>>> +	err = of_parse_phandle_with_args(np, "io-channels",
>>> +					 "#io-channel-cells",
>>> +					 index, &iiospec);
>>> +	if (err)
>>> +		return ERR_PTR(err);
>>> +
>>> +	idev = bus_find_device(&iio_bus_type, NULL, iiospec.np,
>>> +			       iio_dev_node_match);
>>> +	of_node_put(iiospec.np);
>>> +	if (idev == NULL)
>>> +		return ERR_PTR(-EPROBE_DEFER);
>>> +
>>> +	indio_dev = dev_to_iio_dev(idev);
>>> +
>>> +	channel = kzalloc(sizeof(*channel), GFP_KERNEL);
>>> +	if (channel == NULL) {
>>> +		err = -ENOMEM;
>>> +		goto err_no_mem;
>>> +	}
>>> +
>>> +	channel->indio_dev = indio_dev;
>>> +	index = iiospec.args_count ? iiospec.args[0] : 0;
>>
>> What happens here with remaining phandle arguments?
>>
>> I'm not sure if such use case is needed for iio, but other subsystems give 
>> the possibility of specifying custom xlate callback translating from a 
>> custom specifier into channel number. (e.g. drivers/gpio/gpiolib-of.c)
>>
> I don't have a use case, and I hesitate to implement something that may
> never be used (and I can not really test it either). And without a use
> case we would not even know if the implementation makes sense or not.
> 
> It should be possible to add additional functionality later if needed.
> 

Agreed, if it turns out somebody needs it, we can easily add it later on.

- Lars