[PATCH v2 4/4] iio: Add OF support
Guenter Roeck
linux at roeck-us.net
Tue Feb 5 04:12:14 EST 2013
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 at roeck-us.net>
> > >>>>>>> ---
> > >>>>>>> - 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 at 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 at 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 at 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 at 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 at 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 at 35 {
> compatible = "maxim,max1139";
> reg = <0x35>;
> vcc-supply = <®_3p3v>;
> vref-supply = <®_3p3v>;
> #io-channel-cells = <1>;
> };
>
> For multiple subdevices:
>
> voltage-sensor at 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>;
> }
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 at 35 {
compatible = "maxim,max1139";
iio-device;
reg = <0x35>;
vcc-supply = <®_3p3v>;
vref-supply = <®_3p3v>;
#io-channel-cells = <1>;
};
Thanks,
Guenter
More information about the devicetree-discuss
mailing list