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

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

On Mon, Feb 04, 2013 at 07:00:55PM +0100, Tomasz Figa wrote:
> On Monday 04 of February 2013 09:51:34 Guenter Roeck wrote:
> > On Mon, Feb 04, 2013 at 09:12:14AM -0800, Guenter Roeck wrote:
> > > On Mon, Feb 04, 2013 at 12:14:52AM +0100, Tomasz Figa wrote:
> > > > On Sunday 03 of February 2013 19:55:47 Lars-Peter Clausen wrote:
> > > > > On 02/03/2013 06:30 PM, Tomasz Figa wrote:
> > > > > > On Sunday 03 of February 2013 09:01:07 Guenter Roeck wrote:
> > > > > >> On Sun, Feb 03, 2013 at 12:52:40PM +0100, Tomasz Figa wrote:
> > > > > >>> On Sunday 03 of February 2013 12:29:23 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.
> > > > > >>> 
> > > > > >>> I must disagree.
> > > > > >>> 
> > > > > >>> If you have two IIO devices provided by one physical device,
> > > > > >>> then in
> > > > > >>> 
> > > > > >>> device tree they should be represented as follows:
> > > > > >>> 	phys-dev@12345678 {
> > > > > >>> 	
> > > > > >>> 		compatible = "some-physical-device";
> > > > > >>> 		/* ... */
> > > > > >>> 		
> > > > > >>> 		my_trig: iio-trigger {
> > > > > >>> 		
> > > > > >>> 			/* ... */
> > > > > >>> 		
> > > > > >>> 		};
> > > > > >>> 		
> > > > > >>> 		my_dev: iio-device {
> > > > > >>> 		
> > > > > >>> 			/* ... */
> > > > > >>> 		
> > > > > >>> 		};
> > > > > >>> 	
> > > > > >>> 	};
> > > > > >>> 
> > > > > >>> Notice that phys-dev works here as an IIO bus on which its IIO
> > > > > >>> devices
> > > > > >>> are available. This is related to the convention that single
> > > > > >>> OF
> > > > > >>> device node represents single device, which would be violated
> > > > > >>> otherwise.
> > > > > >> 
> > > > > >> Right now the iio device is a child of the physical device, and
> > > > > >> I am
> > > > > >> simply passing of_node on to it. guess you are saying that is
> > > > > >> not
> > > > > >> correct ?
> > > > > >> 
> > > > > >> If so, what would be the correct approach ? Something like the
> > > > > >> following ?
> > > > > >> 
> > > > > >> 	voltage-sensor@35 {
> > > > > >> 	
> > > > > >> 		compatible = "maxim,max1139";
> > > > > >> 		reg = <0x35>;
> > > > > >> 		vcc-supply = <&reg_3p3v>;
> > > > > >> 		vref-supply = <&reg_3p3v>;
> > > > > >> 		
> > > > > >> 		max1139-iio: iio-device {
> > > > > >> 		
> > > > > >> 			device_type = "iio_device";
> > > > > >> 			#io-channel-cells = <1>;
> > > > > >> 		
> > > > > >> 		};
> > > > > >> 	
> > > > > >> 	};
> > > > > >> 
> > > > > >> and in the driver probe function:
> > > > > >> 	if (parent->of_node)
> > > > > >> 	
> > > > > >> 		iio_dev->dev.of_node = of_find_node_by_type(parent-
> > > > >
> > > > >of_node,
> > > > >
> > > > > >> "iio_device");
> > > > > >> 
> > > > > >> Another option would be to use of_find_compatible_node() and
> > > > > >> something
> > > > > >> like compatible = "iio-device";
> > > > > >> in the iio-device node.
> > > > > > 
> > > > > > A device node is defined as a node having compatible property.
> > > > > > Other
> > > > > > nodes should be seen as helper nodes, which do not represent
> > > > > > devices
> > > > > > (although they all have struct device_node in Linux).
> > > > > > 
> > > > > > Also, AFAIK, device_type is a deprecated property used by some
> > > > > > legacy
> > > > > > PowerPC machines and for current machines only compatible should
> > > > > > be
> > > > > > used.
> > > > > > 
> > > > > > So I guess the approach with compatible would be appropriate
> > > > > > here.
> > > > > > 
> > > > > > However for physical devices providing only a single IIO device
> > > > > > it
> > > > > > might>
> > > > > > 
> > > > > > be better to allow simpler specification, like:
> > > > > >  	max1139-iio: voltage-sensor@35 {
> > > > > >  	
> > > > > >  		compatible = "maxim,max1139", "iio_device";
> > > > > 
> > > > > I don't think this makes a lot of sense. First of all iio_device
> > > > > an
> > > > > artificial Linux term, while the device tree should describe the
> > > > > hardware.
> > > > 
> > > > Well, if you look at an iio_device as a subdevice of a physical
> > > > device
> > > > then it should make a bit more sense. (See nodes of GPIO/pinctrl pin
> > > > banks or regulators of a PMIC chip.)
> > > > 
> > > > > Secondly there is no generic iio driver which could match on
> > > > > a node with a "iio_device" compability string and stuff would just
> > > > > work. I mean we don't do
> > > > > 
> > > > > compatible = "atmel,at91sam9260-i2c", "i2c-master";
> > > > > 
> > > > > or similar either.
> > > > 
> > > > Right. We don't need the other compatible for simple devices with
> > > > single subdevice. This is implied by the driver registering a
> > > > single IIO driver using the node of physical device.
> > > > 
> > > > > >  		reg = <0x35>;
> > > > > >  		vcc-supply = <&reg_3p3v>;
> > > > > >  		vref-supply = <&reg_3p3v>;
> > > > > > 		
> > > > > > 		device_type = "iio_device";
> > > > 
> > > > Also we don't need this device_type. Basically we don't need to
> > > > specify
> > > > whether given node is an iio_device or an iio_trigger. It's up to
> > > > the
> > > > driver to register the node as a device or a trigger by setting
> > > > dev.of_node field properly.
> > > > 
> > > > So my suggestion would be to make the bindings as following. For
> > > > single
> > > > 
> > > > subdevice:
> > > > 	voltage-sensor@35 {
> > > > 	
> > > > 		compatible = "maxim,max1139";
> > > > 		reg = <0x35>;
> > > > 		vcc-supply = <&reg_3p3v>;
> > > > 		vref-supply = <&reg_3p3v>;
> > > > 		#io-channel-cells = <1>;
> > > > 	
> > > > 	};
> > > > 
> > > > For multiple subdevices:
> > > > 	voltage-sensor@35 {
> > > > 	
> > > > 		compatible = "maxim,max1139";
> > > > 		reg = <0x35>;
> > > > 		vcc-supply = <&reg_3p3v>;
> > > > 		vref-supply = <&reg_3p3v>;
> > > > 		
> > > > 		subdevice1 {
> > > > 		
> > > > 			/* Subdevice specific data */
> > > > 			#io-channel-cells = <1>;
> > > > 		
> > > > 		};
> > > > 		
> > > > 		subdevice2 {
> > > > 		
> > > > 			/* Subdevice specific data */
> > > > 			#io-channel-cells = <1>;
> > > > 		
> > > > 		}
> > > 
> > > Please provide an example how to parse that. Obviously now I can not
> > > look for "compatible" anymore. Sure, I can use of_get_child_by_name,
> > > but that means the sub-device names would have to be well defined. Or
> > > I could use of_find_node_by_name, but then I would need something
> > > like
> > > 
> > >  	voltage-sensor@35 {
> > >  	
> > >  		compatible = "maxim,max1139";
> > > 		
> > > 		iio-device;
> > > 		
> > >  		reg = <0x35>;
> > >  		vcc-supply = <&reg_3p3v>;
> > >  		vref-supply = <&reg_3p3v>;
> > >  		#io-channel-cells = <1>;
> > >  	
> > >  	};
> > 
> > Never mind. My brain is really too flu-foggy to do anything.
> > 
> > Looks like I can use of_find_node_by_name if subdevice1 and subdevice2
> > have well defined names such as iio-device or iio-trigger. It might
> > even be possible to encode multiple iio subdevices in names such as
> > iio-device@0 and iio-device@1. But that would (or not ?) mean that the
> > names should be something like the following for consistency.
> > 
> > 	iio-device@35 {
> > 		compatible = "maxim,max1139";
> > 		reg = <0x35>;
> > 		vcc-supply = <&reg_3p3v>;
> > 		vref-supply = <&reg_3p3v>;
> > 		#io-channel-cells = <1>;
> > 	};
> > 
> > For multiple subdevices:
> > 
> > 	voltage-sensor@35 {
> > 		compatible = "maxim,max1139";
> > 		reg = <0x35>;
> > 		vcc-supply = <&reg_3p3v>;
> > 		vref-supply = <&reg_3p3v>;
> > 
> > 		iio-device {
> > 			/* Subdevice specific data */
> > 			#io-channel-cells = <1>;
> > 		};
> > 
> > 		iio-trigger {
> > 			/* Subdevice specific data */
> > 			#io-channel-cells = <1>;
> > 		}
> > 
> > Does that make sense ?
> 
> Do you need to parse this from generic code at all?
> 
> A particular IIO device driver gets a pointer to voltage-sensor@35 node in 
> its dev.of_node. In case of a simple device without multiple subdevices, 
> the driver will set the of_node field of iio_device.dev (or 
> iio_trigger.dev) field and register the iio_device using 
> iio_device_register() (or iio_trigger_register()).
> 
> In case of multiple subdevices, the driver (not generic code) will iterate 
> over its child nodes and registers iio_devices and/or iio_triggers with 
> appropriate nodes set in iio_device/iio_trigger structs.
> 
> All the generic code should do is parsing the phandles in client nodes, 
> looking up to which devices they belong and translating phandle arguments 
> to channel numbers.
> 
Ok, I think now I understand (or at least a bit better). That would also solve
the problem mentioned by Jonathan, where a driver for a single chip registers
multiple IIO devices.

Thanks,
Guenter