On 02/03/2013 12:52 PM, 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. But we do some_dev->of_node = some_other_dev->of_node, all over the place. How is that different? - Lars -- 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
