[lm-sensors] API extensions (for IIO,

[lm-sensors] API extensions (for IIO,

[Jonathan Cameron]

Dear All,

We recently proposed an API specification for parts of the Industrial I/O
subsystem in a thread on LKML.  Greg KH pointed out that a we ought to, where
sensible keep as close as possible to API's of existing subsystems.  To that
end we are working on an updated version of the original document.
(original at http://lkml.org/lkml/2010/1/20/195, please note it has changed
a lot in response to comments made in that thread!)

The big difference from hwmon is that we very rarely export processed values
to user space.  The fundamental reason for this is that our primary access to
data is via ring buffer interfaces accessed through related character devices
rather than direct access through sysfs.  Speed is of the essence and often
processed values are not actually what is required in any case.  However,
we do wish to provide sufficient information for a user space library to perform
these calculations in the common case of a linear transform.

Anyhow, taking just voltage channels (ADC's) as a starting point we are looking
at the following and would appreciate comments / suggestions from the hwmon
community.

in0_raw     //raw access
in0_offset  
in0_gain    

(in0_value equivalent would be obtained from (in0_raw + in0_offset)*in0_gain)

In cases where all channels of type in share offset and gain we also allow (to
reduce the large number identical sysfs entries):

in_offset
in_gain

There are a couple of cases that I'm not sure how to sensibly handle, particularly
differential pairs.  Here we want to indicate which input lines they refer to within
the name and that we are dealing with a differential situation.

Ideas that come to mind for a case which is corresponds to (in0_raw - in1_raw) are

in0:1_raw
diff0:1_raw
in0-1_raw

What do people think is clearest?  Obvious, as per hwmon the vast majority of users
are going to access this through a user space library, but it would still be nice
to get a sensible human readable layout in sysfs.  Also note that there are a number
of other elements associated with each channel, but I have left them out of this
discussion to keep things simple (for now!) They are primarily to do with the ring
buffer access and so do not overlap so much with hwmon other than in base naming of
channels.

Note that there is no intention of adding the option to use these new interfaces to
hwmon, merely an intent to avoid introducing incompatible interfaces should this
functionality become of interest in the future and to take advantage of the experience
of the developers on this list.

Thanks,

Jonathan Cameron

p.s. I've thinned out the original list of ccs to those interested in this aspect.
Please forward to any interested parties whom I have missed!

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] API extensions (for IIO,

[Jean Delvare]

Hi Jonathan,

On Sun, 31 Jan 2010 18:31:08 +0000, Jonathan Cameron wrote:
> We recently proposed an API specification for parts of the Industrial I/O
> subsystem in a thread on LKML.  Greg KH pointed out that a we ought to, where
> sensible keep as close as possible to API's of existing subsystems.  To that
> end we are working on an updated version of the original document.
> (original at http://lkml.org/lkml/2010/1/20/195, please note it has changed
> a lot in response to comments made in that thread!)

I've read Greg's comment. I'm not quite sure I agree... IIO serves a
purpose which is clearly different from hwmon. The use cases are
different. Otherwise everyone would use hwmon and IIO wouldn't have to
support voltage and temperature inputs at all. So I don't think it
makes too much sense to make the new IIO API look like the hwmon one.
Learning from our mistakes, yes, certainly. But let's not get too far
into copying, otherwise we might lose the focus on the specific IIO
needs.

> The big difference from hwmon is that we very rarely export processed values
> to user space.  The fundamental reason for this is that our primary access to
> data is via ring buffer interfaces accessed through related character devices
> rather than direct access through sysfs.  Speed is of the essence and often
> processed values are not actually what is required in any case.  However,
> we do wish to provide sufficient information for a user space library to perform
> these calculations in the common case of a linear transform.
> 
> Anyhow, taking just voltage channels (ADC's) as a starting point we are looking
> at the following and would appreciate comments / suggestions from the hwmon
> community.
> 
> in0_raw     //raw access
> in0_offset  
> in0_gain    
> 
> (in0_value equivalent would be obtained from (in0_raw + in0_offset)*in0_gain)
> 
> In cases where all channels of type in share offset and gain we also allow (to
> reduce the large number identical sysfs entries):
> 
> in_offset
> in_gain

FWIW, we considered this for hwmon too, and finally decided to not
support this shortcut. The reasoning was that some chips have common
parameters for _some_ channels, but not all. Finding good sysfs file
names for such cases was challenging. To handle these cases, we decided
it was better to expose one separate file for each channel, and to make
all but first of each seat read-only. As this also covered the more
general case where all channels share a given parameter, we did not want
to create a special case for it, to make things more consistent and the
user-space library more simple.

Now I am not claiming that your case is similar. In particular, if you
intend to put the ADC's resolution in in_gain, then having a single
file for all inputs makes a lot of sense. But it should be possible to
override the general setting with a channel-specific one if needed
(e.g. for power sources which are internally scaled). Whether the final
gain in that case should be in_gain * inX_gain or just inX_gain, I
don't know.

> There are a couple of cases that I'm not sure how to sensibly handle, particularly
> differential pairs.  Here we want to indicate which input lines they refer to within
> the name and that we are dealing with a differential situation.
> 
> Ideas that come to mind for a case which is corresponds to (in0_raw - in1_raw) are
> 
> in0:1_raw
> diff0:1_raw
> in0-1_raw
> 
> What do people think is clearest?  Obvious, as per hwmon the vast majority of users
> are going to access this through a user space library, but it would still be nice
> to get a sensible human readable layout in sysfs.  Also note that there are a number
> of other elements associated with each channel, but I have left them out of this
> discussion to keep things simple (for now!) They are primarily to do with the ring
> buffer access and so do not overlap so much with hwmon other than in base naming of
> channels.

For hwmon, we have hidden the fact that a voltage could be the result
of a differential pair, so we did not have to come up with separate
names. This may not be suitable for IIO though, I'll let you decide.

I think I like the use of "-", as it makes it very clear which pin is
considered the negative one and which pin is considered the positive
one. Maybe in0-in1_raw would be even clearer? I can't find any fatal
flaw in the other proposals though. 

> Note that there is no intention of adding the option to use these new interfaces to
> hwmon, merely an intent to avoid introducing incompatible interfaces should this
> functionality become of interest in the future and to take advantage of the experience
> of the developers on this list.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] API extensions (for IIO,

[Manuel Stahl]

[-- Attachment #1.1.1: Type: text/plain, Size: 1720 bytes --]

Hi Jean,

Am 01.02.2010 14:52, schrieb Jean Delvare:
> Hi Jonathan,
>
> On Sun, 31 Jan 2010 18:31:08 +0000, Jonathan Cameron wrote:
>> We recently proposed an API specification for parts of the Industrial I/O
>> subsystem in a thread on LKML.  Greg KH pointed out that a we ought to, where
>> sensible keep as close as possible to API's of existing subsystems.  To that
>> end we are working on an updated version of the original document.
>> (original at http://lkml.org/lkml/2010/1/20/195, please note it has changed
>> a lot in response to comments made in that thread!)
>
> I've read Greg's comment. I'm not quite sure I agree... IIO serves a
> purpose which is clearly different from hwmon. The use cases are
> different. Otherwise everyone would use hwmon and IIO wouldn't have to
> support voltage and temperature inputs at all. So I don't think it
> makes too much sense to make the new IIO API look like the hwmon one.
> Learning from our mistakes, yes, certainly. But let's not get too far
> into copying, otherwise we might lose the focus on the specific IIO
> needs.

You're absolutly right here. IIO has to support more hardware features 
of these devices than hwmon does. But IIO knows about the type of 
sensor, so it shouldn't be too hard to add an option to IIO to export 
voltage and temperature devices into hwmon. The same could be done with 
accelerometers for input.

-- 
Dipl.-Inf. Manuel Stahl
Fraunhofer-Institut für Integrierte Schaltungen IIS
- Leistungsoptimierte Systeme -
Nordostpark 93                Telefon  +49 (0)911/58061-6419
90411 Nürnberg                Fax      +49 (0)911/58061-6398
http://www.iis.fraunhofer.de  manuel.stahl@iis.fraunhofer.de

[-- Attachment #1.1.2: manuel_stahl.vcf --]
[-- Type: text/x-vcard, Size: 170 bytes --]

begin:vcard
fn:Manuel Stahl
n:Stahl;Manuel
email;internet:manuel.stahl@iis.fraunhofer.de
tel;work:+49 911 58061-6419
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6148 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

Re: [lm-sensors] API extensions (for IIO,

[Jonathan Cameron]

Hi Jean,
> 
> On Sun, 31 Jan 2010 18:31:08 +0000, Jonathan Cameron wrote:
>> We recently proposed an API specification for parts of the Industrial I/O
>> subsystem in a thread on LKML.  Greg KH pointed out that a we ought to, where
>> sensible keep as close as possible to API's of existing subsystems.  To that
>> end we are working on an updated version of the original document.
>> (original at http://lkml.org/lkml/2010/1/20/195, please note it has changed
>> a lot in response to comments made in that thread!)
> 
> I've read Greg's comment. I'm not quite sure I agree... IIO serves a
> purpose which is clearly different from hwmon. The use cases are
> different. Otherwise everyone would use hwmon and IIO wouldn't have to
> support voltage and temperature inputs at all. So I don't think it
> makes too much sense to make the new IIO API look like the hwmon one.
> Learning from our mistakes, yes, certainly. But let's not get too far
> into copying, otherwise we might lose the focus on the specific IIO
> needs.
I agreed to the extent that we won't match API's for the sake of doing so,
but in cases where it costs us nothing it probably makes sense to do so.
If nothing else it may cut down on confusion with developers who are
working in both subsystems.  In the cases covered here, I think there is
no cost to sharing naming.  Clearly we should still document the APIs
separately on the basis they may diverge again in future.  Whether it makes
sense for them to continue to match can be debated if that occurs.
> 
>> The big difference from hwmon is that we very rarely export processed values
>> to user space.  The fundamental reason for this is that our primary access to
>> data is via ring buffer interfaces accessed through related character devices
>> rather than direct access through sysfs.  Speed is of the essence and often
>> processed values are not actually what is required in any case.  However,
>> we do wish to provide sufficient information for a user space library to perform
>> these calculations in the common case of a linear transform.
>>
>> Anyhow, taking just voltage channels (ADC's) as a starting point we are looking
>> at the following and would appreciate comments / suggestions from the hwmon
>> community.
>>
>> in0_raw     //raw access
>> in0_offset  
>> in0_gain    
>>
>> (in0_value equivalent would be obtained from (in0_raw + in0_offset)*in0_gain)
>>
>> In cases where all channels of type in share offset and gain we also allow (to
>> reduce the large number identical sysfs entries):
>>
>> in_offset
>> in_gain
> 
> FWIW, we considered this for hwmon too, and finally decided to not
> support this shortcut. The reasoning was that some chips have common
> parameters for _some_ channels, but not all. Finding good sysfs file
> names for such cases was challenging. 
Agreed, I've already run into that one myself.  
> To handle these cases, we decided
> it was better to expose one separate file for each channel, and to make
> all but first of each seat read-only.
That is pretty much the fallback I was intending when we don't have
parameters applying to all of a given channel type.
> As this also covered the more
> general case where all channels share a given parameter, we did not want
> to create a special case for it, to make things more consistent and the
> user-space library more simple.
> 
> Now I am not claiming that your case is similar. In particular, if you
> intend to put the ADC's resolution in in_gain, then having a single
> file for all inputs makes a lot of sense. But it should be possible to
> override the general setting with a channel-specific one if needed
> (e.g. for power sources which are internally scaled). Whether the final
> gain in that case should be in_gain * inX_gain or just inX_gain, I
> don't know.
In cases where these are separately configurable I'd be inclined to always
have the individual files.  The shared option is only for the simplest
cases.  There is no obligation on a device driver to take this shortcut at
all, it is merely there as an option.  Conversely I think we will definitely
want extensive justification of drivers which do the mixed case you are
describing.  That's not to say I can't envision one, but it will as you say
make things semantically unclear.
> 
>> There are a couple of cases that I'm not sure how to sensibly handle, particularly
>> differential pairs.  Here we want to indicate which input lines they refer to within
>> the name and that we are dealing with a differential situation.
>>
>> Ideas that come to mind for a case which is corresponds to (in0_raw - in1_raw) are
>>
>> in0:1_raw
>> diff0:1_raw
>> in0-1_raw
>>
>> What do people think is clearest?  Obvious, as per hwmon the vast majority of users
>> are going to access this through a user space library, but it would still be nice
>> to get a sensible human readable layout in sysfs.  Also note that there are a number
>> of other elements associated with each channel, but I have left them out of this
>> discussion to keep things simple (for now!) They are primarily to do with the ring
>> buffer access and so do not overlap so much with hwmon other than in base naming of
>> channels.
> 
> For hwmon, we have hidden the fact that a voltage could be the result
> of a differential pair, so we did not have to come up with separate
> names. This may not be suitable for IIO though, I'll let you decide.
> 
> I think I like the use of "-", as it makes it very clear which pin is
> considered the negative one and which pin is considered the positive
> one. Maybe in0-in1_raw would be even clearer?
That does make it very clear, it should also be nice and easy to pull out in a userspace
interface. If we don't do this, I bet we come across a chip capable of giving differential
outputs across different types of input.   in0-accel_x0 anyone? :)

Unless anyone has an objection to this, I'll go with your suggestion.

Thanks,

Jonathan

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] API extensions (for IIO,

[samu.p.onkalo]

>-----Original Message-----
>From: lm-sensors-bounces@lm-sensors.org [mailto:lm-sensors-bounces@lm-
>sensors.org] On Behalf Of ext Jonathan Cameron
>Sent: 31 January, 2010 20:31
>To: LM Sensors; Greg KH; Manuel Stahl; Torokhov; Hennerich, Michael;
>Jean Delvare
>Subject: [lm-sensors] API extensions (for IIO, matching hwmon as closely
>as possible)
>
>Dear All,
>
>We recently proposed an API specification for parts of the Industrial
>I/O
>subsystem in a thread on LKML.  Greg KH pointed out that a we ought to,
>where
>sensible keep as close as possible to API's of existing subsystems.  To
>that
>end we are working on an updated version of the original document.
>(original at http://lkml.org/lkml/2010/1/20/195, please note it has
>changed
>a lot in response to comments made in that thread!)

Hi

Based on the discussion in lkml, it seems that I'm working on "toy" side of the
sensors. I agree that we need to have standard interface for different kind
of sensors. It has been quite hard to decide what kind of interface is the correct one
for different sensors (accelerometers, magnetometers, ambient light sensors,
proximity sensors etc). When sensors are used for some kind of user interface control
(device orientation, lightning, movement, games, amusement applications),
historical or buffered data is not so important. Data is aging quite rapidly.
In battery powered devices, it is essential to turn off sensor HW whenever possible.
Does the proposed interface offer possibility to turn off the sensors when they
are not used?

Br, Samu

ps.
Jonathan, could you please keep me in CC when discussing about IIO.

>
>The big difference from hwmon is that we very rarely export processed
>values
>to user space.  The fundamental reason for this is that our primary
>access to
>data is via ring buffer interfaces accessed through related character
>devices
>rather than direct access through sysfs.  Speed is of the essence and
>often
>processed values are not actually what is required in any case.
>However,
>we do wish to provide sufficient information for a user space library to
>perform
>these calculations in the common case of a linear transform.
>
>Anyhow, taking just voltage channels (ADC's) as a starting point we are
>looking
>at the following and would appreciate comments / suggestions from the
>hwmon
>community.
>
>in0_raw     //raw access
>in0_offset
>in0_gain
>
>(in0_value equivalent would be obtained from (in0_raw +
>in0_offset)*in0_gain)
>
>In cases where all channels of type in share offset and gain we also
>allow (to
>reduce the large number identical sysfs entries):
>
>in_offset
>in_gain
>
>There are a couple of cases that I'm not sure how to sensibly handle,
>particularly
>differential pairs.  Here we want to indicate which input lines they
>refer to within
>the name and that we are dealing with a differential situation.
>
>Ideas that come to mind for a case which is corresponds to (in0_raw -
>in1_raw) are
>
>in0:1_raw
>diff0:1_raw
>in0-1_raw
>
>What do people think is clearest?  Obvious, as per hwmon the vast
>majority of users
>are going to access this through a user space library, but it would
>still be nice
>to get a sensible human readable layout in sysfs.  Also note that there
>are a number
>of other elements associated with each channel, but I have left them out
>of this
>discussion to keep things simple (for now!) They are primarily to do
>with the ring
>buffer access and so do not overlap so much with hwmon other than in
>base naming of
>channels.
>
>Note that there is no intention of adding the option to use these new
>interfaces to
>hwmon, merely an intent to avoid introducing incompatible interfaces
>should this
>functionality become of interest in the future and to take advantage of
>the experience
>of the developers on this list.
>
>Thanks,
>
>Jonathan Cameron
>
>p.s. I've thinned out the original list of ccs to those interested in
>this aspect.
>Please forward to any interested parties whom I have missed!
>
>_______________________________________________
>lm-sensors mailing list
>lm-sensors@lm-sensors.org
>http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] API extensions (for IIO,

[Jonathan Cameron]

On 02/02/10 09:01, samu.p.onkalo@nokia.com wrote:
>> -----Original Message-----
>> From: lm-sensors-bounces@lm-sensors.org [mailto:lm-sensors-bounces@lm-
>> sensors.org] On Behalf Of ext Jonathan Cameron
>> Sent: 31 January, 2010 20:31
>> To: LM Sensors; Greg KH; Manuel Stahl; Torokhov; Hennerich, Michael;
>> Jean Delvare
>> Subject: [lm-sensors] API extensions (for IIO, matching hwmon as closely
>> as possible)
>>
>> Dear All,
>>
>> We recently proposed an API specification for parts of the Industrial
>> I/O
>> subsystem in a thread on LKML.  Greg KH pointed out that a we ought to,
>> where
>> sensible keep as close as possible to API's of existing subsystems.  To
>> that
>> end we are working on an updated version of the original document.
>> (original at http://lkml.org/lkml/2010/1/20/195, please note it has
>> changed
>> a lot in response to comments made in that thread!)
> 
> Hi
> 
> Based on the discussion in lkml, it seems that I'm working on "toy" side of the
> sensors. I agree that we need to have standard interface for different kind
> of sensors. It has been quite hard to decide what kind of interface is the correct one
> for different sensors (accelerometers, magnetometers, ambient light sensors,
> proximity sensors etc). When sensors are used for some kind of user interface control
> (device orientation, lightning, movement, games, amusement applications),
> historical or buffered data is not so important. Data is aging quite rapidly.
Agreed, here as you say the requirements are quite different.  Just as an aside,
in the case of lighting there is the new ALS framework (in linux-next right now)
that basically provides an equivalent of hwmon for ambient light sensors.  There
are quite a few drivers on there way into that from the various places they are
currently scattered through the kernel (tsl2550, tsl2563, isl20003 and a new acpi-als
driver).  These things tend to be fairly slow, so we decided IIO was massive overkill!
> In battery powered devices, it is essential to turn off sensor HW whenever possible.
> Does the proposed interface offer possibility to turn off the sensors when they
> are not used?
At the moment a couple of the drivers support this (or at least patches
with it in have been kicking around), but to a certain extent I'm not
convinced this is really the job of the core framework.  The driver 
(and for that matter the bus driver) are much better placed to understand
when they can go to sleep.  I guess the only exception to this would be if
one had a slow triggered ring buffer capture off some sort of periodic hardware
interrupt (perhaps another devices datardy signal).  Here you might want a heads
up from the triggering device to tell your driver to wake up the sensor prior to
the trigger actually occurring.  In simpler cases, say where you are using an
on SoC periodic timer to do the job, if the wakeup takes a fixed time, then maybe
we can make life easier for userspace by exporting this time and hence allowing it
to adjust the timing trigger appropriately?

I'm personally very keen to see more drivers for these sort of devices handle
power saving well, particularly with respect to interacting with the bus drivers
etc to power down whole chunks of a board.

Perhaps if you illustrate what support you would particularly like to see and
how it should function, you may persuade us that it should be in the IIO core
rather than the drivers themselves?
> 
> Br, Samu
> 
> ps.
> Jonathan, could you please keep me in CC when discussing about IIO.
Will do.

Jonathan

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] API extensions (for IIO,

[Onkalo Samu]

On Tue, 2010-02-02 at 12:13 +0100, ext Jonathan Cameron wrote:
> On 02/02/10 09:01, samu.p.onkalo@nokia.com wrote:
> >> -----Original Message-----
> >> From: lm-sensors-bounces@lm-sensors.org [mailto:lm-sensors-bounces@lm-
> >> sensors.org] On Behalf Of ext Jonathan Cameron
> >> Sent: 31 January, 2010 20:31
> >> To: LM Sensors; Greg KH; Manuel Stahl; Torokhov; Hennerich, Michael;
> >> Jean Delvare
> >> Subject: [lm-sensors] API extensions (for IIO, matching hwmon as closely
> >> as possible)
> >>
> >> Dear All,
> >>
> >> We recently proposed an API specification for parts of the Industrial
> >> I/O
> >> subsystem in a thread on LKML.  Greg KH pointed out that a we ought to,
> >> where
> >> sensible keep as close as possible to API's of existing subsystems.  To
> >> that
> >> end we are working on an updated version of the original document.
> >> (original at http://lkml.org/lkml/2010/1/20/195, please note it has
> >> changed
> >> a lot in response to comments made in that thread!)
> > 
> > Hi
> > 
> > Based on the discussion in lkml, it seems that I'm working on "toy" side of the
> > sensors. I agree that we need to have standard interface for different kind
> > of sensors. It has been quite hard to decide what kind of interface is the correct one
> > for different sensors (accelerometers, magnetometers, ambient light sensors,
> > proximity sensors etc). When sensors are used for some kind of user interface control
> > (device orientation, lightning, movement, games, amusement applications),
> > historical or buffered data is not so important. Data is aging quite rapidly.
> Agreed, here as you say the requirements are quite different.  Just as an aside,
> in the case of lighting there is the new ALS framework (in linux-next right now)
> that basically provides an equivalent of hwmon for ambient light sensors.  There
> are quite a few drivers on there way into that from the various places they are
> currently scattered through the kernel (tsl2550, tsl2563, isl20003 and a new acpi-als
> driver).  These things tend to be fairly slow, so we decided IIO was massive overkill!

Hmm, something similar would make sense for proximity sensors also. 

> > In battery powered devices, it is essential to turn off sensor HW whenever possible.
> > Does the proposed interface offer possibility to turn off the sensors when they
> > are not used?
> At the moment a couple of the drivers support this (or at least patches
> with it in have been kicking around), but to a certain extent I'm not
> convinced this is really the job of the core framework.  The driver 
> (and for that matter the bus driver) are much better placed to understand
> when they can go to sleep.  I guess the only exception to this would be if
> one had a slow triggered ring buffer capture off some sort of periodic hardware
> interrupt (perhaps another devices datardy signal).  Here you might want a heads
> up from the triggering device to tell your driver to wake up the sensor prior to
> the trigger actually occurring.  In simpler cases, say where you are using an
> on SoC periodic timer to do the job, if the wakeup takes a fixed time, then maybe
> we can make life easier for userspace by exporting this time and hence allowing it
> to adjust the timing trigger appropriately?
> 
> I'm personally very keen to see more drivers for these sort of devices handle
> power saving well, particularly with respect to interacting with the bus drivers
> etc to power down whole chunks of a board.
> 
> Perhaps if you illustrate what support you would particularly like to see and
> how it should function, you may persuade us that it should be in the IIO core
> rather than the drivers themselves?

It is probably more driver issue to handle chip operating state. For
portable devices, there probably is somekind of device state control 
(like charging, device in some level of standby state (example UI locked
but still listening to network)) which knows when some part of the HW
services are not used. It might be that actual users of the sensor data
are not controlling the state. Device drivers should provide interface
for turning HW off (sensors, regulators feeding the sensor, possible
clocks) in that case. 

I think that sysfs based interface doesn't offer possibility to turn off
the HW when no-one is accessing the interface.

-Samu



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors