VRM for all drivers. Same was done it Linux 2.6 some times ago.
Also comment out all "set vrm" lines in sensors.conf.eg, as Linux 2.6
now accurately deduces the VRM from the CPU model.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3190 7894878c-1315-0410-8ee3-d5d059ff63e0
The new SMBus PEC implementation doesn't support PEC emulation on
non-PEC non-I2C SMBus masters, so we can drop all related code.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3177 7894878c-1315-0410-8ee3-d5d059ff63e0
Discard I2C_FUNC_SMBUS_*_PEC defines. i2c clients are not supposed to
check for PEC support of i2c bus drivers on individual SMBus
transactions, and i2c bus drivers are not supposed to advertise them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3176 7894878c-1315-0410-8ee3-d5d059ff63e0
some months ago but we omitted to do the same in i2c-dev.h.
Drop I2C_FUNC_SMBUS_EMUL, it is meant as a convenient shortcut for plain
I2C bus drivers and has no use in user-space.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3107 7894878c-1315-0410-8ee3-d5d059ff63e0
extra byte is required for block process call SMBus transactions. This
has been true for three weeks around June 2002, but no more since, so
it is about time that we drop this comment and fix the definition.
Spotted by Hideki Iwamoto.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3100 7894878c-1315-0410-8ee3-d5d059ff63e0
<klh@google.com> received Sept. '04.
No changes by me other than include file path fixups.
Compiles, but will not insmod without i2c-core changes
or stubs to add xxx_nolock() functions.
-----------------
Here you go. I apologize for the fact this code is not integrated
into the lm_sensors package structure and thus will require you to
make various little updates. But I really wanted to get this out
before I'm yanked away again, and am pretty sure you can do it much
faster than I can figure out what needs to be done!
BTW the kernel files are built against 2.4.x where x varies; 18 and 19
should work.
Feel free to clean up anything.
--Ken
On Sat, 18 Sep 2004, Mark Studebaker wrote:
>>> > On Tue, 7 Sep 2004, Mark Studebaker wrote:
>>
>>>> >>sure, send it over.
>>>> >>Sorry for delay, your mail got buried by other mail and just now spotted it.
>>>> >>mds
>>>> >>
>>>> >>Ken Harrenstien wrote:
>>>> >>
>>>
>>>>> >>>It turned out to be a while before I could get back to this, but
>>>>> >>>everything's been working for a while now and I'd like to send in the
>>>>> >>>new pca954x driver.
>>>>> >>>
>>>>> >>>I was looking at the list in the "new_drivers" file -- it *is* kind of
>>>>> >>>intimidating. Since some of the changes affect core i2c files, I was
>>>>> >>>hoping that what I could do to start with is just send you a tar of
>>>>> >>>the modified files in their entirety, or a patch-diff of the changes
>>>>> >>>against the 2.8.7 distribution, so you can scope things out and verify
>>>>> >>>they're on the right track for acceptance. The following files are
>>>>> >>>the ones I've changed so far:
>>>>> >>>
>>>>> >>> New:
>>>>> >>> Documentation/i2c/virtual_i2c
>>>>> >>> drivers/i2c/i2c-virtual.c
>>>>> >>> drivers/sensors/pca954x.c
>>>>> >>> include/linux/i2c-virtual.h
>>>>> >>> Patched:
>>>>> >>> Documentation/Configure.help
>>>>> >>> drivers/i2c/Makefile
>>>>> >>> drivers/i2c/Config.in
>>>>> >>> drivers/i2c/i2c-core.c
>>>>> >>> drivers/sensors/Makefile
>>>>> >>> drivers/sensors/Config.in
>>>>> >>> include/linux/i2c-id.h
>>>>> >>> include/linux/i2c.h
>>>>> >>>
>>>>> >>>
>>>>> >>>I plan to write some additional doc once I know that the code itself
>>>>> >>>is acceptable, and you then can tell me what other files need to be
>>>>> >>>updated.
>>>>> >>>
>>>>> >>>To answer a couple other issues you raised:
>>>>> >>>
>>>>> >>>On Thu, 24 Jun 2004, Mark Studebaker wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>
>>>>>> >>>>(copying the mailing list, already forwarded the first mail to the list)
>>>>>> >>>>
>>>>>> >>>>First I want to ask whether you are working on kernel 2.4 or 2.6.
>>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>2.4.
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>
>>>>>> >>>>Third, you may not have realized that Khali recently did a (2.4 kernel) pca9540 driver.
>>>>>> >>>>It is in our sensors package. It however doesn't do any of the bootstrapping or
>>>>>> >>>>bus registering either. It may or may not help you.
>>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>I saw it in the 2.8.7 distrib, and used parts of it as a template.
>>>>> >>>The pca954x driver will support that chip, although the external /proc
>>>>> >>>interface it presents is necessarily different.
>>>>> >>>
>>>>> >>>--Ken
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2765 7894878c-1315-0410-8ee3-d5d059ff63e0
Date: Thu, 18 Dec 2003 22:42:36 +0100
From: Haakon Riiser <haakon.riiser@fys.uio.no>
To: sensors@Stimpy.netroedge.com
Subject: lm_sensors 2.8.2 / DESTDIR / root
The reason for this email is that I always try to avoid running
Makefiles as root, even during 'make install'. Therefore, I
always use the DESTDIR feature, when it's available. Until today,
I always built i2c and lm_sensors by doing
$ make
$ make -i install DESTDIR=/foo
$ cd /foo && su root && fix permissions/ownership && install
The -i flag to make install is a kludge to avoid having to be root
while installing to the DESTDIR, and it's only required because
the files are installed with "-o root -g root". Using the -i
flag is of course not a good idea, since more fatal errors can
easily fly by undetected.
Today, I upgraded to Linux 2.6.0, and tried a similar install
procedure for lm_sensors, except that the make target is now "user"
and the install target is "user_install". I now noticed that the
DESTDIR variable is not used everywhere in "user_install", so I
couldn't use the -i kludge anymore. Instead, I wrote a patch that
removes the "-o root -g root" arguments to install everywhere, and
I also tried to add DESTDIR to all files/directories installed.
(The patch only applies to lm_sensors, not i2c, since only
lm_sensors is required in Linux 2.6.0.)
There's really no reason to say -o root -g root anyway, since if you
do install directly with make install, you have to be logged in as
root, and then the files will get the right ownership by default.
Much of the point of installing to a temporary DESTDIR is that you
don't have to be root, and that you can prepare the installation
by hand. Fixing the ownership is trivial:
chown -R root.root $DESTDIR
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2189 7894878c-1315-0410-8ee3-d5d059ff63e0
Copy sysctl enums to chip drivers from sensors.h for now,
as seen in drivers included in 2.5 tree. File no longer included
from kernel side.
Apply i2c-proc change in CVS tagged -km2.
Partial clean and sort of includes everywhere.
Add i2c-dev.h, as a partial copy from i2c.
Add to sensors.h from i2c-proc.h to compile things.
Remove i2c-isa.h.
Reflect header file changes to lib/ and prog/.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1705 7894878c-1315-0410-8ee3-d5d059ff63e0
This driver is a copy of vt1211, which is almost identical.
The vt1211 is a super i/o chip and the vt8231 is a PCI chip.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1501 7894878c-1315-0410-8ee3-d5d059ff63e0
provides and API for NVRAM and RTC drivers to sit on top of this. An example
of drivers that uses this API are the Frodo RTC and NVRAM drivers.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1433 7894878c-1315-0410-8ee3-d5d059ff63e0
Replace VID_FROM_REG() with vid_from_reg() in new sensors_vid.h.
Update library so it can be set in sensors.conf.
Add new documentation. Update mkpatch for new file.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1352 7894878c-1315-0410-8ee3-d5d059ff63e0
From: Aurelien Jarno <aurelien@aurel32.net>
Hello,
I have to use the pcf8574 chip with my I2C interface, however, the pcf8574
drivers in lm-sensors is a bit basic. It supposes the pin P1 is used as an
input and the others pin as outputs.
Attached is a patch which corrects that, providing to files in /proc
interface, one for writting, the other for reading. It also modifies a bit
the driver to support the pcf8574a (it is a pcf8574 with a different address
range), and add a documentation file in doc/chips.
The patch also includes some cosmetic changes in the pcf8591 driver I wrote
previously, that is to say it modify the chip name in some places I had
forgotten to change when I made a copy/paste from another driver.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1318 7894878c-1315-0410-8ee3-d5d059ff63e0
The following patch does the following:
Fixed bug with not all alarms enabled.
Added ability to read battery voltage
Select temperature sensor type at module load time.
Added setting for Inside Technologies 786LCD board to example config file
I also fixed what looked like a typo in the existing it87 section where
in6_min/max was set twice and in7 was not set. As commented I think
the equation for the negative voltages are wrong but without that motherboard
I can't verify.
With the 786LCD board sensors-detect reports a lm78 which doesn't
exist and a sis5595 which may be part of the SIS630 chip but doesn't
perform the monitoring. The it8705F/SIS950 which is on the board is
reported as a misdetect. I didn't know enough about the various chips
to figure out how to get correct detections.
David Gesswein
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1146 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare