MAX1363 IIO driver questions

MAX1363 IIO driver questions

[Guenter Roeck]

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

Re: MAX1363 IIO driver questions

[Jonathan Cameron]

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
> 
> Thanks,
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: MAX1363 IIO driver questions

[Guenter Roeck]

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)
> 
Excellent. Guess I need to check more than once 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.
> 
I'll have another look myself.

Thanks,
Guenter

Re: MAX1363 IIO driver questions

[Guenter Roeck]

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.

Thanks,
Guenter

Re: MAX1363 IIO driver questions

[Jonathan Cameron]

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&m=132933525705497&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

Re: MAX1363 IIO driver questions

[Jonathan Cameron]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]


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...

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

Guenter Roeck <linux@roeck-us.net> 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&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


[-- Attachment #2: Type: text/html, Size: 2824 bytes --]

Userspace IIO map instantiation [was MAX1363 IIO driver questions]

[Jonathan Cameron]

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

On 01/17/2013 09:03 PM, Jonathan Cameron wrote:
> 
> 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...
> 
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> 
> Guenter Roeck <linux@roeck-us.net> 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&m=132933525705497&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
> 

Re: MAX1363 IIO driver questions

[Guenter Roeck]

On Thu, Jan 17, 2013 at 09:03:58PM +0000, Jonathan Cameron wrote:
> 
> 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

> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> 
> Guenter Roeck <linux@roeck-us.net> 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&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
> 

Re: MAX1363 IIO driver questions

[Jonathan Cameron]

On 01/18/2013 10:09 PM, Guenter Roeck wrote:
> On Thu, Jan 17, 2013 at 09:03:58PM +0000, Jonathan Cameron wrote:
>>
>> 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

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.

> 
> 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.

> 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

>> -- 
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> Guenter Roeck <linux@roeck-us.net> 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&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
>>

Re: MAX1363 IIO driver questions

[Guenter Roeck]

On Sat, Jan 26, 2013 at 11:25:35AM +0000, Jonathan Cameron wrote:
> On 01/18/2013 10:09 PM, Guenter Roeck wrote:
> > On Thu, Jan 17, 2013 at 09:03:58PM +0000, Jonathan Cameron wrote:
> >>
> >> 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
> 
> 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.
> 
> > 
> > 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.
> 

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

Re: MAX1363 IIO driver questions

[Lars-Peter Clausen]

On 01/29/2013 09:00 PM, Guenter Roeck wrote:
> On Sat, Jan 26, 2013 at 11:25:35AM +0000, Jonathan Cameron wrote:
>> On 01/18/2013 10:09 PM, Guenter Roeck wrote:
>>> On Thu, Jan 17, 2013 at 09:03:58PM +0000, Jonathan Cameron wrote:
>>>>
>>>> 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
>>
>> 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.
>>
>>>
>>> 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.
>>
> 
> 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() ?

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

Re: MAX1363 IIO driver questions

[Guenter Roeck]

On Tue, Jan 29, 2013 at 09:10:25PM +0100, Lars-Peter Clausen wrote:
> On 01/29/2013 09:00 PM, Guenter Roeck wrote:
> > On Sat, Jan 26, 2013 at 11:25:35AM +0000, Jonathan Cameron wrote:
> >> On 01/18/2013 10:09 PM, Guenter Roeck wrote:
> >>> On Thu, Jan 17, 2013 at 09:03:58PM +0000, Jonathan Cameron wrote:
> >>>>
> >>>> 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
> >>
> >> 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.
> >>
> >>>
> >>> 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.
> >>
> > 
> > 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() ?
> 
> 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
> 
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

Re: MAX1363 IIO driver questions

[Lars-Peter Clausen]

On 01/29/2013 10:05 PM, Guenter Roeck wrote:
> On Tue, Jan 29, 2013 at 09:10:25PM +0100, Lars-Peter Clausen wrote:
>> On 01/29/2013 09:00 PM, Guenter Roeck wrote:
>>> On Sat, Jan 26, 2013 at 11:25:35AM +0000, Jonathan Cameron wrote:
>>>> On 01/18/2013 10:09 PM, Guenter Roeck wrote:
>>>>> On Thu, Jan 17, 2013 at 09:03:58PM +0000, Jonathan Cameron wrote:
>>>>>>
>>>>>> 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
>>>>
>>>> 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.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>
>>> 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() ?
>>
>> 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
>>
> 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

Re: MAX1363 IIO driver questions

[Doug Anderson]

Lars / Guenter,

On Tue, Jan 29, 2013 at 1:21 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 01/29/2013 10:05 PM, Guenter Roeck wrote:
>> On Tue, Jan 29, 2013 at 09:10:25PM +0100, Lars-Peter Clausen wrote:
>>> 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.
>
> 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