* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-17 21:03 ` Jonathan Cameron
0 siblings, 0 replies; 30+ messages in thread
From: Jonathan Cameron @ 2013-01-17 21:03 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Jonathan Cameron, linux-iio, Jean Delvare, lm-sensors
[-- Attachment #1.1: Type: text/plain, Size: 2012 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 #1.2: Type: text/html, Size: 2829 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread
* Userspace IIO map instantiation [was MAX1363 IIO driver questions]
2013-01-17 21:03 ` [lm-sensors] " Jonathan Cameron
@ 2013-01-17 21:37 ` Jonathan Cameron
-1 siblings, 0 replies; 30+ messages in thread
From: Jonathan Cameron @ 2013-01-17 21:37 UTC (permalink / raw)
Cc: Guenter Roeck, linux-iio, Jean Delvare, lm-sensors,
James Peverill, Mark Brown, Greg KH
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
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* [lm-sensors] Userspace IIO map instantiation [was MAX1363 IIO driver questions]
@ 2013-01-17 21:37 ` Jonathan Cameron
0 siblings, 0 replies; 30+ messages in thread
From: Jonathan Cameron @ 2013-01-17 21:37 UTC (permalink / raw)
Cc: Guenter Roeck, linux-iio, Jean Delvare, lm-sensors,
James Peverill, Mark Brown, Greg KH
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\x132933525705497&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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: MAX1363 IIO driver questions
2013-01-17 21:03 ` [lm-sensors] " Jonathan Cameron
@ 2013-01-18 22:09 ` Guenter Roeck
-1 siblings, 0 replies; 30+ messages in thread
From: Guenter Roeck @ 2013-01-18 22:09 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio, Jean Delvare, lm-sensors
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
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-18 22:09 ` Guenter Roeck
0 siblings, 0 replies; 30+ messages in thread
From: Guenter Roeck @ 2013-01-18 22:09 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio, Jean Delvare, lm-sensors
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\x132933525705497&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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: MAX1363 IIO driver questions
2013-01-18 22:09 ` [lm-sensors] " Guenter Roeck
@ 2013-01-26 11:25 ` Jonathan Cameron
-1 siblings, 0 replies; 30+ messages in thread
From: Jonathan Cameron @ 2013-01-26 11:25 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Jonathan Cameron, linux-iio, Jean Delvare, lm-sensors
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
>>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-26 11:25 ` Jonathan Cameron
0 siblings, 0 replies; 30+ messages in thread
From: Jonathan Cameron @ 2013-01-26 11:25 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Jonathan Cameron, linux-iio, Jean Delvare, lm-sensors
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\x132933525705497&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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: MAX1363 IIO driver questions
2013-01-26 11:25 ` [lm-sensors] " Jonathan Cameron
@ 2013-01-29 20:00 ` Guenter Roeck
-1 siblings, 0 replies; 30+ messages in thread
From: Guenter Roeck @ 2013-01-29 20:00 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio, Jean Delvare, lm-sensors
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
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-29 20:00 ` Guenter Roeck
0 siblings, 0 replies; 30+ messages in thread
From: Guenter Roeck @ 2013-01-29 20:00 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio, Jean Delvare, lm-sensors
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
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: MAX1363 IIO driver questions
2013-01-29 20:00 ` [lm-sensors] " Guenter Roeck
@ 2013-01-29 20:10 ` Lars-Peter Clausen
-1 siblings, 0 replies; 30+ messages in thread
From: Lars-Peter Clausen @ 2013-01-29 20:10 UTC (permalink / raw)
To: Guenter Roeck
Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, Jean Delvare,
lm-sensors
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
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-29 20:10 ` Lars-Peter Clausen
0 siblings, 0 replies; 30+ messages in thread
From: Lars-Peter Clausen @ 2013-01-29 20:10 UTC (permalink / raw)
To: Guenter Roeck
Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, Jean Delvare,
lm-sensors
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\x135902119507483&w=2
- Lars
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: MAX1363 IIO driver questions
2013-01-29 20:10 ` [lm-sensors] " Lars-Peter Clausen
@ 2013-01-29 21:05 ` Guenter Roeck
-1 siblings, 0 replies; 30+ messages in thread
From: Guenter Roeck @ 2013-01-29 21:05 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, Jean Delvare,
lm-sensors
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
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-29 21:05 ` Guenter Roeck
0 siblings, 0 replies; 30+ messages in thread
From: Guenter Roeck @ 2013-01-29 21:05 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, Jean Delvare,
lm-sensors
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\x135902119507483&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
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: MAX1363 IIO driver questions
2013-01-29 21:05 ` [lm-sensors] " Guenter Roeck
@ 2013-01-29 21:21 ` Lars-Peter Clausen
-1 siblings, 0 replies; 30+ messages in thread
From: Lars-Peter Clausen @ 2013-01-29 21:21 UTC (permalink / raw)
To: Guenter Roeck
Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, Jean Delvare,
lm-sensors, Naveen Krishna Chatradhi, Doug Anderson, Tomasz Figa
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
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-29 21:21 ` Lars-Peter Clausen
0 siblings, 0 replies; 30+ messages in thread
From: Lars-Peter Clausen @ 2013-01-29 21:21 UTC (permalink / raw)
To: Guenter Roeck
Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, Jean Delvare,
lm-sensors, Naveen Krishna Chatradhi, Doug Anderson, Tomasz Figa
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\x135902119507483&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
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: MAX1363 IIO driver questions
2013-01-29 21:21 ` [lm-sensors] " Lars-Peter Clausen
@ 2013-01-29 21:46 ` Doug Anderson
-1 siblings, 0 replies; 30+ messages in thread
From: Doug Anderson @ 2013-01-29 21:46 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Guenter Roeck, Jonathan Cameron, Jonathan Cameron, linux-iio,
Jean Delvare, lm-sensors, Naveen Krishna Chatradhi, Tomasz Figa
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] MAX1363 IIO driver questions
@ 2013-01-29 21:46 ` Doug Anderson
0 siblings, 0 replies; 30+ messages in thread
From: Doug Anderson @ 2013-01-29 21:46 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Guenter Roeck, Jonathan Cameron, Jonathan Cameron, linux-iio,
Jean Delvare, lm-sensors, Naveen Krishna Chatradhi, Tomasz Figa
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\x135902119507483&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
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 30+ messages in thread