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@xxxxxxxxxxxx> > >>>>>>> --- > >>>>>>> - 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 = <®_3p3v>; > >> vref-supply = <®_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 = <®_3p3v>; > > vref-supply = <®_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 = <®_3p3v>; vref-supply = <®_3p3v>; #io-channel-cells = <1>; }; For multiple subdevices: voltage-sensor@35 { compatible = "maxim,max1139"; reg = <0x35>; vcc-supply = <®_3p3v>; vref-supply = <®_3p3v>; subdevice1 { /* Subdevice specific data */ #io-channel-cells = <1>; }; subdevice2 { /* Subdevice specific data */ #io-channel-cells = <1>; } }; Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
