> Has someone else made a better/more stable version of this? If not, then
> I wouldn't mind making this a pet project if I can get access to the
> technical info. Ideas?
You can get megabytes of PDF's about the LM75, LM78, LM79 and friends at
www.national.com (great site !).
As for the module you mentioned, I've been using a slightly different
module too, which talks to the LM78 using the ISA bus too.
This is probably *not* the way to go. The definitive better way is to add
support for the SMBus (System Management Bus), which is a slightly
bastardised I2C, and use it to talk to the various SMBus-enabled chips.
Currently, only two SMBus controllers exists (AFAIK) : the Intel 82371AB
(one of the two or three Big Chips which make an Intel MB chipset since
at least Triton III), and one recent southbridge from SiS.
The devices accessible with this bus as for now are :
1) Thermal and tachymetric probes
2) SDRAM bank information (for the ones which have bits of EEPROM.
I'd really like to find a pointer to any information on this !)
3) Smart Battery stuff. The SBS (www.sbs-forum.org) seems
now to be well adopted by the laptop makers, and looks like a low-level
synonym for ACPI. Using the SMBus, you can 'talk' to each battery
(there can be more than one) and query it about its nominal and currently
estimated autonomy, ask the charger if it's connected to the AC, etc.
I'm thinking of doing a /proc/bus/SMbus to hold this data, with each
component found giving its status in a file, whose name would be based on
its I2C identificator (+ MUX ID in the case of multiplexed batteries).
With a carefully designed layout, a userland script could simply cat all
files into its input, or search a specific file for a specific component.
Another way to show the information would be to give it in a slightly more
abstract way. IE, regardless if you have an LM78, two 75's, or a HecetaII,
you'd get /proc/bus/SMbus/thermal/01, 02 and 03 (with basically the same
information in each), then on chips where that makes sense
/proc/bus/SMbus/fans/01 and 02, etc.
Or perhaps the chip-specific raw data belong to /proc/bus/SMbus but the
'cooked' thermal, fan and battery information belong to
/proc/sys/status... Having both simultaneously may even make sense
(depending on whether the client software wants to know what components
the motherboard is made with, or simply wants to access its features)
Hmmm... thinking of it, cooking up the raw data may very well be the job
of a userland library (but how to keep the lib and kernel in sync
regarding which chips they support ? One way is wrong, the other leads to
bloat. Ack !)
Since the LM78 and up (LM79 and Intel HecetaII) are also capable of
asserting an interrupt when the temperature goes above a certain
(programmable) level, or when the fans stop working, that'd be also great
to have something to put behind these triggers...
To make things clean, IMHO, there's got to be three layers between the
/proc interface and the devices :
- a low-level chipset-specific driver (IE one for the i82371AB,
one for the SiS), which handles the chip-specific host and slave
protocols, including getting slave-initiated communications (if we want to
make use of the watchdogs).
- a middle-level SMBus interface, providing hardware-independent
primitives to send, receive and expect data from a given SMbus slave.
- a high-level "system status" interface, wich would provide
'standard' models of features (this one would provide a uniform view of
what a thermal probe, a fan, or a battery is). These 'standard' models
would of course expose themselves via /proc (I propose /proc/sys/status).
If things are well done, there's no reason this "system status" thing
assumes the SMBus is used (after all, not everything is x86). Also, a
direct ISA-bus LM78 driver could still hook itself up there.
- a driver for each chip which can be found on the SMBus, which
would register itself to the middle-level SMBus API, on one end, and
provide a raw /proc interface (probably in /proc/bus/SMbus). It would also
register with the high-level interface in order to give models of its
feature (for instance, an LM78 would declare three thermal probes and two
fans with watchdog capabilities. A single LM75 would declare a single
thermal probe. The SBS driver would show each battery, and hide the
multiplexer (or make access to each individual battery transparent).
Wow, exciting things to do (certainly not before 2.3)
I'm going to be totally offline and off computers starting next sunday,
for two months, but I've been planning to start doing serious stuff on the
SMBus in september.
-- Cyrille
------------------------------
Zog Zog
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu