All of lore.kernel.org
 help / color / mirror / Atom feed
* [lm-sensors] lm-sensors benefits
@ 2009-05-28 14:00 Rob Bloom
  2009-05-29  7:36 ` Hans de Goede
  0 siblings, 1 reply; 2+ messages in thread
From: Rob Bloom @ 2009-05-28 14:00 UTC (permalink / raw)
  To: lm-sensors

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

--===============1508790979849647179==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C9DF9C.A266F387"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 2991 bytes --]

Many thanks to Hans, Mark and Jonathan for answering my previous email
on specific hwmon chips (turns out 3 of the 4 I questioned are not (yet)
supported by lm-sensors).  I'd like to back-up a bit and ensure I
understand what lm-sensors will do for us in our project:



Essentially, we want to be able to read our temp and power monitor chips
every 10 seconds and evaluate the values read (pass them for review to
our own customized health monitoring system).  I've been tasked with
explaining the benefits of using lm-sensors package vs. not using it.
Hopefully my questions do not seem too naive but I'm asking them from
the perspective of having to write drivers (or, at least, assisting) for
unsupported chips:



-          As I understand it, the drivers for these chips are not part
of lm-sensors; one must develop the code for the chip in the kernel, if
not already supported by the kernel.  This driver work, if needed, is
done whether or not one chooses to use lm-sensors, correct?



-          The libsensors library makes things easier by offering an
interface for apps to access chip readings, configure them and convert
them to real-world values.  It works in conjunction with the
/etc/sensors.conf file.

o        Is libsensors part of lm-sensors or are they developed and
retrieved independently?

o        Is lm-sensors considered one of the "apps" mentioned above that
opt to use libsensors to make things easier?

o        Can I choose to write my own app to interface with libsensors
and the hwmon chips?  One of my colleagues asked "why can't we simply
read the chip registers with simple i2c calls over the bus?".



-          I skimmed over the lm-sensors source code.  I know that it
was made generic.  So, how does it know what chips it needs to monitor?
I assume this is through the sensors.conf file.  I'm looking for the:

o        lm-sensors source code that discovers the chips that it has
(does it read the sensors.conf file?  Where is the lm-sensors code that
does this?)

o        lm-sensors source code that utilizes the kernel drivers that
sit in /drivers/hwmon directory.  Could you point me to this code?



If the info I am looking for is already in some doc'n somewhere, feel
free to point me to it.  I have perused a good bit of doc'n by now but
maybe I've missed it.



Thanks for your helpful comments and tips.



Rob Bloom
Software Design Engineer
Flextronics Canada Design Services




Legal Disclaimer:
The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message

[-- Attachment #3: Type: text/html, Size: 11570 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [lm-sensors] lm-sensors benefits
  2009-05-28 14:00 [lm-sensors] lm-sensors benefits Rob Bloom
@ 2009-05-29  7:36 ` Hans de Goede
  0 siblings, 0 replies; 2+ messages in thread
From: Hans de Goede @ 2009-05-29  7:36 UTC (permalink / raw)
  To: lm-sensors

On 05/28/2009 04:00 PM, Rob Bloom wrote:
>
>
> Many thanks to Hans, Mark and Jonathan for answering my previous email
> on specific hwmon chips (turns out 3 of the 4 I questioned are not (yet)
> supported by lm-sensors). I’d like to back-up a bit and ensure I
> understand what lm-sensors will do for us in our project:
>
> Essentially, we want to be able to read our temp and power monitor chips
> every 10 seconds and evaluate the values read (pass them for review to
> our own customized health monitoring system). I’ve been tasked with
> explaining the benefits of using lm-sensors package vs. not using it.
> Hopefully my questions do not seem too naive but I’m asking them from
> the perspective of having to write drivers (or, at least, assisting) for
> unsupported chips:
>
> - As I understand it, the drivers for these chips are not part of
> lm-sensors; one must develop the code for the chip in the kernel, if not
> already supported by the kernel. This driver work, if needed, is done
> whether or not one chooses to use lm-sensors, correct?
>

Correct, in the end you will always need some code to talk to the IC's

> - The libsensors library makes things easier by offering an interface
> for apps to access chip readings, configure them and convert them to
> real-world values. It works in conjunction with the /etc/sensors.conf file.
>
> o Is libsensors part of lm-sensors or are they developed and retrieved
> independently?
>

libsensors is part of lm_sensors, one could even argue that libsensors *is*
what lm_sensors is all about, and that the sensors application included
is an example application of how to use libsensors.

> o Is lm-sensors considered one of the “apps” mentioned above that opt to
> use libsensors to make things easier?
>

The sensors application which is part of lm_sensors (as is libsensors)
is one of the apps yes. And libsensors is not only about making things
easier, but also about providing a single unified interface that many
different applications can use, while having all the configuration data
(which pin is connected to what, what are the scaling factors if any) in
a central place for all of them, this is what /etc/sensors.conf is for.

> o Can I choose to write my own app to interface with libsensors and the
> hwmon chips?

Yes you can easily write your own app.

 > One of my colleagues asked “why can’t we simply read the
> chip registers with simple i2c calls over the bus?”.
>

Sure you can do this, but the advantage of writing a proper driver and
then using libsensors is that your app becomes independent of the
IC's, so if you ever do another revision of the product, or a whole new
product you could reuse your application without needing to change it.
And chances are that if in the new product you choose already
supported IC'd, you don't need to write any driver code either.

> - I skimmed over the lm-sensors source code. I know that it was made
> generic. So, how does it know what chips it needs to monitor? I assume
> this is through the sensors.conf file. I’m looking for the:
 > o lm-sensors source code that discovers the chips that it has (does it
 > read the sensors.conf file? Where is the lm-sensors code that does this?)
 >

libsensors will give you access to all hwmon IC's the kernel knows about,
all drivers which implement the hwmon interface register themselves as
being part of the hwmon class, you can find out which IC's you have
by looking under /sys/class/hwmon

Then it finds out what sort of inputs the IC has (and what sort of
settings (min / max limits for alarms, alarm, etc) by looking at the files
under /sys/class/hwmon/hwmon#/device, these files follow the hwmon
sysfs API which is documented in the kernel tree, you can find it
online here:
http://www.mjmwired.net/kernel/Documentation/hwmon/sysfs-interface

Only then it looks at sensors.conf, to see if there is anantry for the
IC it found and within that entry an entry for the input. If it finds such
an entry that can tell it 3 things.
1: This input should be ignored (in which case it will forget about the input)
2: The label for the input (a pretty name to show for this)
3: A conversion formula to go from the raw pin measurement to what is actually
    being measured.

> o lm-sensors source code that utilizes the kernel drivers that sit in
> /drivers/hwmon directory. Could you point me to this code?
>

That code lives under the lib directory. But all it basically does is
read the files under /sys/class/hwmon/hwmon#/device, and when
a scaling formula is given in sensors.conf apply that and then return
the value.

Regards,

Hans

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-05-29  7:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-28 14:00 [lm-sensors] lm-sensors benefits Rob Bloom
2009-05-29  7:36 ` Hans de Goede

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.