* The i2c package can no longer be compiled as part of the lm_sensors tree
* The archive of the i2c package is removed
* smbus, i2c-dev and i2c-proc modules and headers have been removed; they
are now completely integrated into the i2c package
* The fake i2c.h header has been removed; this also allowed us to remove
the ugly LM_SENSORS and TBD defines.
* A new variable I2C_HEADERS is introduced in the Makefile. This allows
us to install the i2c headers in, for example, /usr/local/include/linux.
* All files now include <linux/i2c.h> instead of "i2c.h" and "smbus.h"
Status: 'make dep' works, all the right include files are found. 'make all'
does not yet work.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@496 7894878c-1315-0410-8ee3-d5d059ff63e0
the results to the display. Only the first four lines are read, and only
the first 20 chars of each line are displayed.
Example use:
echo -e "hi\nthere,\nhow are\nyou?" | displayit.pl
Displays this on the display:
hi
there,
how are
you?
It doesn't get much simpler than this!
TODO: The code isn't very efficient and goes slow for what it is doing.
It assumes that the display is 20x4 (easily changable). And, it assumes
that there is only one display. This is really more of a simple example
than a feature-rich app.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@483 7894878c-1315-0410-8ee3-d5d059ff63e0
Now prints out what kind of sensor it is.
Also separated alarms for temp2 and temp3 for 782d/783s (they are
a single bit for 781d).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@400 7894878c-1315-0410-8ee3-d5d059ff63e0
The old documentation of Phil is still present at the bottom of the file.
Phil may decide to remove it.
In the driver, file 'status' is renamed to 'alarms' and masked to display
only the alarm bits. This fits more closely with other drivers, and the
remaining bit was not interesting anyway.
I fixed a problem that made insertion of the module impossible (I made a
typo when I introduced the insmod parameters) *** Someone else seems to
have changed this at almost the same moment?!? Now it is correct. ***
The MAX1617 and MAX1617A are now also supported by the library.
Once more, some slight formatting changes are made in the documentation
generators (some columns were made wider).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@395 7894878c-1315-0410-8ee3-d5d059ff63e0
Also a very slight formatting improvement for the module parameters
documentation script, and a typo from the LM78 documentation removed.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@393 7894878c-1315-0410-8ee3-d5d059ff63e0
This program scan the C-sources of the library and all kernel modules and
outputs everything it can find about all features.
To do: sort features and add command-line parameters, implement slightly
better layout.
The perl program completely replaces the C program and already has
much more functionality.
This program will be very helpful to write the kernel module documentation,
and especially to keep it up-to-date: as the C sources are examined,
updates need only be done at one place, in the source code.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@384 7894878c-1315-0410-8ee3-d5d059ff63e0
This one was easy. A MAX1617 is just a MAX1617A with better detection.
Life is beautiful!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@375 7894878c-1315-0410-8ee3-d5d059ff63e0
Detection is completely impossible, but sensors-detect now assumes with a
confidence of 1 (the lowest possible) that any chip in the LTC1710 address
range is a real LTC1710. Perhaps I should remove this again, as I don't
think this chip will be encountered 'in the wild' if your name is not Phil -
in which case you would have soldered it to your SMBus yourself, so you
should know what you are doing...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@372 7894878c-1315-0410-8ee3-d5d059ff63e0
Also fixed a small lm78 problem and synchronised the detect script with
the Winbond detection.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@341 7894878c-1315-0410-8ee3-d5d059ff63e0
The detection program can now be told that it should probe for more
addresses than the kernel driver module; it automatically generates
the necessary insmod parameters for the module if chips are found on
these non-standard addresses. Very useful for the LM78, for instance;
the driver still only check 0x20-0x2f, but the probe program checks
all addresses.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@336 7894878c-1315-0410-8ee3-d5d059ff63e0
I've reviewed and applied the patch, but I would like some others to review
these commits too, to be safe.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@327 7894878c-1315-0410-8ee3-d5d059ff63e0
Supported insmod parameters:
ignore, ignore_range
probe, probe_range
force, force_lm78, force_lm78j, force_lm79
force* overrules ignore* overrules probe*
The *_range parameters need three elements for each specification:
bus,start_addr,end_addr
The address ranges are inclusive.
The other parameters need two elements for each specification:
bus,addr
In each case, '-1' stands for 'any I2C bus', and 9191 stands for
'the ISA bus' (Bonus question: who can figure out why I choose 9191?)
In each case, just append if you want several specification, for example:
insmod lm78 probe=9191,0x2a0,1,0x56
force_* does no detection, not even chip detection; it blindly assumes
you know what you are doing. plain force does the chip detection, but
nothing else; but it can still fail if the register read-out does not
match a chip type.
Detection is done in exactly the same way as sensors-detect, except that
only the range 0x20-0x2f is examined by default. This needs to be
synchronized somehow with the detect script. I would rather scan the whole
I2C address range, but with those clueless PIIX4 hangs when clock chips
are read, that would simply give too much trouble.
The detect script has slightly better ISA detection now, too.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@325 7894878c-1315-0410-8ee3-d5d059ff63e0
* Either Phil had not done a 'cvs update', or I forgot a 'cvs commit'; anyway,
the last changes to detect.pl have been ported to sensors-detect.
* Added a rule to the Makefile fragment to install it in $(SBINDIR).
* Added SBINDIR to the main Makefile.
* Deleted detect.pl
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@323 7894878c-1315-0410-8ee3-d5d059ff63e0
removed in1 and added in6 for 783s to keep compatibility
with 781d/782d. So 783s has no in1. sorry.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@313 7894878c-1315-0410-8ee3-d5d059ff63e0
* No more redefined complaints of MODULE_* symbols for 2.0 kernels
This was introduced by the last archive of Simon
* Correct load order of adapters in detect script modprobe report
You can't assume things come out of a hash in the same order as you
put them in, of course :-(
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@303 7894878c-1315-0410-8ee3-d5d059ff63e0
detection bug
The lesson of today: the control variable in foreach loops is local to the
loop and regains his former value on exit of the loop. Oops.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@298 7894878c-1315-0410-8ee3-d5d059ff63e0
