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. > >>> +} > >>> + > >>> +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. OK. I'm not much into IIO, so my suggestion was based entirely on what other subsystems do. 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
