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

[Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>]

On Sun, Feb 03, 2013 at 12:29:23PM +0100, Lars-Peter Clausen wrote:
> 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-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
> >>> ---
> >>> - 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@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@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.
> 
iio_dev_type is defined as static variable in industrialio-core.c, which can be
loaded as module. To use it in inkern.c, I would have to move it there and make
it global. I can do that, but is it worth it just to safe the strcmp ?

Thanks,
Guenter