MAX1363 IIO driver questions

DISCUSSION Guenter Roeck 5 participants 16 messages Nov 24, 2012 – Jan 29, 2013 IIO

lore

Share & tools

lore

Guenter Roeck

author

2012-11-24 05:27 UTC #0 lore raw

Hi all,

What would it take to move the MAX1363 driver out of staging ?

Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.

Thanks,
Guenter

Jonathan Cameron

maintainer

2012-11-24 10:18 UTC #1 lore raw

Quoted 1 line · Guenter Roeck

Hi all,

Hi Guenter,

Quoted 3 lines

What would it take to move the MAX1363 driver out of staging ?

Nothing given it is already out of staging in linux-next (though only has been for about a week)

Quoted 4 lines

Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.

The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.

Jonathan

Quoted 8 lines

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Guenter Roeck

author

2012-11-24 11:12 UTC #2 lore raw

Quoted 9 lines · Jonathan Cameron

Quoted 1 line · Guenter Roeck
Hi all,
Hi Guenter,
Quoted 3 lines
What would it take to move the MAX1363 driver out of staging ?
Nothing given it is already out of staging in linux-next (though only has been for about a week)

Excellent. Guess I need to check more than once a week :).

Quoted 10 lines

Quoted 4 lines
Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.
The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.

I'll have another look myself.

Thanks,
Guenter

Guenter Roeck

author

2013-01-16 05:49 UTC #3 lore raw

In reply to Jonathan Cameron

Quoted 14 lines · Jonathan Cameron

Quoted 1 line · Guenter Roeck
Hi all,
Hi Guenter,
Quoted 3 lines
What would it take to move the MAX1363 driver out of staging ?
Nothing given it is already out of staging in linux-next (though only has been for about a week)
Quoted 4 lines
Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.

Quoted 5 lines

The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.

Jonathan,

can you educate me how to actually use iio_hwmon ? I get it loaded, which registers the platform driver, but I have no idea how to instantiate it.

Thanks,
Guenter

Jonathan Cameron

2013-01-16 08:41 UTC #4 lore raw

Quoted 20 lines · Guenter Roeck

Quoted 14 lines · Jonathan Cameron
Quoted 1 line · Guenter Roeck
Hi all,
Hi Guenter,
Quoted 3 lines
What would it take to move the MAX1363 driver out of staging ?
Nothing given it is already out of staging in linux-next (though only has been for about a week)
Quoted 4 lines
Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.
Quoted 5 lines
The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.

Quoted 5 lines

Jonathan,
can you educate me how to actually use iio_hwmon ? I get it loaded, which registers the platform driver, but I have no idea how to instantiate it.

http://marc.info/?l=linux-iio&m2933525705497&w=2

[PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.

Should give you a basic example. Clearly a spot of documentation might be in order ;)

Jonathan

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Guenter Roeck

author

2013-01-17 20:45 UTC #5 lore raw

In reply to Guenter Roeck

Quoted 23 lines · Jonathan Cameron

Quoted 22 lines · Guenter Roeck
Quoted 14 lines · Jonathan Cameron
Quoted 1 line · Guenter Roeck
Hi all,
Hi Guenter,
Quoted 3 lines
What would it take to move the MAX1363 driver out of staging ?
Nothing given it is already out of staging in linux-next (though only has been for about a week)
Quoted 4 lines
Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.
Quoted 5 lines
The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.
Jonathan,

Quoted 8 lines

Quoted 3 lines
can you educate me how to actually use iio_hwmon ? I get it loaded, which registers the platform driver, but I have no idea how to instantiate it.
http://marc.info/?l=linux-iio&m2933525705497&w=2
[PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.

Hi Jonathan,

In other words, I can not test it on a PC unless I write a driver to instantiate it. Not too helpful :(. It means that iio drivers can not be used / instantiated for hardware monitoring on PCs.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Jonathan Cameron

2013-01-17 21:03 UTC #6 lore raw

Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...

Signature · 1 line

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Guenter Roeck <[email protected]> wrote:

Quoted 23 lines · Jonathan Cameron

Quoted 22 lines · Guenter Roeck
Quoted 14 lines · Jonathan Cameron
Quoted 1 line · Guenter Roeck
Hi all,
Hi Guenter,
Quoted 3 lines
What would it take to move the MAX1363 driver out of staging ?
Nothing given it is already out of staging in linux-next (though only has been for about a week)
Quoted 4 lines
Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.
Quoted 5 lines
The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.
Jonathan,

Quoted 8 lines

Quoted 3 lines
can you educate me how to actually use iio_hwmon ? I get it loaded, which registers the platform driver, but I have no idea how to instantiate it.
http://marc.info/?l=linux-iio&m=132933525705497&w=2
[PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.

Hi Jonathan,

In other words, I can not test it on a PC unless I write a driver to instantiate it. Not too helpful :(. It means that iio drivers can not be used / instantiated for hardware monitoring on PCs.

Thanks,
Guenter

Jonathan Cameron

maintainer

2013-01-17 21:37 UTC #7 lore raw

Userspace IIO map instantiation [was MAX1363 IIO driver questions]

Thinking about it, this functionality would also be of use to James Peverill as part of his idea for in kernel real time control loops fully configurable from userspace. I've cc'd a few others involved in the original interfaces for setting up these maps.

To take a random stab at how it might work.

Every iio device gains some new interfaces

iio_map_add
iio_map_del

These two take comma separated parameter lists to effectively fill a struct iio_map
so

iio_channel_name,client_device_name,client_channel_name (possibly other punctuation to make it clearer, also we would need to explicitly make the channel names available from userspace which is fine if tedious)

Each of these effectively describes a single channel map and is one conceptual entity so fine as a sysfs attribute.

Probably also need a means to list current maps that are set up, perhaps iio_map_list or similar (ugly: perhaps we can come up with a better way of describing them).

This would then call iio_map_array_register (or a single element variant) to set up the maps.

Now for currently un inserted client modules, these maps will be picked up on insertion just fine. The 'interesting' case would be for modules that are already there. We could define an appropriate callback to be notified of new entries that match the device name. Then the client will have to decide what to do about them. For example the iio to hwmon module would want to add more sysfs attributes for the new channels.

So the questions are

a) is there a better way?
b) what types of driver do something similar already?
c) would something like the above work?

There is a clear use case for something with this functionality (several of them as it turns out) so let us work out how best to proceed.

Jonathan

Quoted 54 lines · Jonathan Cameron

Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...
Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Guenter Roeck <[email protected]> wrote:
On Wed, Jan 16, 2013 at 08:41:45AM +0000, Jonathan Cameron wrote:
> On 16/01/13 05:49, Guenter Roeck wrote:
> >On Sat, Nov 24, 2012 at 10:18:04AM +0000, Jonathan Cameron wrote:
> >>On 11/24/2012 05:27 AM, Guenter Roeck wrote:
> >>>Hi all,
> >>Hi Guenter,
> >>>
> >>>What would it take to move the MAX1363 driver out of staging ? > >>>
> >>Nothing given it is already out of staging in linux-next (though only has been > >>for about a week)
> >>
> >>>Background is that I need a hardware monitoring driver for MAX1139, and would > >>>like to avoid using a driver from staging if possible (after all, it might > >>>go away anytime). Another option would be to submit a hwmon driver for it, >
>>>but that doesn't seem to be the best approach.
> >>
> >>The hwmon driver client driver for iio devices is still in staging, but mainly > >>because I haven't had a chance to take a last look at it before posting it to > >>the hmwon list. IIRC you were more or less happy with what went into staging > >>in the first place, so hopefully not too much left to do.
> >>
> >Jonathan,
> >
> >can you educate me how to actually use iio_hwmon ? I get it loaded, > >which registers the platform driver, but I have no idea how to instantiate it. > >
> http://marc.info/?l=linux-iio&m2933525705497&w=2
>
> [PATCH 6/6] stargate2: example of map configuration for iio to hwmon > example.
>
Hi Jonathan,
In oth
er
words, I can not test it on a PC unless I write a driver to instantiate it. Not too helpful :(. It means that iio drivers can not be used / instantiated for hardware monitoring on PCs.
Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Guenter Roeck

author

2013-01-18 22:09 UTC #8 lore raw

In reply to Jonathan Cameron

Quoted 3 lines · Jonathan Cameron

Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...

Best idea I can come up with is to disconnect iio_hwmon from the requirement to instantiate it explicitly. There might be two sysfs entries - one to attach it to a specific iio device, and one to attach it to individual channels of an iio device. Similar like the new_device interface on i2c adapters, and along the line of

echo max1139 something > /sys/module/iio_hwmon/something_else

and/or

echo max1139 something channel > /sys/module/iio_hwmon/something_else

ie sysfs attributes associated with iio_hwmon, not with the iio device itself.

That would require iio_hwmon to be instantiated automatically, though, as soon as it is loaded, not through the iio device or through platform data and/or through devicetree.

Guenter

Quoted 46 lines

Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Guenter Roeck <[email protected]> wrote:
Quoted 23 lines · Jonathan Cameron
Quoted 22 lines · Guenter Roeck
Quoted 14 lines · Jonathan Cameron
Quoted 1 line · Guenter Roeck
Hi all,
Hi Guenter,
Quoted 3 lines
What would it take to move the MAX1363 driver out of staging ?
Nothing given it is already out of staging in linux-next (though only has been for about a week)
Quoted 4 lines
Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.
Quoted 5 lines
The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.
Jonathan,
Quoted 8 lines
Quoted 3 lines
can you educate me how to actually use iio_hwmon ? I get it loaded, which registers the platform driver, but I have no idea how to instantiate it.
http://marc.info/?l=linux-iio&m=132933525705497&w=2
[PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.
Hi Jonathan,
In other words, I can not test it on a PC unless I write a driver to instantiate it. Not too helpful :(. It means that iio drivers can not be used / instantiated for hardware monitoring on PCs.
Thanks,
Guenter

Jonathan Cameron

maintainer

2013-01-26 11:25 UTC #9 lore raw

Quoted 5 lines · Guenter Roeck

Quoted 3 lines · Jonathan Cameron
Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...

Quoted 7 lines

Best idea I can come up with is to disconnect iio_hwmon from the requirement to instantiate it explicitly. There might be two sysfs entries - one to attach it to a specific iio device, and one to attach it to individual channels of an iio device. Similar like the new_device interface on i2c adapters, and along the line of
echo max1139 something > /sys/module/iio_hwmon/something_else

We'll have to have something more specific or the common case of more than one instance of an adc will cause trouble. Obviously this doesn't matter doing by adding the map from the IIO side.

Quoted 7 lines

and/or
echo max1139 something channel > /sys/module/iio_hwmon/something_else
ie sysfs attributes associated with iio_hwmon, not with the iio device itself.

This will play havock with the way the internal mappings work. Originally we had it mapped from both sides by name (e.g. the map wasn't in any way handled by either driver) but that got an awful lot of flack and really wasn't considered acceptable. The current version of treating it much like regulators etc is much cleaner.

Quoted 3 lines

That would require iio_hwmon to be instantiated automatically, though, as soon as it is loaded, not through the iio device or through platform data and/or through devicetree.

I'm fine with instantiating automatically. There are quite a few bits of
IIO that have to do this for one reason or another. A slightly nasty
but easy to implement form would be to do this in two steps. Have attrs to add the mapping form the IIO side so something like

iio_channel_name : iio_hwmon_device_name, hwmon_channel_name >> /sys/bus/iio/devices/iio:device0/add_client_channel_map (removal by reversing this, but blocked obviously if in use by iio_hwmon)

then (and not sure where the magic hwmon device will sit)

iio_hwmon_device_name >> /sys/bus/iio/devices/iio_hwmon/add_device with a remove_device means of reversing this.

This can then effectively add a platform_device as if we had had the map all along. I kind of like this because it corresponds to the steps that effectively exist for a statically set up mapping.

To take the three possible approaches.

The advantage of doing the mapping form the hwmon side is that there is no need for callbacks etc as the hwmon driver will inherently know the mapping has been updated.

The disadvantage is that we then need to maintain a way of finding the right IIO device and adding the channel map effectively backwards then retrieving it again. That's rather uggly to put it lightly.

Doing it all from the iio device side requires some nasty callbacks to tell the hwmon driver that there are new channels.

The hybrid approach is perhaps the most rigid but does conform to the current standards and interestingly will also allow you to have iio_hwmon devices that have channels from multiple IIO devices (not entirely sure that will actually work right now, but the interface allows for it ;) The nasty here is what we do about attempts to add additional mappings after the iio_hwmon device has been instantiated. Easy approach is probably to just ignore them.. They'll get added to the map, and IFF the hwmon device is removed and readded they'll get picked up.

There are a few fiddly corners with all the approaches. As ever they mostly relate to not undercutting a driver by removing its dependencies. We may need some 'inuse' flags for the map to indicate someone cares about it currently. Not to hard I guess.

So my vote is for a hybrid approach were:

1) mappings are added / removed via attributes that all IIO devices get.
2) iio_hwmon 'instances' are added / removed via attributes in a special control device that will then instantiate the actual hmwon devices. (very much like the way i2c devices can be added or iio's userspace triggers)

How does this sound?

Jonathan

Quoted 46 lines

Quoted 46 lines
Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Guenter Roeck <[email protected]> wrote:
Quoted 23 lines · Jonathan Cameron
Quoted 22 lines · Guenter Roeck
Quoted 14 lines · Jonathan Cameron
Quoted 1 line · Guenter Roeck
Hi all,
Hi Guenter,
Quoted 3 lines
What would it take to move the MAX1363 driver out of staging ?
Nothing given it is already out of staging in linux-next (though only has been for about a week)
Quoted 4 lines
Background is that I need a hardware monitoring driver for MAX1139, and would like to avoid using a driver from staging if possible (after all, it might go away anytime). Another option would be to submit a hwmon driver for it, but that doesn't seem to be the best approach.
Quoted 5 lines
The hwmon driver client driver for iio devices is still in staging, but mainly because I haven't had a chance to take a last look at it before posting it to the hmwon list. IIRC you were more or less happy with what went into staging in the first place, so hopefully not too much left to do.
Jonathan,
Quoted 8 lines
Quoted 3 lines
can you educate me how to actually use iio_hwmon ? I get it loaded, which registers the platform driver, but I have no idea how to instantiate it.
http://marc.info/?l=linux-iio&m=132933525705497&w=2
[PATCH 6/6] stargate2: example of map configuration for iio to hwmon example.
Hi Jonathan,
In other words, I can not test it on a PC unless I write a driver to instantiate it. Not too helpful :(. It means that iio drivers can not be used / instantiated for hardware monitoring on PCs.
Thanks,
Guenter

Guenter Roeck

author

2013-01-29 20:00 UTC #10 lore raw

Quoted 23 lines · Jonathan Cameron

Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Jonathan Cameron
Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...
Quoted 7 lines
Best idea I can come up with is to disconnect iio_hwmon from the requirement to instantiate it explicitly. There might be two sysfs entries - one to attach it to a specific iio device, and one to attach it to individual channels of an iio device. Similar like the new_device interface on i2c adapters, and along the line of
echo max1139 something > /sys/module/iio_hwmon/something_else
We'll have to have something more specific or the common case of more than one instance of an adc will cause trouble. Obviously this doesn't matter doing by adding the map from the IIO side.
Quoted 5 lines
and/or
echo max1139 something channel > /sys/module/iio_hwmon/something_else

Quoted 8 lines

Quoted 2 lines
ie sysfs attributes associated with iio_hwmon, not with the iio device itself.
This will play havock with the way the internal mappings work. Originally we had it mapped from both sides by name (e.g. the map wasn't in any way handled by either driver) but that got an awful lot of flack and really wasn't considered acceptable. The current version of treating it much like regulators etc is much cleaner.

I think I am giving up on testing the code on a non-embedded system; I would need/use manual instantiation only for testing, and it seems too difficult to implement and not really worth it. I'll focus on getting it to work with OF.

The current approach, with iio_hwmon requesting its assigned mappings through io_channel_get_all(), does not work well for me for a number of reasons.

First, it is difficult to associate device references in OF with actual device names. I don't know if you have tried, but while a reference to &iio_hwmon can uniquely identify the device name for an OF entry such as

	iio_hwmon: iio_hwmon@0 {
		compatible = "iio-hwmon";
	};

it is difficult to predict how the actual iio_hwmon device name looks like. Amongst others, it depends if there are additional attributes such as "reg = <>", on the value of "@x" (if specified) and other attributes I have not really tracked down yet. In other words, when I tried to create a device named "iio_hwmon.0", I managed to get all kinds of device names except for "iio_hwmon.0".

Also, the iio_hwmon driver does not know which consumers are assigned to it. If it is instantiated before the ADC driver (which happens all the time for me, as iio_hwmon does not have to wait for the i2c bus adapter), its call to iio_channel_get_all() returns nothing. Even if it does return some mappings, there is no guarantee that the mappings are complete (eg if an instance of iio_hwmon is mapped to ADC channels from multiple chips).

Other subsystems solve that problem by having the consumer request the resources it needs. The leds-gpio driver is an excellent example: It knows from its OF data which gpio pins it needs and requests those. If the pins are not available, it gets an -EPROBE_DEFER error from the gpio subsystem, and simply defers its probe until the missing pins are available.

The question for me is really if it would be possible to implement the same approach for the iio subsystem. I would then specify something like

	max1139: max1139@35 {
        	compatible = "maxim,max1139";
		reg = <0x35>;
	};

...

	iio_hwmon {
		compatible = "iio-hwmon";

		in0 {
			label = "vin";
			iio-map = { &max1139 0 }; /* adc channel 0 */
		};
		in1 {
			label = "vout";
			iio-map = { &max1139 1 }; /* adc channel 1 */
		};
		...
	};

which would then map into in0/in1 hwmon attributes (with optional "vin" and "vout" labels if specified).

Problem here is that io_channel_get() currently does not use the provider name as argument to find the resource. Instead, it uses consumer_dev_name and/or consumer_channel. I am not sure how to solve that problem. It would be much more helpful if the provider would not be tied to the consumer from provider side, but from consumer side, and the mapping would be based on provider device and index (or something else such as ADC channel name if that is preferred).

Would this kind of solution be acceptable for the iio maintainers ? Is it even possible, given that the provider has to currently provide the mapping to its intended consumers using iio_map_array_register() ?

I have a number of additional questions regarding the max1363 driver (eg how to initialize the chip from of data, and if the regulator always _has_ to be vcc), but those are really minor problems we can address later. Right now I'll have to find a solution for the above problems.

Thanks,
Guenter

Lars-Peter Clausen

2013-01-29 20:10 UTC #11 lore raw

Quoted 101 lines · Guenter Roeck

Quoted 23 lines · Jonathan Cameron
Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Jonathan Cameron
Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...
Quoted 7 lines
Best idea I can come up with is to disconnect iio_hwmon from the requirement to instantiate it explicitly. There might be two sysfs entries - one to attach it to a specific iio device, and one to attach it to individual channels of an iio device. Similar like the new_device interface on i2c adapters, and along the line of
echo max1139 something > /sys/module/iio_hwmon/something_else
We'll have to have something more specific or the common case of more than one instance of an adc will cause trouble. Obviously this doesn't matter doing by adding the map from the IIO side.
Quoted 5 lines
and/or
echo max1139 something channel > /sys/module/iio_hwmon/something_else
Quoted 8 lines
Quoted 2 lines
ie sysfs attributes associated with iio_hwmon, not with the iio device itself.
This will play havock with the way the internal mappings work. Originally we had it mapped from both sides by name (e.g. the map wasn't in any way handled by either driver) but that got an awful lot of flack and really wasn't considered acceptable. The current version of treating it much like regulators etc is much cleaner.
I think I am giving up on testing the code on a non-embedded system; I would need/use manual instantiation only for testing, and it seems too difficult to implement and not really worth it. I'll focus on getting it to work with OF.
The current approach, with iio_hwmon requesting its assigned mappings through io_channel_get_all(), does not work well for me for a number of reasons.
First, it is difficult to associate device references in OF with actual device names. I don't know if you have tried, but while a reference to &iio_hwmon can uniquely identify the device name for an OF entry such as
	iio_hwmon: iio_hwmon@0 {
		compatible = "iio-hwmon";
	};
it is difficult to predict how the actual iio_hwmon device name looks like. Amongst others, it depends if there are additional attributes such as "reg = <>", on the value of "@x" (if specified) and other attributes I have not really tracked down yet. In other words, when I tried to create a device named "iio_hwmon.0", I managed to get all kinds of device names except for "iio_hwmon.0".
Also, the iio_hwmon driver does not know which consumers are assigned to it. If it is instantiated before the ADC driver (which happens all the time for me, as iio_hwmon does not have to wait for the i2c bus adapter), its call to iio_channel_get_all() returns nothing. Even if it does return some mappings, there is no guarantee that the mappings are complete (eg if an instance of iio_hwmon is mapped to ADC channels from multiple chips).
Other subsystems solve that problem by having the consumer request the resources it needs. The leds-gpio driver is an excellent example: It knows from its OF data which gpio pins it needs and requests those. If the pins are not available, it gets an -EPROBE_DEFER error from the gpio subsystem, and simply defers its probe until the missing pins are available.
The question for me is really if it would be possible to implement the same approach for the iio subsystem. I would then specify something like
	max1139: max1139@35 {
        	compatible = "maxim,max1139";
		reg = <0x35>;
	};
...
	iio_hwmon {
		compatible = "iio-hwmon";

		in0 {
			label = "vin";
			iio-map = { &max1139 0 }; /* adc channel 0 */
		};
		in1 {
			label = "vout";
			iio-map = { &max1139 1 }; /* adc channel 1 */
		};
		...
	};
which would then map into in0/in1 hwmon attributes (with optional "vin" and "vout" labels if specified).
Problem here is that io_channel_get() currently does not use the provider name as argument to find the resource. Instead, it uses consumer_dev_name and/or consumer_channel. I am not sure how to solve that problem. It would be much more helpful if the provider would not be tied to the consumer from provider side, but from consumer side, and the mapping would be based on provider device and index (or something else such as ADC channel name if that is preferred).

Quoted 3 lines

Would this kind of solution be acceptable for the iio maintainers ? Is it even possible, given that the provider has to currently provide the mapping to its intended consumers using iio_map_array_register() ?

Hi Guenter,

I wrote in another mail a few days ago, how I think dt bindings for IIO could be implemented. The basic idea was to simply use bindings very similar to what the clk API uses, since its provider/consumer structure actually matches what we do in IIO pretty good.

The full mail can be found here:
http://marc.info/?l=linux-iio&m=135902119507483&w=2

- Lars

Guenter Roeck

author

2013-01-29 21:05 UTC #12 lore raw

Quoted 108 lines · Lars-Peter Clausen

Quoted 101 lines · Guenter Roeck
Quoted 23 lines · Jonathan Cameron
Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Jonathan Cameron
Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...
Quoted 7 lines
Best idea I can come up with is to disconnect iio_hwmon from the requirement to instantiate it explicitly. There might be two sysfs entries - one to attach it to a specific iio device, and one to attach it to individual channels of an iio device. Similar like the new_device interface on i2c adapters, and along the line of
echo max1139 something > /sys/module/iio_hwmon/something_else
We'll have to have something more specific or the common case of more than one instance of an adc will cause trouble. Obviously this doesn't matter doing by adding the map from the IIO side.
Quoted 5 lines
and/or
echo max1139 something channel > /sys/module/iio_hwmon/something_else
Quoted 8 lines
Quoted 2 lines
ie sysfs attributes associated with iio_hwmon, not with the iio device itself.
This will play havock with the way the internal mappings work. Originally we had it mapped from both sides by name (e.g. the map wasn't in any way handled by either driver) but that got an awful lot of flack and really wasn't considered acceptable. The current version of treating it much like regulators etc is much cleaner.
I think I am giving up on testing the code on a non-embedded system; I would need/use manual instantiation only for testing, and it seems too difficult to implement and not really worth it. I'll focus on getting it to work with OF.
The current approach, with iio_hwmon requesting its assigned mappings through io_channel_get_all(), does not work well for me for a number of reasons.
First, it is difficult to associate device references in OF with actual device names. I don't know if you have tried, but while a reference to &iio_hwmon can uniquely identify the device name for an OF entry such as
	iio_hwmon: iio_hwmon@0 {
		compatible = "iio-hwmon";
	};
it is difficult to predict how the actual iio_hwmon device name looks like. Amongst others, it depends if there are additional attributes such as "reg = <>", on the value of "@x" (if specified) and other attributes I have not really tracked down yet. In other words, when I tried to create a device named "iio_hwmon.0", I managed to get all kinds of device names except for "iio_hwmon.0".
Also, the iio_hwmon driver does not know which consumers are assigned to it. If it is instantiated before the ADC driver (which happens all the time for me, as iio_hwmon does not have to wait for the i2c bus adapter), its call to iio_channel_get_all() returns nothing. Even if it does return some mappings, there is no guarantee that the mappings are complete (eg if an instance of iio_hwmon is mapped to ADC channels from multiple chips).
Other subsystems solve that problem by having the consumer request the resources it needs. The leds-gpio driver is an excellent example: It knows from its OF data which gpio pins it needs and requests those. If the pins are not available, it gets an -EPROBE_DEFER error from the gpio subsystem, and simply defers its probe until the missing pins are available.
The question for me is really if it would be possible to implement the same approach for the iio subsystem. I would then specify something like
	max1139: max1139@35 {
        	compatible = "maxim,max1139";
		reg = <0x35>;
	};
...
	iio_hwmon {
		compatible = "iio-hwmon";

		in0 {
			label = "vin";
			iio-map = { &max1139 0 }; /* adc channel 0 */
		};
		in1 {
			label = "vout";
			iio-map = { &max1139 1 }; /* adc channel 1 */
		};
		...
	};
which would then map into in0/in1 hwmon attributes (with optional "vin" and "vout" labels if specified).
Problem here is that io_channel_get() currently does not use the provider name as argument to find the resource. Instead, it uses consumer_dev_name and/or consumer_channel. I am not sure how to solve that problem. It would be much more helpful if the provider would not be tied to the consumer from provider side, but from consumer side, and the mapping would be based on provider device and index (or something else such as ADC channel name if that is preferred).
Quoted 3 lines
Would this kind of solution be acceptable for the iio maintainers ? Is it even possible, given that the provider has to currently provide the mapping to its intended consumers using iio_map_array_register() ?
Hi Guenter,

Quoted 8 lines

I wrote in another mail a few days ago, how I think dt bindings for IIO could be implemented. The basic idea was to simply use bindings very similar to what the clk API uses, since its provider/consumer structure actually matches what we do in IIO pretty good.
The full mail can be found here:
http://marc.info/?l=linux-iio&m=135902119507483&w=2

Hi Lars,

looks like a good idea.

Do you know if anyone is working on an implementation ? Otherwise I'll give it a shot.

Thanks,
Guenter

Lars-Peter Clausen

2013-01-29 21:21 UTC #13 lore raw

Quoted 117 lines · Guenter Roeck

Quoted 108 lines · Lars-Peter Clausen
Quoted 101 lines · Guenter Roeck
Quoted 23 lines · Jonathan Cameron
Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Jonathan Cameron
Good point. New use case for us so suggestions on how to do the association cleanly would be most welcome. Is there anything similar out there? We could add a per iio device sysfs interface to add additional mappings but it is a little uggly...
Quoted 7 lines
Best idea I can come up with is to disconnect iio_hwmon from the requirement to instantiate it explicitly. There might be two sysfs entries - one to attach it to a specific iio device, and one to attach it to individual channels of an iio device. Similar like the new_device interface on i2c adapters, and along the line of
echo max1139 something > /sys/module/iio_hwmon/something_else
We'll have to have something more specific or the common case of more than one instance of an adc will cause trouble. Obviously this doesn't matter doing by adding the map from the IIO side.
Quoted 5 lines
and/or
echo max1139 something channel > /sys/module/iio_hwmon/something_else
Quoted 8 lines
Quoted 2 lines
ie sysfs attributes associated with iio_hwmon, not with the iio device itself.
This will play havock with the way the internal mappings work. Originally we had it mapped from both sides by name (e.g. the map wasn't in any way handled by either driver) but that got an awful lot of flack and really wasn't considered acceptable. The current version of treating it much like regulators etc is much cleaner.
I think I am giving up on testing the code on a non-embedded system; I would need/use manual instantiation only for testing, and it seems too difficult to implement and not really worth it. I'll focus on getting it to work with OF.
The current approach, with iio_hwmon requesting its assigned mappings through io_channel_get_all(), does not work well for me for a number of reasons.
First, it is difficult to associate device references in OF with actual device names. I don't know if you have tried, but while a reference to &iio_hwmon can uniquely identify the device name for an OF entry such as
	iio_hwmon: iio_hwmon@0 {
		compatible = "iio-hwmon";
	};
it is difficult to predict how the actual iio_hwmon device name looks like. Amongst others, it depends if there are additional attributes such as "reg = <>", on the value of "@x" (if specified) and other attributes I have not really tracked down yet. In other words, when I tried to create a device named "iio_hwmon.0", I managed to get all kinds of device names except for "iio_hwmon.0".
Also, the iio_hwmon driver does not know which consumers are assigned to it. If it is instantiated before the ADC driver (which happens all the time for me, as iio_hwmon does not have to wait for the i2c bus adapter), its call to iio_channel_get_all() returns nothing. Even if it does return some mappings, there is no guarantee that the mappings are complete (eg if an instance of iio_hwmon is mapped to ADC channels from multiple chips).
Other subsystems solve that problem by having the consumer request the resources it needs. The leds-gpio driver is an excellent example: It knows from its OF data which gpio pins it needs and requests those. If the pins are not available, it gets an -EPROBE_DEFER error from the gpio subsystem, and simply defers its probe until the missing pins are available.
The question for me is really if it would be possible to implement the same approach for the iio subsystem. I would then specify something like
	max1139: max1139@35 {
        	compatible = "maxim,max1139";
		reg = <0x35>;
	};
...
	iio_hwmon {
		compatible = "iio-hwmon";

		in0 {
			label = "vin";
			iio-map = { &max1139 0 }; /* adc channel 0 */
		};
		in1 {
			label = "vout";
			iio-map = { &max1139 1 }; /* adc channel 1 */
		};
		...
	};
which would then map into in0/in1 hwmon attributes (with optional "vin" and "vout" labels if specified).
Problem here is that io_channel_get() currently does not use the provider name as argument to find the resource. Instead, it uses consumer_dev_name and/or consumer_channel. I am not sure how to solve that problem. It would be much more helpful if the provider would not be tied to the consumer from provider side, but from consumer side, and the mapping would be based on provider device and index (or something else such as ADC channel name if that is preferred).
Quoted 3 lines
Would this kind of solution be acceptable for the iio maintainers ? Is it even possible, given that the provider has to currently provide the mapping to its intended consumers using iio_map_array_register() ?
Hi Guenter,
Quoted 8 lines
I wrote in another mail a few days ago, how I think dt bindings for IIO could be implemented. The basic idea was to simply use bindings very similar to what the clk API uses, since its provider/consumer structure actually matches what we do in IIO pretty good.
The full mail can be found here:
http://marc.info/?l=linux-iio&m=135902119507483&w=2

Quoted 6 lines

Hi Lars,
looks like a good idea.
Do you know if anyone is working on an implementation ? Otherwise I'll give it a shot.

I unfortunately dont have time for this atm, but maybe Naveen or Dou is working on it. Added them to Cc.

- Lars

Doug Anderson

2013-01-29 21:46 UTC #14 lore raw

Lars / Guenter,

Quoted 12 lines · Lars-Peter Clausen

Quoted 11 lines · Guenter Roeck
Quoted 8 lines · Lars-Peter Clausen
I wrote in another mail a few days ago, how I think dt bindings for IIO could be implemented. The basic idea was to simply use bindings very similar to what the clk API uses, since its provider/consumer structure actually matches what we do in IIO pretty good.
The full mail can be found here:
http://marc.info/?l=linux-iio&m=135902119507483&w=2
Hi Lars,

Quoted 7 lines

Quoted 4 lines
looks like a good idea.
Do you know if anyone is working on an implementation ? Otherwise I'll give it a shot.
I unfortunately dont have time for this atm, but maybe Naveen or Dou is working on it. Added them to Cc.

I believe Naveen was going to work on this but I found out this morning that he had to go on leave for some days so I'm not sure when he might respond. If you want to take a whack at implementing the bindings I don't think he would mind, though. ...then he'd be able to build on the same bindings to get the Samsung ADC working. :)

-Doug

Guenter Roeck

author

2013-01-29 22:28 UTC #15 lore raw

In reply to Guenter Roeck

Quoted 20 lines · Doug Anderson

Lars / Guenter,
Quoted 17 lines · Lars-Peter Clausen
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Lars-Peter Clausen
I wrote in another mail a few days ago, how I think dt bindings for IIO could be implemented. The basic idea was to simply use bindings very similar to what the clk API uses, since its provider/consumer structure actually matches what we do in IIO pretty good.
The full mail can be found here:
http://marc.info/?l=linux-iio&m5902119507483&w=2
Hi Lars,
looks like a good idea.
Do you know if anyone is working on an implementation ? Otherwise I'll give it a shot.

Quoted 9 lines

Quoted 2 lines
I unfortunately dont have time for this atm, but maybe Naveen or Dou is working on it. Added them to Cc.
I believe Naveen was going to work on this but I found out this morning that he had to go on leave for some days so I'm not sure when he might respond. If you want to take a whack at implementing the bindings I don't think he would mind, though. ...then he'd be able to build on the same bindings to get the Samsung ADC working. :)

Ok, I'll see what I can come up with.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors