[lm-sensors] New Abit uGuru driver + libsensors patch,

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Hans de Goede]

Hi All,

As promised some time ago here is a new version of the Abit uGuru 
driver, this version fully supports the sensor part of the uGuru, that 
means it supports the following:

-reading all sensors
-reading and writing min/max settings for all sensors
-reading/writing settings for all sensors (enable alarm, beep, shutdown)
-reading alarms
-configuring the fan speed control (quiet fan or whatever buzzword)

I would like to submit the libsensors part here and the driver upstream, 
so please review.

Thanks,

Hans


For some more info I've also written a small readme, see Attachment.
-------------- next part --------------
Abit Uguru driver README.
============
This driver supports the sensor part of the custom Abit uGuru chip found
on Abit uGuru motherboards. Currently it has been tested on an Abit KV8
Pro, AV8, AX8 and AN8-SLI. The openguru program this driver is based on
has also been successfully tested on: Abit AV8 3rd Eye, AN8 Ultra and AN7.

Unfortunatly there are no specs for this chip, this driver is based on reverse
enginering done by Olle Sandberg <ollebull@gmail.com> and some additional
reverse engineering done by me. I would like to express my thanks to Olle,
this driver couldnot have been written without his efforts.

Because of the lack of specs only the sensors part of the uGuru is
supported. IOW the voltage / clock programming is NOT supported.


Installing:
=====
Driver
------

This version of the driver is meant for out of tree compilation, although it
should work fine in tree, I don't have the makefile mods to make it work
in tree. Because of rescent hwmon api changes this driver needs kernel
2.6.13 or newer, compiled with sensors support.

Just type "make" in the directory containing Makefile and abituguru.c . This
will give you an abituguru.ko file, you can copy this to
/lib/modules/xxx/kernel/drivers/hwmon if you want, or use it from its current
location.

To load the driver type:
modprobe i2c-isa
modprobe hwmon
insmod <path-to>/abituguru.ko

If the driver fails to load you can try:
insmod <path-to>/abituguru.ko force=1

Now you should have a /sys/bus/i2c/devices/9191-00e0/ dir with a bunch of
files for all your sensors, you can read them with "cat <file>".

Userspace support
-----------------
To make libsensors programs (sensors ksensors) recognize the driver you
also need to patch libsensors, this can be done by checking out the latest
version of the lm_sensors code out of CVS, applying userspace.patch to the
lm_sensors source and then building and installing libsensors.

Once libsensors is installed you need to edit /etc/sensors.conf to match
your motherboard, the Abit uGuru part is at the bottom of the file. If you
have a motherboard which is not listed there I would appreciate it if you
could send me a mail with the settings for your motherboard.

Now run "sensors" and enjoy. Note: support for reading the alarms hasn't been
added to userspace yet.


Optional features
========
There are several files under /sys/bus/i2c/devices/9191-00e0/ for which
libsensors doesn't have support but which may still be usefull. Note: all
filenames below are relative to /sys/bus/i2c/devices/9191-00e0/ .

To set read/write values you can use:
echo "<value>">/sys/bus/i2c/devices/9191-00e0/<file>

Sensors
-------

* alarm_in
This read only file is a bitmask containing a 1 for all volt sensors who's
reading is or has been past its tresholds. Note that all bitmasks are read
decimal when catting, so if the first 11 volt sensors are past there treshold
this file will contain 2047. If in2 is past its treshold it will hold 4, etc.

* alarm_temp, alarm_fan
Idem, but then for temp resp fan sensors.

* enable_in, enable_temp, enable_fan
This read/write (decimal) bitmask contains a 1 for all sensors whos alarm is
enabled. If a sensors alarm is not enabled, passing its treshold will not
result in a 1 showing up in alarm_in, nor will it beep or cause a shutdown.

* beep_in, beep_temp, beep_fan
Read/write (decimal) bitmask, enabled sensors with a 1 in this bitmask will
cause the PC-speaker to beep if an alarm occurs.

* shutdown_in, shutdown_temp, shutdown_fan
Read/write (decimal) bitmask, enabled sensors with a 1 in this bitmask will
cause the computer to shutdown if an alarm persist for a certain amount of
time (usually 30 seconds).

Fan PWM (speed control) (only fans 1-3)
---------------------------------------

* enable_fan_pwm
This read/write (decimal) bitmask contains a 1 for all fans whos speed is
controlled depending on the temperature, fans for which pwm is disabled or
which don't have a pwm (fan > 3) always run at max speed.

* fanX_temp_sensor
This read/write file contains the number of the temperature sensor to use to
control the speed of the fan. It is wise to never use a different sensor no
then 1 for fan 1 (cpu temp for cpu fan). For other fans you can play with
this.

* fanX_temp_min
This read/write file contains the temperature in degrees celcius below which
the fan will always run at its lowest speed.

* fanX_temp_max
This read/write file contains the temperature in degrees celcius above which
the fan will always run at its maximum speed.

* fanX_pwm_min
This read/write file contains the minium speed at which the fan will rotate,
this is a value between 0 and 255 with 0 being standing still and 255 being
max speed. The uGuru seems to ignore values below 170, which is a good thing
since a to low voltage to the fan could cause it to stand still and slowly
burn away.

* fanX_pwm_max
This read/write file contains the maximum speed at which the fan will
rotate, in the same format as fanX_pwm_min.


Questions/comments
=========

You can send any questions you have to me at: <j.w.r.degoede@hhs.nl>, or to
the lm_sensors mailinglist:
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors


Copyright/Warranty
=========

This software is licenced under the GNU GPL v2, see COPYING, and as such
comes WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Hans de Goede]

The driver.

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Hans de Goede]

The libsensors patch, I still need to add alarm support. I understand 
that is sorta hard todo for 2.6 only drivers, can someone give my any hints?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: userspace.patch
Type: text/x-patch
Size: 13006 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20051021/f5917068/userspace.bin

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Jean Delvare]

Hi Hans,

> The driver.

-ENOPATCH

--
Jean Delvare

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> 
>>The driver.
> 
> 
> -ENOPATCH
> 

Yes, its a new driver, so nothing to diff against, would a diff against 
/dev/null really make you happier?

Can someone please take a look at the driver and give me some proper 
feedback?

Thanks & Regards,

Hans

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Jean Delvare]

> > >The driver.
> > 
> > -ENOPATCH
> 
> Yes, its a new driver, so nothing to diff against, would a diff against 
> /dev/null really make you happier?

No, I mean, there is no attachement at all.

And yes, a patch would still make me happier, because it would include
the relevant changes to the kernel build system so that we can check
that your code compiles properly, and people could test your driver
more easily too.

> Can someone please take a look at the driver and give me some proper 
> feedback?

Not before you actually send something to us ;)

Note that the mailing list is configured to drop any unacceptable
attachement. Maybe that's what happened. Accepted types are text/plain
and text/x-patch. Make sure your attachement has the proper type. If
you think there is a different type we should accept, please let us
know.

-- 
Jean Delvare

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Hans de Goede]

Ah,

Now I understand, Thunderbird somehow chooses application/octet as type 
for C-source code. Reattaching this time as .txt file.

About patch vs c-code file, I don't have any changes to the kernel build 
system, one of the blessings of the new buildsystem is that it is very 
easy to build modules out of tree and that is what I've been doing I've 
also attached a Makefile.txt for you to build it with.

Thanks & Regards,

Hans



Jean Delvare wrote:
>>>>The driver.
>>>
>>>-ENOPATCH
>>
>>Yes, its a new driver, so nothing to diff against, would a diff against 
>>/dev/null really make you happier?
> 
> 
> No, I mean, there is no attachement at all.
> 
> And yes, a patch would still make me happier, because it would include
> the relevant changes to the kernel build system so that we can check
> that your code compiles properly, and people could test your driver
> more easily too.
> 
> 
>>Can someone please take a look at the driver and give me some proper 
>>feedback?
> 
> 
> Not before you actually send something to us ;)
> 
> Note that the mailing list is configured to drop any unacceptable
> attachement. Maybe that's what happened. Accepted types are text/plain
> and text/x-patch. Make sure your attachement has the proper type. If
> you think there is a different type we should accept, please let us
> know.
> 
-------------- next part --------------
/*
    abituguru.c - Part of lm_sensors, Linux kernel modules
                  for hardware monitoring

    Copyright (c) 2005  Hans de Goede <j.w.r.degoede@hhs.nl>

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/*
    This driver supports the sensor part of the custom Abit uGuru chip found
    on Abit uGuru motherboards. Currently it has been tested on an Abit KV8
    Pro, AV8, AX8 and AN8-SLI. The openguru program this driver is based on
    has also been successfully tested on: Abit AV8 3rd Eye, AN8 Ultra and AN7.
    
    Unfortunatly there are no specs for this chip, this driver is based on the
    (reverse enginered) openguru program by Olle Sandberg <ollebull@gmail.com>.
    You can find the first version of his program which only supports reading
    the sensors not the min/max values at:
    http://hem.bredband.net/b330708/oguru/oguru.tar.gz
    I would like to express my thanks to Olle, this driver couldnot have been
    written without his efforts.
    
    Because of the lack of specs only the sensors part of the uGuru is
    supported. A word of caution to those who want to experiment and see if
    they can figure the voltage / clock programming out, I tried reading and
    only reading banks 0-0x30 with the reading code used for the sensor banks
    (0x20-0x28) and this resulted in a permanent reprogramming of the voltages,
    luckily I had the sensors part configured so that it would shutdown my
    system on any out of spec voltages which proprably safed my computer (after
    a reboot I managed to immediatly enter the bios and reload the defaults).
    This probably means that the read/write cycle for the non sensor part is
    different from the sensor part.
    
    This driver used via686a.c as a skeleleton since that is an ISA only chip
    like the Abit uGuru (AFAIK).
*/
/*  History:
    
    version 0.9:
    -initial release, only reading the sensors is supported.
    version 0.9.1:
    -Olle has done some more reverse engineering, so now reading the min/max
     values and the settings is also supported.
    -modified the driver to work with the new hwmon seperation in 2.6.13,
     As a result this version requires 2.6.13 or higher.
    -simplified the ready code.
    -added a abituguru_wait function which waits for the uguru the reach
     a certain state, use this everywhere instead of having seperate loops
     with there own timeouts scatered over the place.
    -use array sysfs initalisation instead of #define hell.
    -fix rounding of values.
    version 0.9.2:
    -Olle has now reverse engineered the writing of the flags and min/max
     values, so now writing the min/max values is also supported. 
    -Now that we've seen testing of more mainboards, it turns out that
     the way the volt inputs are hooked up isn't identical for all mainboards,
     also causing the ranges for the volt inputs to be not constant. Because
     of this conversion for the voltage sensors has been removed, the raw
     register values are now returned. Sample entries for known mainboards
     will be added to sensors.conf .
    -During this testing, it has also been shown that certain addresses in
     bank1 (0x0D) sometimes are attached to a temp sensor and sometimes to a
     volt sensor. Luckily with some tricks this can be detected, so now we
     detect if a sensor is connected and what type for all addresses in bank1.
    version 0.9.3:
    -userspace expects temp and in values to be in milli units, so they are now
     multiplied by 1000 in show and divided by 1000 on set.
    -Now that the min/max values can be written I've been able to trigger some
     false alarms and have managed to find out how the alarms work, so now
     reading the alarms is supported also.
    version 0.9.4:
    -reshuffle / cleanup (mainly bank1 handling)
    -fix some race conditions
    version 0.9.5:
    -Reading/writing the settings (enable alarm, beep, shutdown) is now also
     supported.
    version 1.0.0:
    -Added support for controling the fan PWM (speed control).
    -Add force param to skip "detection" .
*/

#include <linux/module.h>
#include <linux/slab.h>
#include <linux/pci.h>
#include <linux/jiffies.h>
#include <linux/i2c.h>
#include <linux/i2c-isa.h>
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
#include <linux/init.h>
#include <asm/io.h>

/* This is needed untill this gets merged upstream */
#ifndef __SENSOR_DEVICE_ATTR
#define __SENSOR_DEVICE_ATTR(_name,_mode,_show,_store,_index)	\
{	.dev_attr =	__ATTR(_name,_mode,_show,_store),	\
	.index =	_index,					\
}
#endif

/* Debugging output is enabled for now, since this driver is still in the
   testing fase */
#define ABIT_UGURU_DEBUG	1
/* Banks */
#define ABIT_UGURU_ALARM_BANK	0x20 /* 3 bytes, 2 bytes bank1, 1 byte bank2 */
#define ABIT_UGURU_SENSOR_BANK1	0x21 /* volt and temp */
#define ABIT_UGURU_FAN_PWM	0x24 /* 3x 5 bytes */
#define ABIT_UGURU_SENSOR_BANK2	0x26 /* fans */
/* uGuru sensor bank 1 flags */			     /* Alarm if: */
#define ABIT_UGURU_TEMP_HIGH_ALARM_ENABLE	0x01 /*  temp over warn */
#define ABIT_UGURU_VOLT_HIGH_ALARM_ENABLE	0x02 /*  volt over max */
#define ABIT_UGURU_VOLT_LOW_ALARM_ENABLE	0x04 /*  volt under min */
#define ABIT_UGURU_TEMP_HIGH_ALARM_FLAG		0x10 /* temp is over warn */
#define ABIT_UGURU_VOLT_HIGH_ALARM_FLAG		0x20 /* volt is over max */
#define ABIT_UGURU_VOLT_LOW_ALARM_FLAG		0x40 /* volt is under min */
/* uGuru sensor bank 2 flags */			     /* Alarm if: */
#define ABIT_UGURU_FAN_LOW_ALARM_ENABLE		0x01 /*   fan under min */
/* uGuru sensor bank common flags */
#define ABIT_UGURU_BEEP_ENABLE			0x08 /* beep if alarm */
#define ABIT_UGURU_SHUTDOWN_ENABLE		0x80 /* shutdown if alarm */
/* uGuru fan PWM (speed control) flags */
#define ABIT_UGURU_FAN_PWM_ENABLE		0x80 /* enable speed control */
/* Values used for conversion */
#define ABIT_UGURU_FAN_MAX	15300 /* RPM */
/* Bank1 sensor types */
#define ABIT_UGURU_IN_SENSOR	0
#define ABIT_UGURU_TEMP_SENSOR	1
#define ABIT_UGURU_NC		2

/* All the variables below are named identical to the oguru and oguru2 programs
   reverse engineered by Olle Sandberg, hence the names might not be 100%
   logical. I could come up with better names, but I prefer keeping the names
   identical so that this driver can be compared with his work more easily. */
/* Two i/o-ports are used by uGuru */
#define ABIT_UGURU_BASE		0x00E0
#define ABIT_UGURU_CMD		0x00 /* Used to tell uGuru what to read and to read the actual data */
#define ABIT_UGURU_DATA		0x04 /* Mostly used to check if uGuru is busy */
/* uGuru status' */
#define ABIT_UGURU_STATUS_WRITE	0x00 /* Ready to be written */
#define ABIT_UGURU_STATUS_READ	0x01 /* Ready to be read */
#define ABIT_UGURU_STATUS_INPUT	0x08 /* More input */
#define ABIT_UGURU_STATUS_READY	0x09 /* Ready to be written */


/* Insmod parameters */
static int force;
module_param(force, bool, 0);
MODULE_PARM_DESC(force, "Set to one to force detection.");

/* For the Abit uGuru, we need to keep some data in memory.
   The structure is dynamically allocated, at the same time when a new
   abituguru client is allocated. */
struct abituguru_data {
	struct i2c_client client;
	struct class_device *class_dev;
	struct semaphore update_lock;
	char uguru_ready;	/* is the uguru in ready state? */
	char valid;		/* !=0 if following fields are valid */
	unsigned long last_updated;	/* In jiffies */

	/* Bank 1 data */
	u8 bank1_sensors[2];	/* number of [0] in, [1] temp sensors */
	u8 bank1_address[2][16];/* addresses of [0] in, [1] temp sensors */
	/* This array holds 16 x 4 entries for all the sensors in bank 1
	   (flags,min,max,value for voltage/..,warn,shutdown,.. for temp). */
	u8 bank1_regs[16*4];
	/* The sysfs attr for the bank1 sensors are generated automaticly */
	struct sensor_device_attribute bank1_attr[16*3];

	/* Bank 2 data, the highest number of fans currently know to be
	   attached is 6, thus 6 x 3 entries (flags, min, value). */
	u8 bank2_regs[6*3];

	/* Alarms 2 bytes for bank1, 1 byte for bank2 */
	u8 alarm_regs[3];
	
	/* Fan PWM (speed control) 3x5 bytes */
	u8 fan_pwm_regs[3*5];
};

static int abituguru_detect(struct i2c_adapter *adapter);
static int abituguru_detach_client(struct i2c_client *client);
/* Danger Will Robinson, danger! This function downs the update_lock semaphore
   in the abituguru_data struct but doesn't up it, the caller must up
   it when it is done with the returned data! */
static struct abituguru_data *abituguru_update_device(struct device *dev);

/* wait till the uguru is in the specified state */
static int abituguru_wait(struct i2c_client *client, u8 state)
{
	/* 250 was determined by trial and error, 200 works most of the time
	   but not always. I assume this is cpu-speed independent, since
	   the ISA-bus and not the CPU should be the bottleneck. */
	int lockup_cnt = 250;
	  
	while (inb_p(client->addr + ABIT_UGURU_DATA) != state)
	{
	  lockup_cnt--;
	  if (lockup_cnt = 0)
	    return -EIO;
	}
	
	return 0;
}

/* Put the uguru in ready for input state, this code assumes that
   the uguru is not already in this state.
   It is the callers responsibility to make sure it isn't! */
static int abituguru_ready(struct i2c_client *client)
{
	struct abituguru_data *data = i2c_get_clientdata(client);

	/* Reset? / Prepare for next read/write cycle */
	outb_p(0x00, client->addr + ABIT_UGURU_DATA);

	/* Wait till the uguru is ready */
	if (abituguru_wait(client, ABIT_UGURU_STATUS_READY))
		return -EIO;

	/* Cmd port MUST be read now and should contain 0xAC */
	if (inb_p(client->addr + ABIT_UGURU_CMD) != 0xAC)
		return -EIO;

#if ABIT_UGURU_DEBUG		
	/* After this the ABIT_UGURU_DATA port should contain
	   ABIT_UGURU_STATUS_INPUT */
	if (inb_p(client->addr + ABIT_UGURU_DATA) != 
	      ABIT_UGURU_STATUS_INPUT)
		return -EIO;
#endif	
	
	data->uguru_ready = 1;
	return 0;
}

static int abituguru_send_address(struct i2c_client *client,
	u8 bank_addr, u8 sensor_addr)
{
	struct abituguru_data *data = i2c_get_clientdata(client);

 	/* When we're called the uguru normally will be ready for the first
	   input and thus in ABIT_UGURU_STATUS_INPUT state. If however
	   something went wrong previously it might not be, so then we try to
	   force it into ready state. If/when the uguru is ready we send the
	   bank address, after this the uguru is no longer "ready". */
	if (!data->uguru_ready && (abituguru_ready(client) != 0))
		return -EIO;
	outb_p(bank_addr, client->addr + ABIT_UGURU_DATA);
	data->uguru_ready = 0;

	/* Wait till the uguru is ABIT_UGURU_STATUS_INPUT state again and send
	   the sensor addr */
	if (abituguru_wait(client, ABIT_UGURU_STATUS_INPUT))
		return -EIO;
	outb_p(sensor_addr, client->addr + ABIT_UGURU_CMD);
	
	return 0;
}

static int abituguru_read(struct i2c_client *client,
	u8 bank_addr, u8 sensor_addr, u8 *buf, int count)
{
	int bytes_read = 0;
	
	/* Send the address */
	if (abituguru_send_address(client, bank_addr, sensor_addr))
		return -EIO;
	
	/* And read the data */
	while((bytes_read < count) &&
	      (abituguru_wait(client, ABIT_UGURU_STATUS_READ)=0)) {
		buf[bytes_read] = inb(client->addr + ABIT_UGURU_CMD);
		bytes_read++;
	}

	/* Last put the chip back in ready state */
	abituguru_ready(client);

	return bytes_read;
}

static int abituguru_write(struct i2c_client *client,
	u8 bank_addr, u8 sensor_addr, u8 *buf, int count)
{
	int bytes_written = 0;

	/* Send the address */
	if (abituguru_send_address(client, bank_addr, sensor_addr))
		return -EIO;

	/* And write the data */
	while((bytes_written < count) &&
	      (abituguru_wait(client, ABIT_UGURU_STATUS_WRITE)=0)) {
		outb(buf[bytes_written], client->addr + ABIT_UGURU_CMD);
		bytes_written++;
	}
	
	/* Now we need to wait till the chip is ready to be read again,
	   don't ask why */
	if (abituguru_wait(client, ABIT_UGURU_STATUS_READ))
		return -EIO;
	
	/* Cmd port MUST be read now and should contain 0xAC */
	if (inb_p(client->addr + ABIT_UGURU_CMD) != 0xAC)
		return -EIO;
	
	/* Last put the chip back in ready state */
	abituguru_ready(client);

	return bytes_written;
}

/* Detect sensor type. Temp and Volt sensors are enabled with
   different masks and will ignore enable masks not meant for them.
   This enables us to test what kindoff sensor we're dealing with.
   By setting the alarm treshholds so that we will always get an
   alarm for sensor type X and then enabling the sensor as sensor type
   X, if we then get an alarm it is a sensor of type X. */
static int abituguru_detect_sensor_type(struct i2c_client *client,
	u8 sensor_addr)
{
	u8 orig_settings[3];
	u8 buf[3];
	u8 val;
	int ret = ABIT_UGURU_NC;
	
	/* First read the sensor and the current settings */
	if (abituguru_read(client, ABIT_UGURU_SENSOR_BANK1, sensor_addr, &val,
		1) != 1)	return -EIO;
	if (abituguru_read(client, ABIT_UGURU_SENSOR_BANK1+1, sensor_addr,
		orig_settings, 3) != 3)	return -EIO;
	
	/* Test val is sane / usable for sensor type detection. */
	if ((val < 10u) || (val > 245u))
		return -1; /* ? */
	
	/* Volt sensor test, enable volt low alarm, set min value ridicously
	   high. If its a volt sensor this should always give us an alarm. */
	buf[0]«IT_UGURU_VOLT_LOW_ALARM_ENABLE;
	buf[1]%4;
	buf[2]%5;
	if (abituguru_write(client, ABIT_UGURU_SENSOR_BANK1+2, sensor_addr,
		buf,3) != 3)	return -EIO;
	/* Now we need 20 ms to give the uguru time to read the sensors
	   and raise the alarm */
	set_current_state(TASK_UNINTERRUPTIBLE);
	schedule_timeout(HZ/50);
	/* Check for alarm and check the alarm is a volt low alarm. */
	if ( (abituguru_read(client, ABIT_UGURU_ALARM_BANK, 0, buf, 3) = 3) &&
	     (buf[sensor_addr/8] & (0x01<<(sensor_addr%8)) ) &&
	     (abituguru_read(client, ABIT_UGURU_SENSOR_BANK1+1,
		sensor_addr, buf, 3) = 3) &&
	     (buf[0] & ABIT_UGURU_VOLT_LOW_ALARM_FLAG) ) {
		abituguru_write(client, ABIT_UGURU_SENSOR_BANK1+2,
			sensor_addr, orig_settings, 3);
		return ABIT_UGURU_IN_SENSOR;
	}

	/* Temp sensor test, enable sensor as a temp sensor, set beep value
	   ridicously low (but not too low, otherwise uguru ignores it).
	   If its a temp sensor this should always give us an alarm. */
	buf[0]«IT_UGURU_TEMP_HIGH_ALARM_ENABLE;
	buf[1]=5;
	buf[2]\x10;
	if (abituguru_write(client, ABIT_UGURU_SENSOR_BANK1+2, sensor_addr,
		buf,3) != 3)	return -EIO;
	/* Now we need 20 ms to give the uguru time to read the sensors
	   and raise the alarm */
	set_current_state(TASK_UNINTERRUPTIBLE);
	schedule_timeout(HZ/50);
	/* Check for alarm and check the alarm is a temp high alarm. */
	if ( (abituguru_read(client, ABIT_UGURU_ALARM_BANK, 0, buf, 3) = 3) &&
	     (buf[sensor_addr/8] & (0x01<<(sensor_addr%8)) ) &&
	     (abituguru_read(client, ABIT_UGURU_SENSOR_BANK1+1,
		sensor_addr, buf, 3) = 3) &&
	     (buf[0] & ABIT_UGURU_TEMP_HIGH_ALARM_FLAG) )
		ret = ABIT_UGURU_TEMP_SENSOR;
	
	/* Restore original settings */
	abituguru_write(client, ABIT_UGURU_SENSOR_BANK1+2, sensor_addr,
		orig_settings, 3);
	
	return ret;
}

/* following are the sysfs callback functions */
static ssize_t show_bank1_reg(struct device *dev,
	struct device_attribute *devattr, char *buf)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid)
		ret = sprintf(buf, "%d\n", data->bank1_regs[attr->index]*1000);
	up(&data->update_lock);
	return ret;
}

static ssize_t show_bank2_reg(struct device *dev,
	struct device_attribute *devattr, char *buf)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid)
		ret = sprintf(buf, "%d\n",  (data->bank2_regs[attr->index]*
			ABIT_UGURU_FAN_MAX + 128) / 255);
	up(&data->update_lock);
	return ret;
}

static ssize_t store_bank1_reg(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	int val = (simple_strtoul(buf, NULL, 10) + 500) / 1000;
	ssize_t ret = -EIO;
	if (data->valid && (data->bank1_regs[attr->index] != val)) {
		u8 buf[3];
		memcpy (buf, &data->bank1_regs[attr->index & ~3], 3);
		buf[attr->index&3] = val;
		if (abituguru_write(&data->client,
			ABIT_UGURU_SENSOR_BANK1+2, attr->index/4, buf, 3) = 3)
			ret = count;
		data->valid = 0;
	}	
	up(&data->update_lock);
	return ret;
}

static ssize_t store_bank2_reg(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	unsigned long user_val = simple_strtoul(buf, NULL, 10);
	u8 reg_val = (user_val*255 + ABIT_UGURU_FAN_MAX/2) /
		ABIT_UGURU_FAN_MAX;
	ssize_t ret = -EIO;
	if (data->valid && (data->bank2_regs[attr->index] != reg_val)) {
		u8 buf[2];
		buf[0] = data->bank2_regs[(attr->index/3)*3];
		buf[1] = reg_val;
		if (abituguru_write(&data->client,
			ABIT_UGURU_SENSOR_BANK2+2, attr->index/3, buf, 2) = 2)
			ret = count;
		data->valid = 0;
	}
	up(&data->update_lock);
	return ret;
}

static ssize_t show_alarm_bank1(struct device *dev,
	struct device_attribute *devattr, char *buf)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid) {
		int i, alarm = 0;
		for (i=0; i<data->bank1_sensors[attr->index]; i++) {
			u8 address = data->bank1_address[attr->index][i];
			if (data->alarm_regs[address/8] & (0x01<<(address%8)))
				alarm |= 0x01 << i;
		}
		ret = sprintf(buf, "%d\n", alarm);
	}
	up(&data->update_lock);
	return ret;
}

static ssize_t show_alarm_bank2(struct device *dev,
	struct device_attribute *devattr, char *buf)
{
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid)
		ret = sprintf(buf, "%d\n", (int)data->alarm_regs[2]);
	up(&data->update_lock);
	return ret;
}

/* sysfs utility functions for uguru settings */
static ssize_t show_bank1_settings(struct device *dev,
	struct device_attribute *devattr, u8 setting, char *buf)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid) {
		int i, mask = 0;
		for (i=0; i<data->bank1_sensors[attr->index]; i++) {
			u8 address = data->bank1_address[attr->index][i];
			if (data->bank1_regs[address*4] & setting)
				mask |= 0x01 << i;
		}
		ret = sprintf(buf, "%d\n", mask);
	}
	up(&data->update_lock);
	return ret;
}

static ssize_t show_bank2_settings(struct device *dev, u8 setting, char *buf)
{
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid) {
		int i, mask = 0;
		for (i=0; i<6; i++) {
			if (data->bank2_regs[i*3] & setting)
				mask |= 0x01 << i;
		}
		ret = sprintf(buf, "%d\n", mask);
	}
	up(&data->update_lock);
	return ret;
}

static ssize_t store_bank1_settings(struct device *dev,
	struct device_attribute *devattr, u8 setting, const char *buf,
	size_t count)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	int i, mask = simple_strtoul(buf, NULL, 10);
	ssize_t ret = -EIO;
	if (data->valid) {
		ret = count;
		for (i=0; i<data->bank1_sensors[attr->index]; i++) {
			u8 buf[3], dirty = 0;
			u8 address = data->bank1_address[attr->index][i];
			memcpy (buf, &data->bank1_regs[address*4], 3);
			/* check if we need to enable the feature */
			if ((mask&(0x01<<i)) && ((buf[0]&setting)!=setting)) {
				buf[0] |= setting;
				dirty = 1;
			}
			/* check if we need to disable the feature */
			if (!(mask&(0x01<<i)) && (buf[0]&setting)) {
				buf[0] &= ~setting;
				dirty = 1;
			}
			if (dirty) {
				if (abituguru_write(&data->client,
					ABIT_UGURU_SENSOR_BANK1+2, address,
					buf, 3) != 3)
					ret = -EIO;
				data->valid = 0;
			}
		}
	}
	up(&data->update_lock);
	return ret;
}

static ssize_t store_bank2_settings(struct device *dev, u8 setting,
	const char *buf, size_t count)
{
	struct abituguru_data *data = abituguru_update_device(dev);
	int i, mask = simple_strtoul(buf, NULL, 10);
	ssize_t ret = -EIO;
	if (data->valid) {
		ret = count;
		for (i=0; i<6; i++) {
			u8 buf[2], dirty = 0;
			memcpy (buf, &data->bank2_regs[i*3], 2);
			/* check if we need to enable the feature */
			if ((mask&(0x01<<i)) && ((buf[0]&setting)!=setting)) {
				buf[0] |= setting;
				dirty = 1;
			}
			/* check if we need to disable the feature */
			if (!(mask&(0x01<<i)) && (buf[0]&setting)) {
				buf[0] &= ~setting;
				dirty = 1;
			}
			if (dirty) {
				if (abituguru_write(&data->client,
					ABIT_UGURU_SENSOR_BANK2+2, i,
					buf, 2) != 2)
					ret = -EIO;
				data->valid = 0;
			}
		}
	}
	up(&data->update_lock);
	return ret;
}

/* endof sysfs utility functions for uguru settings, continuation of
   normal sysfs callback functions: enables */
static ssize_t show_enable_in(struct device *dev,   
	struct device_attribute *devattr, char *buf)
{
	return show_bank1_settings(dev, devattr,
		ABIT_UGURU_VOLT_HIGH_ALARM_ENABLE|
		ABIT_UGURU_VOLT_LOW_ALARM_ENABLE, buf);
}

static ssize_t show_enable_temp(struct device *dev,   
	struct device_attribute *devattr, char *buf)
{
	return show_bank1_settings(dev, devattr,
		ABIT_UGURU_TEMP_HIGH_ALARM_ENABLE, buf);
}

static ssize_t show_enable_fan(struct device *dev,
	struct device_attribute *devattr, char *buf)
{
	return show_bank2_settings(dev, ABIT_UGURU_FAN_LOW_ALARM_ENABLE,
		buf);
}

static ssize_t store_enable_in(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	return store_bank1_settings(dev, devattr,
		ABIT_UGURU_VOLT_HIGH_ALARM_ENABLE|
		ABIT_UGURU_VOLT_LOW_ALARM_ENABLE, buf, count);
}

static ssize_t store_enable_temp(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	return store_bank1_settings(dev, devattr,
		ABIT_UGURU_TEMP_HIGH_ALARM_ENABLE, buf, count);
}

static ssize_t store_enable_fan(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	return store_bank2_settings(dev, ABIT_UGURU_FAN_LOW_ALARM_ENABLE, buf,
		count);
}

/* beeps */
static ssize_t show_beep_bank1(struct device *dev,   
	struct device_attribute *devattr, char *buf)
{
	return show_bank1_settings(dev, devattr, ABIT_UGURU_BEEP_ENABLE, buf);
}

static ssize_t show_beep_bank2(struct device *dev,   
	struct device_attribute *devattr, char *buf)
{
	return show_bank2_settings(dev, ABIT_UGURU_BEEP_ENABLE, buf);
}

static ssize_t store_beep_bank1(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	return store_bank1_settings(dev, devattr, ABIT_UGURU_BEEP_ENABLE, buf,
		count);
}

static ssize_t store_beep_bank2(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	return store_bank2_settings(dev, ABIT_UGURU_BEEP_ENABLE, buf, count);
}

/* shutdowns */
static ssize_t show_shutdown_bank1(struct device *dev,   
	struct device_attribute *devattr, char *buf)
{
	return show_bank1_settings(dev, devattr, ABIT_UGURU_SHUTDOWN_ENABLE,
		buf);
}

static ssize_t show_shutdown_bank2(struct device *dev,   
	struct device_attribute *devattr, char *buf)
{
	return show_bank2_settings(dev, ABIT_UGURU_SHUTDOWN_ENABLE, buf);
}

static ssize_t store_shutdown_bank1(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	return store_bank1_settings(dev, devattr, ABIT_UGURU_SHUTDOWN_ENABLE,
		buf, count);
}

static ssize_t store_shutdown_bank2(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	return store_bank2_settings(dev,ABIT_UGURU_SHUTDOWN_ENABLE,buf,count);
}

/* Fan PWM (speed control) */
static ssize_t show_fan_pwm_reg(struct device *dev,
        struct device_attribute *devattr, char *buf)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid)
		ret = sprintf(buf, "%d\n",
			(int)data->fan_pwm_regs[attr->index]);
	up(&data->update_lock);
	return ret;
}
        
static ssize_t store_fan_pwm_reg(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	int val = simple_strtoul(buf, NULL, 10);
	ssize_t ret = -EIO;
	if (data->valid && (data->fan_pwm_regs[attr->index] != val)) {
		u8 buf[5];
		memcpy (buf, &data->fan_pwm_regs[(attr->index/5)*5], 5);
		buf[attr->index%5] = val;
		if (abituguru_write(&data->client,
			ABIT_UGURU_FAN_PWM+1, attr->index/5, buf, 5) = 5)
			ret = count;
		data->valid = 0;
	}	
	up(&data->update_lock);
	return ret;
}

static ssize_t show_fan_pwm_sensor(struct device *dev,
        struct device_attribute *devattr, char *buf)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid) {
		/* We need to walk to the temp sensor addresses to find what
		   the userspace id of the configured temp sensor is. */
		int i;
		for (i=0; i<data->bank1_sensors[ABIT_UGURU_TEMP_SENSOR]; i++) {
			if (data->bank1_address[ABIT_UGURU_TEMP_SENSOR][i] =
			    (data->fan_pwm_regs[attr->index] & 0x0F)) {
				ret = sprintf(buf, "%d\n", i+1);
				break;
			}
		}
	}
	up(&data->update_lock);
	return ret;
}
        
static ssize_t store_fan_pwm_sensor(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
	struct abituguru_data *data = abituguru_update_device(dev);
	unsigned long val = simple_strtoul(buf, NULL, 10) - 1;
	ssize_t ret = count;
	if (!data->valid)
		ret = -EIO;
	else if (val < data->bank1_sensors[ABIT_UGURU_TEMP_SENSOR]) {
		u8 buf[5];
		u8 address = data->bank1_address[ABIT_UGURU_TEMP_SENSOR][val];
		memcpy (buf, &data->fan_pwm_regs[attr->index], 5);
		buf[0] = (buf[0]&0xF0) | address;
		if (buf[0] != data->fan_pwm_regs[attr->index]) {
			if (abituguru_write(&data->client, ABIT_UGURU_FAN_PWM+1,
				attr->index/5, buf, 5) != 5)
				ret = -EIO;
			data->valid = 0;
		}
	}
	up(&data->update_lock);
	return ret;
}

static ssize_t show_enable_fan_pwm(struct device *dev,
        struct device_attribute *devattr, char *buf)
{
	struct abituguru_data *data = abituguru_update_device(dev);
	ssize_t ret = -EIO;
	if (data->valid) {
		int i, mask = 0;
		for (i=0; i<3; i++) {
			if (data->fan_pwm_regs[i*5]&ABIT_UGURU_FAN_PWM_ENABLE)
				mask |= 0x01 << i;
		}
		ret = sprintf(buf, "%d\n", mask);
	}
	up(&data->update_lock);
	return ret;
}
        
static ssize_t store_enable_fan_pwm(struct device *dev, struct device_attribute
	*devattr, const char *buf, size_t count)
{
	struct abituguru_data *data = abituguru_update_device(dev);
	int i, mask = simple_strtoul(buf, NULL, 10);
	ssize_t ret = -EIO;
	if (data->valid) {
		ret = count;
		for (i=0; i<3; i++) {
			u8 buf[5], dirty = 0;
			memcpy (buf, &data->fan_pwm_regs[i*5], 5);
			/* check if we need to enable */
			if ( (mask&(0x01<<i)) &&
			    !(buf[0]&ABIT_UGURU_FAN_PWM_ENABLE)) {
				buf[0] |= ABIT_UGURU_FAN_PWM_ENABLE;
				dirty = 1;
			}
			/* check if we need to disable */
			if (!(mask&(0x01<<i)) &&
			     (buf[0]&ABIT_UGURU_FAN_PWM_ENABLE)) {
				buf[0] &= ~ABIT_UGURU_FAN_PWM_ENABLE;
				dirty = 1;
			}
			if (dirty) {
				if (abituguru_write(&data->client,
					ABIT_UGURU_FAN_PWM+1, i,
					buf, 5) != 5)
					ret = -EIO;
				data->valid = 0;
			}
		}
	}
	up(&data->update_lock);
	return ret;
}

/* Sysfs attr, the entries for the temp and in sensors are missing, these are
   generated automaticly, because we don't know how many temp and in sensors
   there are in bank1, luckily we can probe the uguru to find out if a sensor
   is not connected, temp or in. */
static struct sensor_device_attribute abituguru_sysfs_attr[] = {
	__SENSOR_DEVICE_ATTR(fan1_input,       0444, show_bank2_reg, NULL, 2),
	__SENSOR_DEVICE_ATTR(fan1_min,         0644, show_bank2_reg,
		store_bank2_reg, 1),
	__SENSOR_DEVICE_ATTR(fan1_temp_sensor, 0644, show_fan_pwm_sensor,
		store_fan_pwm_sensor, 0),
	__SENSOR_DEVICE_ATTR(fan1_pwm_min,     0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 1),
	__SENSOR_DEVICE_ATTR(fan1_pwm_max,     0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 2),
	__SENSOR_DEVICE_ATTR(fan1_temp_min,    0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 3),
	__SENSOR_DEVICE_ATTR(fan1_temp_max,    0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 4),
	__SENSOR_DEVICE_ATTR(fan2_input,       0444, show_bank2_reg, NULL, 5),
	__SENSOR_DEVICE_ATTR(fan2_min,         0644, show_bank2_reg,
		store_bank2_reg, 4),
	__SENSOR_DEVICE_ATTR(fan2_temp_sensor, 0644, show_fan_pwm_sensor,
		store_fan_pwm_sensor, 5),
	__SENSOR_DEVICE_ATTR(fan2_pwm_min,     0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 6),
	__SENSOR_DEVICE_ATTR(fan2_pwm_max,     0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 7),
	__SENSOR_DEVICE_ATTR(fan2_temp_min,    0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 8),
	__SENSOR_DEVICE_ATTR(fan2_temp_max,    0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 9),
	__SENSOR_DEVICE_ATTR(fan3_input,       0444, show_bank2_reg, NULL, 8),
	__SENSOR_DEVICE_ATTR(fan3_min,         0644, show_bank2_reg,
		store_bank2_reg, 7),
	__SENSOR_DEVICE_ATTR(fan3_temp_sensor, 0644, show_fan_pwm_sensor,
		store_fan_pwm_sensor, 10),
	__SENSOR_DEVICE_ATTR(fan3_pwm_min,     0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 11),
	__SENSOR_DEVICE_ATTR(fan3_pwm_max,     0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 12),
	__SENSOR_DEVICE_ATTR(fan3_temp_min,    0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 13),
	__SENSOR_DEVICE_ATTR(fan3_temp_max,    0644, show_fan_pwm_reg,
		store_fan_pwm_reg, 14),
	__SENSOR_DEVICE_ATTR(fan4_input,       0444, show_bank2_reg, NULL, 11),
	__SENSOR_DEVICE_ATTR(fan4_min,         0644, show_bank2_reg,
		store_bank2_reg, 10),
	__SENSOR_DEVICE_ATTR(fan5_input,       0444, show_bank2_reg, NULL, 14),
	__SENSOR_DEVICE_ATTR(fan5_min,         0644, show_bank2_reg,
		store_bank2_reg, 13),
	__SENSOR_DEVICE_ATTR(fan6_input,       0444, show_bank2_reg, NULL, 17),
	__SENSOR_DEVICE_ATTR(fan6_min,         0644, show_bank2_reg,
		store_bank2_reg, 16),
	__SENSOR_DEVICE_ATTR(alarm_in,         0444, show_alarm_bank1, NULL,0),
	__SENSOR_DEVICE_ATTR(alarm_temp,       0444, show_alarm_bank1, NULL,1),
	__SENSOR_DEVICE_ATTR(alarm_fan,        0444, show_alarm_bank2, NULL,0),
	__SENSOR_DEVICE_ATTR(enable_in,        0644, show_enable_in,
		store_enable_in, 0),
	__SENSOR_DEVICE_ATTR(enable_temp,      0644, show_enable_temp,
		store_enable_temp, 1),
	__SENSOR_DEVICE_ATTR(enable_fan,       0644, show_enable_fan,
		store_enable_fan, 0),
	__SENSOR_DEVICE_ATTR(enable_fan_pwm,   0644, show_enable_fan_pwm,
		store_enable_fan_pwm, 0),
	__SENSOR_DEVICE_ATTR(beep_in,          0644, show_beep_bank1,
		store_beep_bank1, 0),
	__SENSOR_DEVICE_ATTR(beep_temp,        0644, show_beep_bank1,
		store_beep_bank1, 1),
	__SENSOR_DEVICE_ATTR(beep_fan,         0644, show_beep_bank2,
		store_beep_bank2, 0),
	__SENSOR_DEVICE_ATTR(shutdown_in,      0644, show_shutdown_bank1,
		store_shutdown_bank1, 0),
	__SENSOR_DEVICE_ATTR(shutdown_temp,    0644, show_shutdown_bank1,
		store_shutdown_bank1, 1),
	__SENSOR_DEVICE_ATTR(shutdown_fan,     0644, show_shutdown_bank2,
		store_shutdown_bank2, 0)
};

/* Const names for use in the dynamicly genererated in and temp sysfs attr,
   16 is a bit over kill since there are know known mainboards with 16 in
   or temp sensors, but better safe then sorry. */
static const char * const abituguru_bank1_name[2][3*16] = { {
	"in0_input",	"in0_min",	"in0_max",
	"in1_input",	"in1_min",	"in1_max",
	"in2_input",	"in2_min",	"in2_max",
	"in3_input",	"in3_min",	"in3_max",
	"in4_input",	"in4_min",	"in4_max",
	"in5_input",	"in5_min",	"in5_max",
	"in6_input",	"in6_min",	"in6_max",
	"in7_input",	"in7_min",	"in7_max",
	"in8_input",	"in8_min",	"in8_max",
	"in9_input",	"in9_min",	"in9_max",
	"in10_input",	"in10_min",	"in10_max",
	"in11_input",	"in11_min",	"in11_max",
	"in12_input",	"in12_min",	"in12_max",
	"in13_input",	"in13_min",	"in13_max",
	"in14_input",	"in14_min",	"in14_max",
	"in15_input",	"in15_min",	"in15_max" }, {
	"temp1_input",	"temp1_max",	"temp1_max_hyst",
	"temp2_input",	"temp2_max",	"temp2_max_hyst",
	"temp3_input",	"temp3_max",	"temp3_max_hyst",
	"temp4_input",	"temp4_max",	"temp4_max_hyst",
	"temp5_input",	"temp5_max",	"temp5_max_hyst",
	"temp6_input",	"temp6_max",	"temp6_max_hyst",
	"temp7_input",	"temp7_max",	"temp7_max_hyst",
	"temp8_input",	"temp8_max",	"temp8_max_hyst",
	"temp9_input",	"temp9_max",	"temp9_max_hyst",
	"temp10_input",	"temp10_max",	"temp10_max_hyst",
	"temp11_input",	"temp11_max",	"temp11_max_hyst",
	"temp12_input",	"temp12_max",	"temp12_max_hyst",
	"temp13_input",	"temp13_max",	"temp13_max_hyst",
	"temp14_input",	"temp14_max",	"temp14_max_hyst",
	"temp15_input",	"temp15_max",	"temp15_max_hyst",
	"temp16_input",	"temp16_max",	"temp16_max_hyst" }
};

/* The driver. I choose to use type i2c_driver, as at is identical to both
   smbus_driver and isa_driver, and clients could be of either kind */
static struct i2c_driver abituguru_driver = {
	.owner		= THIS_MODULE,
	.name		= "abituguru",
	.id		= 0, /* This is optional */
	.flags		= I2C_DF_NOTIFY,
	.attach_adapter	= abituguru_detect,
	.detach_client	= abituguru_detach_client,
};

/* This is called when the module is loaded */
static int abituguru_detect(struct i2c_adapter *adapter)
{
	struct i2c_client *new_client;
	struct abituguru_data *data;
	int i,res,err = 0;
	const char client_name[] = "abituguru";
	/* El weirdo probe order, to keep the sysfs order identical to the
	   BIOS and window-appliction listing order. */
	const u8 probe_order[16] = { 0x00,0x01,0x03,0x04,0x0A,0x08,0x0E,0x02,
		0x09,0x06,0x05,0x0B,0x0F,0x0D,0x07,0x0C };
	u8 data_val;

	/* Make sure we are probing the ISA bus!!  */
	if (!i2c_is_isa_adapter(adapter)) {
		dev_err(&adapter->dev,
		"abituguru_detect called for an I2C bus adapter?!?\n");
		err = -ENODEV;
		goto ERROR0;
	}

	/* Reserve our 2 ISA addresses */
	if (!request_region(ABIT_UGURU_BASE+ABIT_UGURU_CMD, 1,
		abituguru_driver.name)) {
		dev_err(&adapter->dev, "ISA-address %x already in use!\n",
			ABIT_UGURU_BASE + ABIT_UGURU_CMD);
		err = -EBUSY;
		goto ERROR0;
	}
	if (!request_region(ABIT_UGURU_BASE+ABIT_UGURU_DATA, 1,
		abituguru_driver.name)) {
		dev_err(&adapter->dev, "ISA-address %x already in use!\n",
			ABIT_UGURU_BASE + ABIT_UGURU_DATA);
		err = -EBUSY;
		goto ERROR1;
	}

	/* Malloc our data and initialise the static parts. */
	if (!(data = kmalloc(sizeof(struct abituguru_data), GFP_KERNEL))) {
		err = -ENOMEM;
		goto ERROR2;
	}
	memset(data, 0, sizeof(struct abituguru_data));
	new_client = &data->client;
	i2c_set_clientdata(new_client, data);
	new_client->addr = ABIT_UGURU_BASE;
	new_client->adapter = adapter;
	new_client->driver = &abituguru_driver;
	new_client->flags = 0;
	strlcpy(new_client->name, client_name, I2C_NAME_SIZE);
	init_MUTEX(&data->update_lock);

	/* See if there is an uguru there. After a reboot uGuru will hold 0x00
	   at DATA and 0xAC at CMD. When this driver has already been loaded
	   once DATA will hold 0x08 that's why we need to test both. */
	data_val = inb_p(ABIT_UGURU_BASE + ABIT_UGURU_DATA);
	if ( ((data_val = 0x00) || (data_val = 0x08)) &&
	     (inb_p(ABIT_UGURU_BASE + ABIT_UGURU_CMD) = 0xAC)) {
	     	/* Probably found uGuru, see if its ready */
		if (data_val = ABIT_UGURU_STATUS_INPUT)
			data->uguru_ready = 1;
	} else if (force) {
		/* User forced goahead, see if it the uGuru is in waiting
		   for input state, and ifso force a read to make sure it
		   is ready for the ready cycle */
		printk(KERN_WARNING "No Abit uGuru found, asuming one is present because of \"force\" parameter\n");
		if (data_val = ABIT_UGURU_STATUS_INPUT) {
			u8 dummy;
			data->uguru_ready = 1;
			abituguru_read(new_client, ABIT_UGURU_SENSOR_BANK2,
				0, &dummy, 1);
		}
	} else {
		/* No uGuru found */
		err = -ENODEV;
		goto ERROR3;
	}
	
	/* Do a test read of the uGuru to see if one really is there,
	   note that this won't read bank1 since we didn't detect
	   the bank1 sensors yet. */
	abituguru_update_device(&new_client->dev);
	if (!data->valid) {
		err = -ENODEV;
		goto ERROR3;
	}
	up(&data->update_lock);
	data->valid = 0;

	/* Tell the I2C layer a new client has arrived */
	if ((err = i2c_attach_client(new_client)))
		goto ERROR3;

	/* Register sysfs hooks */
	data->class_dev = hwmon_device_register(&new_client->dev);
	if (IS_ERR(data->class_dev)) {
		err = PTR_ERR(data->class_dev);
		goto ERROR4;
	}
	/* Detect sensor types and register the sysfs hooks for bank1 */
	for (i=0; i<16; i++) {
		data->bank1_attr[i*3   ].dev_attr.attr.mode  = 0444;
		data->bank1_attr[i*3   ].dev_attr.attr.owner = THIS_MODULE;
		data->bank1_attr[i*3   ].dev_attr.show  = show_bank1_reg;
		data->bank1_attr[i*3   ].dev_attr.store = NULL;
		data->bank1_attr[i*3   ].index = probe_order[i]*4 + 3;
		data->bank1_attr[i*3 +1].dev_attr.attr.mode  = 0644;
		data->bank1_attr[i*3 +1].dev_attr.attr.owner = THIS_MODULE;
		data->bank1_attr[i*3 +1].dev_attr.show  = show_bank1_reg;
		data->bank1_attr[i*3 +1].dev_attr.store = store_bank1_reg;
		data->bank1_attr[i*3 +1].index = probe_order[i]*4 + 1;
		data->bank1_attr[i*3 +2].dev_attr.attr.mode  = 0644;
		data->bank1_attr[i*3 +2].dev_attr.attr.owner = THIS_MODULE;
		data->bank1_attr[i*3 +2].dev_attr.show  = show_bank1_reg;
		data->bank1_attr[i*3 +2].dev_attr.store = store_bank1_reg;
		data->bank1_attr[i*3 +2].index = probe_order[i]*4 + 2;
		
		res = abituguru_detect_sensor_type(new_client, probe_order[i]);
		if (res < 0) {
			printk(KERN_WARNING "Couldnot determine sensor type for sensorbank1 sensor %d, skipping sensor\n", i);
			continue;
		}
		
		if (res != ABIT_UGURU_NC) {
			data->bank1_attr[i*3   ].dev_attr.attr.name 				abituguru_bank1_name[res][
					data->bank1_sensors[res]*3   ];
			data->bank1_attr[i*3 +1].dev_attr.attr.name 				abituguru_bank1_name[res][
					data->bank1_sensors[res]*3 +1];
			data->bank1_attr[i*3 +2].dev_attr.attr.name 				abituguru_bank1_name[res][
					data->bank1_sensors[res]*3 +2];
			data->bank1_address[res][data->bank1_sensors[res]] 				probe_order[i];
			data->bank1_sensors[res]++;

			device_create_file(&new_client->dev,
				&data->bank1_attr[i*3   ].dev_attr);
			device_create_file(&new_client->dev,
				&data->bank1_attr[i*3 +1].dev_attr);
			device_create_file(&new_client->dev,
				&data->bank1_attr[i*3 +2].dev_attr);
		}
	}
	/* Fan and misc hooks */
	for (i=0; i<40; i++)
		device_create_file(&new_client->dev,
			&abituguru_sysfs_attr[i].dev_attr);

	return 0;

ERROR4:
	if (i2c_detach_client(new_client))
		dev_err(&new_client->dev,
		"Client deregistration failed, client not detached.\n");
ERROR3:
	kfree(data);
ERROR2:
	release_region(ABIT_UGURU_BASE + ABIT_UGURU_DATA, 1);
ERROR1:
	release_region(ABIT_UGURU_BASE + ABIT_UGURU_CMD, 1);
ERROR0:
	return err;
}

static int abituguru_detach_client(struct i2c_client *client)
{
	int err;
	struct abituguru_data *data = i2c_get_clientdata(client);

	hwmon_device_unregister(data->class_dev);

	if ((err = i2c_detach_client(client))) {
		dev_err(&client->dev,
		"Client deregistration failed, client not detached.\n");
		return err;
	}

	release_region(client->addr + ABIT_UGURU_DATA, 1);
	release_region(client->addr + ABIT_UGURU_CMD, 1);
	kfree(data);

	return 0;
}

/* Danger Will Robinson, danger! This function downs the update_lock semaphore
   in the abituguru_data struct but doesn't up it, the caller must up
   it when it is done with the returned data! */
static struct abituguru_data *abituguru_update_device(struct device *dev)
{
	struct i2c_client *client = to_i2c_client(dev);
	struct abituguru_data *data = i2c_get_clientdata(client);
	int i;

	down(&data->update_lock);

	if (time_after(jiffies, data->last_updated + HZ + HZ / 2)
	    || !data->valid) {
	    	data->valid = 0;
		if (abituguru_read(client, ABIT_UGURU_ALARM_BANK, 0,
			data->alarm_regs, 3) != 3)
			return data;
		for (i = 0; i < 16; i++) {
			if (abituguru_read(client, ABIT_UGURU_SENSOR_BANK1,
				i, &data->bank1_regs[i*4+3], 1) != 1)
				return data;
			if (abituguru_read(client, ABIT_UGURU_SENSOR_BANK1+1,
				i, &data->bank1_regs[i*4], 3) != 3)
				return data;
		}
		for (i = 0; i < 3; i++) {
			if (abituguru_read(client, ABIT_UGURU_FAN_PWM,
				i, &data->fan_pwm_regs[i*5], 5) != 5)
				return data;
		}
		for (i = 0; i < 6; i++) {
			if (abituguru_read(client, ABIT_UGURU_SENSOR_BANK2,
				i, &data->bank2_regs[i*3+2], 1) != 1)
				return data;
			if (abituguru_read(client, ABIT_UGURU_SENSOR_BANK2+1,
				i, &data->bank2_regs[i*3], 2) != 2)
				return data;
		}
		data->last_updated = jiffies;
	    	data->valid = 1;
	}
	return data;
}

static int __init sm_abituguru_init(void)
{
	return i2c_isa_add_driver(&abituguru_driver);
}

static void __exit sm_abituguru_exit(void)
{
	i2c_isa_del_driver(&abituguru_driver);
}

MODULE_AUTHOR("Hans de Goede <j.w.r.degoede@hhs.nl>");
MODULE_DESCRIPTION("Abit uGuru Sensor device");
MODULE_LICENSE("GPL");

module_init(sm_abituguru_init);
module_exit(sm_abituguru_exit);
-------------- next part --------------
obj-m += abituguru.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Grant Coady]

Hans de Goede wrote:
> 
> Jean Delvare wrote:
> 
>>-ENOPATCH
> 
> Yes, its a new driver, so nothing to diff against, would a diff against 
> /dev/null really make you happier?

diff -Nrup (or -Naur) is your friend, you going to offer at least two files,
the driver, and the documentation file for that driver?

> Can someone please take a look at the driver and give me some proper 
> feedback?

As soon you send a patch :o)

Grant.

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Matt Stamp]

I am getting an error when trying to insert module and it will not force.

I get.

insmod abituguru.ko
insmod: error inserting 'abituguru.ko' : -1 Unknown symbol in module

I am using debian unstable with kernel 2.6.13.4.

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Hans de Goede]

Matt Stamp wrote:
> I am getting an error when trying to insert module and it will not force.
> 
> I get.
> 
> insmod abituguru.ko
> insmod: error inserting 'abituguru.ko' : -1 Unknown symbol in module
> 
> I am using debian unstable with kernel 2.6.13.4.
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 

Yes, my mistake (in the docs), you should use kernel 2.6.14rc4 or newer 
2.6.13 is not new enough.

Regards,

Hans

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Mark M. Hoffman]

Hi Hans:

* Hans de Goede <j.w.r.degoede@hhs.nl> [2005-10-21 11:19:13 +0200]:
> As promised some time ago here is a new version of the Abit uGuru 
> driver, this version fully supports the sensor part of the uGuru, that 
> means it supports the following:
> 
> -reading all sensors
> -reading and writing min/max settings for all sensors
> -reading/writing settings for all sensors (enable alarm, beep, shutdown)
> -reading alarms
> -configuring the fan speed control (quiet fan or whatever buzzword)
> 
> I would like to submit the libsensors part here and the driver upstream, 
> so please review.

BTW: "driver upstream" = this same mailing list.

> Thanks,
> 
> Hans
> 
> 
> For some more info I've also written a small readme, see Attachment.

For starters, you should add this readme as a new file in doc/chips in
your lm_sensors2 patch.  Try to use a similar format as the documentation
already there.

> Abit Uguru driver README.
> ============[...]

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Mark M. Hoffman]

Hi Hans:

* Hans de Goede <j.w.r.degoede@hhs.nl> [2005-10-21 11:21:22 +0200]:
> The libsensors patch, I still need to add alarm support. I understand 
> that is sorta hard todo for 2.6 only drivers, can someone give my any hints?

I didn't get very far into the review...

> --- lm_sensors2/etc/sensors.conf.eg.uguru	2005-10-17 14:16:54.000000000 +0200
> +++ lm_sensors2/etc/sensors.conf.eg	2005-10-17 14:16:54.000000000 +0200
> @@ -2371,3 +2371,110 @@
>     set temp2_over  45
>     set temp2_hyst  40
>  
> +
> +# Abit Uguru sensor part configuration.
> +# The Abit Uguru is relativly straight forward to configure.
> +# label statements:
> +# All the voltage (in) temp and fan sensors should be in the same order
> +# as listed in the BIOS.
> +# compute statements:
> +# The temp and fan sensors don't need any compute statements. The voltage
> +# sensors are given in raw registervalues by the kernel driver since the
> +# way they are hooked up differs from one motherboard to another. The voltage
> +# sensors give values of 0-255 which are linear mapped to one of the following:
> +# 0-3.49v, 0-4.26v, 0-6.25 volt or 0-14.51 volt. Abit's windows software uses
> +# the following mutipliers for this: 0.0137, 0.0171, 0.0245 and 0.0569.
> +# Most voltages will fall in the 0-3.49v range and thus use the 0.0137
> +# multiplier. 3.3 volt sources use the 0.0171 mutiplier, 5 volt the 0.0245 and
> +# 12 volt the 0.0569.

No.  This is not how we do analog inputs.  Notice that no other driver in
lm_sensors2 or in kernel 2.6 does this.

The value that is visible outside the driver (in sysfs) is the voltage AT
THE PIN OF THE HARDWARE.  Now I'll grant you that for a reverse-engineered
driver, it's difficult if not impossible to be sure what this really is.
If you're handy with hardware and patient, you could probe the pins of
the thing w/ a voltmeter and try to gather some clues.

Otherwise you can guess by two different methods...

(1) Does uGuru look a whole lot like some other documented chip?  If so,
guess that it has the same full-scale voltage at each input as the known
chip and write the driver that way.  E.g. asb100 is similar to w83781d.

(2) Use Abit's multipliers and just scale the voltages in the driver.
It's almost certainly not acurate w.r.t. voltage at the pin of the
hardware... but since they're not releasing a datasheet that's less
important anyway.

But certainly, having a kernel driver output 0-255 for a voltage input is
a huge and unacceptable step backwards.  Please fix that first and then
we can talk about the rest.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Hans de Goede]

Mark M. Hoffman wrote:
> Hi Hans:
> 
> * Hans de Goede <j.w.r.degoede@hhs.nl> [2005-10-21 11:21:22 +0200]:
> 
>>The libsensors patch, I still need to add alarm support. I understand 
>>that is sorta hard todo for 2.6 only drivers, can someone give my any hints?
> 
> 
> I didn't get very far into the review...
> 
> 
>>--- lm_sensors2/etc/sensors.conf.eg.uguru	2005-10-17 14:16:54.000000000 +0200
>>+++ lm_sensors2/etc/sensors.conf.eg	2005-10-17 14:16:54.000000000 +0200
>>@@ -2371,3 +2371,110 @@
>>    set temp2_over  45
>>    set temp2_hyst  40
>> 
>>+
>>+# Abit Uguru sensor part configuration.
>>+# The Abit Uguru is relativly straight forward to configure.
>>+# label statements:
>>+# All the voltage (in) temp and fan sensors should be in the same order
>>+# as listed in the BIOS.
>>+# compute statements:
>>+# The temp and fan sensors don't need any compute statements. The voltage
>>+# sensors are given in raw registervalues by the kernel driver since the
>>+# way they are hooked up differs from one motherboard to another. The voltage
>>+# sensors give values of 0-255 which are linear mapped to one of the following:
>>+# 0-3.49v, 0-4.26v, 0-6.25 volt or 0-14.51 volt. Abit's windows software uses
>>+# the following mutipliers for this: 0.0137, 0.0171, 0.0245 and 0.0569.
>>+# Most voltages will fall in the 0-3.49v range and thus use the 0.0137
>>+# multiplier. 3.3 volt sources use the 0.0171 mutiplier, 5 volt the 0.0245 and
>>+# 12 volt the 0.0569.
> 
> 
> No.  This is not how we do analog inputs.  Notice that no other driver in
> lm_sensors2 or in kernel 2.6 does this.
> 
> The value that is visible outside the driver (in sysfs) is the voltage AT
> THE PIN OF THE HARDWARE.  Now I'll grant you that for a reverse-engineered
> driver, it's difficult if not impossible to be sure what this really is.
> If you're handy with hardware and patient, you could probe the pins of
> the thing w/ a voltmeter and try to gather some clues.
> 
> Otherwise you can guess by two different methods...
> 
> (1) Does uGuru look a whole lot like some other documented chip?  If so,
> guess that it has the same full-scale voltage at each input as the known
> chip and write the driver that way.  E.g. asb100 is similar to w83781d.
> 
> (2) Use Abit's multipliers and just scale the voltages in the driver.
> It's almost certainly not acurate w.r.t. voltage at the pin of the
> hardware... but since they're not releasing a datasheet that's less
> important anyway.
> 
> But certainly, having a kernel driver output 0-255 for a voltage input is
> a huge and unacceptable step backwards.  Please fix that first and then
> we can talk about the rest.
> 

In my first incarnation of the driver I did scale the output with the 
Abit multipliers before reporting them to userspace. The problem is 
however that the uGuru is on a number of different mainboards and the 
multipliers for say in5 differ from mainboard to mainboard, afaik that 
is exactly what sensors.conf is there to handle. To quote from:
lm_sensors2/doc/developers/new_drivers

* A quick note about conversions. The conversions which are specified
   in the sensor chip datasheet and which *cannot* vary from one board to
   the next are performed by the driver. If other conversions are
   necessary, they are performed in user-space.

So I'm not doing any conversion since this differs from one board to the 
next. The 4 multipliers as given in sensors.conf are otherwise 100% 
correct (iow they are not guessed, they are exactly the same multipliers 
as Abit's software uses), the problem is that the driver has no (known) 
way to find out which of the 4 multipliers to use for which analog input.

About the README, that is currently mean't for people who are testing 
the driver for me, hence the "install" part which of course has to go 
when the driver is in tree, I'll convert it to look like the other chips 
docs.

Thanks for your time & Regards,

Hans

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Rudolf Marek]

Hello Hans,

>> But certainly, having a kernel driver output 0-255 for a voltage input is
>> a huge and unacceptable step backwards.  Please fix that first and then
>> we can talk about the rest.
I agree completely.

But I have a proposal to solution.

All we just need to know is the how many volts are used for one bit.
http://www.winbond.com/e-winbondhtm/partner/PDFresult.asp?Pname’6

Some suggestions are here around page 64.

And some information are here:

+ label in0 "CPUcore"
+   compute in0 @*0.0137 , @/0.0137
+   label in1 "DDRVdd"
+   compute in1 @*0.0137 , @/0.0137
+   label in7 "Vdd5V"
+   compute in7 @*0.0245 , @/0.0245

VCore is often unscaled so this *0.0137 gives for 8bit =>  3.4935Vref so 3.5V

Rest is simple: just compute the correct divisors for each in0
0.0245/0.0137 is round 2 so 5V might be scaled by 2. I dont know how those values were obtained so I cant do more speculations.

Best would be if could measure actual voltage on pin P3REF so pin50 of the chip. Also there is another Vref at pin 72 the datasheet
is unclear what pin is used when. If you are measuring please measure actual chip VCC too. (This should be 5V)

How to measure:

Multimeter 0-5V DC
one wire to selected pin, second wire try the black wire of 4 hole power connector. Try not to shortcut the pins around.
You can take a needle and glue it with the tape to multimeter probe.

Thanks

Regards
Rudolf

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Jean Delvare]

Hi Mark, Hans,

> For starters, you should add this readme as a new file in doc/chips in
> your lm_sensors2 patch.  Try to use a similar format as the documentation
> already there.

As this is a Linux 2.6 driver, the correct place would rather be
Documentation/hwmon in the Linux tree.

Thanks,
-- 
Jean Delvare

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Rudolf Marek]

Hans,

Contact Ollebull (That person you was working on uGuru) and ask him about the docs.
He wrote some, which is quite OK, but it needs to be updated.

Thanks
regards
Rudolf

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Matthew Stamp]

Hans,
 Since my last email I have upgraded to 2.6.14 and got all the nessasary
modules in place. Although I have nothing in my /sys/bus/i2c/devices. I do
have abituguru and i2c_adapter in the drivers section. I was talking with
ollie long ago about this also. It seems his program openguru doesn't work
on my board either, I have a AN7 bios v.19. Yes I know it is been proven to
work with this board but for some reason it does not with mine. When I use
the openguru program it just simply states that uguru was not found.

 Debian Sid 2.6.14
 desktop:/home/tfmegatron# lsmod

Module Size Used by

ipt_limit 1920 11

ipt_LOG 6080 3

ipt_state 1408 4

ip_conntrack 42576 1 ipt_state

iptable_filter 2176 1

ip_tables 20480 4 ipt_limit,ipt_LOG,ipt_state,iptable_filter

emu10k1_gp 2688 0

gameport 11848 2 emu10k1_gp

snd_emu10k1_synth 6720 0

snd_emux_synth 36544 1 snd_emu10k1_synth

snd_seq_virmidi 6080 1 snd_emux_synth

snd_seq_midi_emul 6528 1 snd_emux_synth

snd_seq_dummy 2628 0

snd_seq_oss 33344 0

snd_seq_midi 6944 0

snd_seq_midi_event 6272 3 snd_seq_virmidi,snd_seq_oss,snd_seq_midi

snd_seq 51344 9
snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event

snd_emu10k1 120036 1 snd_emu10k1_synth

snd_rawmidi 21600 3 snd_seq_virmidi,snd_seq_midi,snd_emu10k1

snd_seq_device 6988 8
snd_emu10k1_synth,snd_emux_synth,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq,snd_emu10k1,snd_rawmidi

snd_ac97_codec 93884 1 snd_emu10k1

snd_pcm_oss 50208 0

snd_mixer_oss 17536 1 snd_pcm_oss

snd_pcm 85000 3 snd_emu10k1,snd_ac97_codec,snd_pcm_oss

snd_timer 22340 3 snd_seq,snd_emu10k1,snd_pcm

snd_ac97_bus 1792 1 snd_ac97_codec

snd_page_alloc 8456 2 snd_emu10k1,snd_pcm

snd_util_mem 3328 2 snd_emux_synth,snd_emu10k1

snd_hwdep 7328 2 snd_emux_synth,snd_emu10k1

snd 47012 13
snd_emux_synth,snd_seq_virmidi,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep

soundcore 7904 1 snd

ohci1394 33012 0

ieee1394 90164 1 ohci1394

nvidia 3904188 12

lp 9412 0

parport_pc 26116 1

parport 34888 2 lp,parport_pc

Anything else you might want to look at just ask. Thanks for your time.
 matt
 On 10/27/05, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
>
>
>
> Matt Stamp wrote:
> > I am getting an error when trying to insert module and it will not
> force.
> >
> > I get.
> >
> > insmod abituguru.ko
> > insmod: error inserting 'abituguru.ko' : -1 Unknown symbol in module
> >
> > I am using debian unstable with kernel 2.6.13.4 <http://2.6.13.4>.
> > _______________________________________________
> > lm-sensors mailing list
> > lm-sensors@lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> >
>
> Yes, my mistake (in the docs), you should use kernel 2.6.14rc4 or newer
> 2.6.13 is not new enough.
>
> Regards,
>
> Hans
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Hans de Goede]

Matthew Stamp wrote:
> Hans,
>  
> Since my last email I have upgraded to 2.6.14 and got all the nessasary 
> modules in place.  Although I have nothing in my /sys/bus/i2c/devices.  
> I do have abituguru and i2c_adapter in the drivers section.  I was 
> talking with ollie long ago about this also.  It seems his program 
> openguru doesn't work on my board either,  I have a AN7 bios v.19.  Yes 
> I know it is been proven to work with this board but for some reason it 
> does not with mine.  When I use the openguru program it just simply 
> states that uguru was not found. 
> 
>  

Could you rmmod the driver and insmod it as follows:
insmod <path>/abituguru.ko force=1

That should skip the early part of the detection phase, instead it will 
just assume the uguru is there and do a testread, if the testread 
however fails then it will still not register (show up under 
/sys/bus/i2c/devices).

If the testread fails we do btw have a real problem, but lets take this 
one step at a time. Have you ever had this working under windows? and do 
the bios readings seem sane, there is a small chance you've just got a 
busted uGuru.

Regards,

Hans

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Matthew Stamp]

Hans,
 I will get back with you on the force=1 bit. But about the question with
winxp. Everything works fine. Abit's uguru program reads the sensors
correctly.

 On 10/29/05, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
>
>
>
> Matthew Stamp wrote:
> > Hans,
> >
> > Since my last email I have upgraded to 2.6.14 and got all the nessasary
> > modules in place. Although I have nothing in my /sys/bus/i2c/devices.
> > I do have abituguru and i2c_adapter in the drivers section. I was
> > talking with ollie long ago about this also. It seems his program
> > openguru doesn't work on my board either, I have a AN7 bios v.19. Yes
> > I know it is been proven to work with this board but for some reason it
> > does not with mine. When I use the openguru program it just simply
> > states that uguru was not found.
> >
> >
>
> Could you rmmod the driver and insmod it as follows:
> insmod <path>/abituguru.ko force=1
>
> That should skip the early part of the detection phase, instead it will
> just assume the uguru is there and do a testread, if the testread
> however fails then it will still not register (show up under
> /sys/bus/i2c/devices).
>
> If the testread fails we do btw have a real problem, but lets take this
> one step at a time. Have you ever had this working under windows? and do
> the bios readings seem sane, there is a small chance you've just got a
> busted uGuru.
>
> Regards,
>
> Hans
>

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Hans de Goede]

Rudolf Marek wrote:
> Hello Hans,
> 
> 
>>>But certainly, having a kernel driver output 0-255 for a voltage input is
>>>a huge and unacceptable step backwards.  Please fix that first and then
>>>we can talk about the rest.
> 
> I agree completely.
> 
> But I have a proposal to solution.
> 
> All we just need to know is the how many volts are used for one bit.
> http://www.winbond.com/e-winbondhtm/partner/PDFresult.asp?Pname’6
> 
> Some suggestions are here around page 64.
> 
> And some information are here:
> 
> + label in0 "CPUcore"
> +   compute in0 @*0.0137 , @/0.0137
> +   label in1 "DDRVdd"
> +   compute in1 @*0.0137 , @/0.0137
> +   label in7 "Vdd5V"
> +   compute in7 @*0.0245 , @/0.0245
> 
> VCore is often unscaled so this *0.0137 gives for 8bit =>  3.4935Vref so 3.5V
> 
> Rest is simple: just compute the correct divisors for each in0
> 0.0245/0.0137 is round 2 so 5V might be scaled by 2. I dont know how those values were obtained so I cant do more speculations.
> 
> Best would be if could measure actual voltage on pin P3REF so pin50 of the chip. Also there is another Vref at pin 72 the datasheet
> is unclear what pin is used when. If you are measuring please measure actual chip VCC too. (This should be 5V)
> 
> How to measure:
> 
> Multimeter 0-5V DC
> one wire to selected pin, second wire try the black wire of 4 hole power connector. Try not to shortcut the pins around.
> You can take a needle and glue it with the tape to multimeter probe.
> 

For the record, I'm a teacher in electrical engineering and computer 
science at a Dutch university.

At first I had the same tought process as you and I too thought that the 
uGuru is most likely hooked up to a 3.5v voltage reference. But there 
are a number of reasons why I'm not so sure:

The W83L950D has only 8 analog inputs, but the uGuru has 16. So somehow 
Abit is doing some trickery to get more analog inputs, they could be 
using the 8 comparator inputs, with one of the DA outputs hooked up to 
the comparator reference pin, and using SAR to build another 8 AD inputs
out of this.

BTW pin P3REF is the comparator reference not the AD/DA reference. the 
VREF pin (72) is the AD/DA reference. Also P3REF is pin 58, not 50.

They could however also be using one or more external sensor IC's hooked 
up to one of the 2 i2c/smbus controllers which are onboard the W83L950D. 
In this case the reference voltage hooked up to the W83L950D is 
irrelevant (or atleast irrelevant for some of the inputs).

Also if I we're to design the sensor part of a mainboard I would want to 
have a cheap reference voltage with a low temperature drift, thus I 
would use an of the shelf component. These however do not come in a 3.5 
volt variant, atleast not from the worldst 2 biggest reference voltage 
IC suppliers, see:
http://para.maxim-ic.com/compare.asp?Fam=Volt_Ref&Tree=References&HP=References.cfm&lnhttp://www.analog.com/en/subCat/0,2879,769%255F838%255F0%255F%255F0%255F,00.html

So a reference voltage of 3.5 volt is not likely, assuming that Abit 
doesn't want to build a descrete reference voltage source themselves, or 
use an expensive programmable one. Also note that a simple zenerdiode 
setup will not suffice since its temperature drift is to high, (at least 
higher then what I've seen with my mb sofar).

Also you assume that the other mutipliers used are based on round 
dividers of the input voltage, but if that where the case then the 
0-6.25 volt would be 0-7 volt which is a rather big error.

Last, the uGuru is a microcontroller and could do some scaling itself. I 
know this is the case for temperature sensors, since the register value 
equals the temperature in degrees celcius here, so most likely the uGuru 
has already done conversion here.

So in short, we don't even now which inputs if any are used, and we 
don't know what kindoff conversions if any are already done by the 
uGuru. And since I'm not planning on reverse engineering the layout of a 
6 layer print we will probably never know.

The current uGuru driver is based on software reverse-engineering, not 
hardware reverse-engineering. One of the reasons for this is that the 
hardware used is programmable, so we will probably never know what is 
going on inside. Another reason is that its a lot easier and safer.

I can however modify the driver to always scale all analog inputs to 
0-3.5 volts and modify sensors.conf accordingly if that makes you happier.

Regards,

Hans

[lm-sensors] New Abit uGuru driver + libsensors patch,

[Matthew Stamp]

Hans,
 I have used the force=1 bit and it seems to work. I do however get a beep
from my system speaker and this stated in dmesg.
 No Abit uGuru found, asuming one is present because of "force" parameter
Could not determine sensor type for sensorbank1 sensor 15, skipping sensor
 Also I patched lm-sensors and in ksensors I correctly displays my cputemp.
But Every 10 seconds give or take it will drop to 0, then -1 for a few
seconds then come back up to 32c.
 Other than that I am happy to finally be able to read these sensors. I have
waited for this for years. Thank you.
 matt

 On 10/29/05, Matthew Stamp <mstamp@gmail.com> wrote:
>
> Hans,
>  I will get back with you on the force=1 bit. But about the question with
> winxp. Everything works fine. Abit's uguru program reads the sensors
> correctly.
>
>  On 10/29/05, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> >
> >
> >
> > Matthew Stamp wrote:
> > > Hans,
> > >
> > > Since my last email I have upgraded to 2.6.14 and got all the
> > nessasary
> > > modules in place. Although I have nothing in my /sys/bus/i2c/devices.
> > > I do have abituguru and i2c_adapter in the drivers section. I was
> > > talking with ollie long ago about this also. It seems his program
> > > openguru doesn't work on my board either, I have a AN7 bios v.19. Yes
> > > I know it is been proven to work with this board but for some reason
> > it
> > > does not with mine. When I use the openguru program it just simply
> > > states that uguru was not found.
> > >
> > >
> >
> > Could you rmmod the driver and insmod it as follows:
> > insmod <path>/abituguru.ko force=1
> >
> > That should skip the early part of the detection phase, instead it will
> > just assume the uguru is there and do a testread, if the testread
> > however fails then it will still not register (show up under
> > /sys/bus/i2c/devices).
> >
> > If the testread fails we do btw have a real problem, but lets take this
> > one step at a time. Have you ever had this working under windows? and do
> > the bios readings seem sane, there is a small chance you've just got a
> > busted uGuru.
> >
> > Regards,
> >
> > Hans
> >
>
>

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Rudolf Marek]

> For the record, I'm a teacher in electrical engineering and computer
> science at a Dutch university.

Cool. Wee need such persons to help us exactly with ADC problems ;)

> 
> At first I had the same tought process as you and I too thought that the
> uGuru is most likely hooked up to a 3.5v voltage reference. But there
> are a number of reasons why I'm not so sure:
> 
> The W83L950D has only 8 analog inputs, but the uGuru has 16. So somehow
> Abit is doing some trickery to get more analog inputs, they could be
> using the 8 comparator inputs, with one of the DA outputs hooked up to
> the comparator reference pin, and using SAR to build another 8 AD inputs
> out of this.

Hmm quite clever.

> BTW pin P3REF is the comparator reference not the AD/DA reference. the
> VREF pin (72) is the AD/DA reference. Also P3REF is pin 58, not 50.

Aha ok

> They could however also be using one or more external sensor IC's hooked
> up to one of the 2 i2c/smbus controllers which are onboard the W83L950D.
> In this case the reference voltage hooked up to the W83L950D is
> irrelevant (or atleast irrelevant for some of the inputs).
> 
> Also if I we're to design the sensor part of a mainboard I would want to
> have a cheap reference voltage with a low temperature drift, thus I
> would use an of the shelf component. These however do not come in a 3.5
> volt variant, atleast not from the worldst 2 biggest reference voltage
> IC suppliers, see:
> http://para.maxim-ic.com/compare.asp?Fam=Volt_Ref&Tree=References&HP=References.cfm&ln> 
> http://www.analog.com/en/subCat/0,2879,769%255F838%255F0%255F%255F0%255F,00.html
> 
> 
> So a reference voltage of 3.5 volt is not likely, assuming that Abit
> doesn't want to build a descrete reference voltage source themselves, or
> use an expensive programmable one. Also note that a simple zenerdiode
> setup will not suffice since its temperature drift is to high, (at least
> higher then what I've seen with my mb sofar).

Thank you for your analysis. However chip makers do create custom IO devices or custom modifications for MB manufacturers (big customers?)

> Also you assume that the other mutipliers used are based on round
> dividers of the input voltage, but if that where the case then the
> 0-6.25 volt would be 0-7 volt which is a rather big error.
> 
> Last, the uGuru is a microcontroller and could do some scaling itself. I
> know this is the case for temperature sensors, since the register value
> equals the temperature in degrees celcius here, so most likely the uGuru
> has already done conversion here.

Yes true.

> So in short, we don't even now which inputs if any are used, and we
> don't know what kindoff conversions if any are already done by the
> uGuru. And since I'm not planning on reverse engineering the layout of a
> 6 layer print we will probably never know.

I was wondering to read the uGUru program out of it. It seems it can be possible. And then read the x51 assembly.

> The current uGuru driver is based on software reverse-engineering, not
> hardware reverse-engineering. One of the reasons for this is that the
> hardware used is programmable, so we will probably never know what is
> going on inside. Another reason is that its a lot easier and safer.

Agree

> I can however modify the driver to always scale all analog inputs to
> 0-3.5 volts and modify sensors.conf accordingly if that makes you happier.

This is not what makes us happy. We simply need SAME interface for every possible chip that provides voltages. We dont
want any "if uguru" in software libraries.

Please convert it so it gives out some values in mV as interface request it.

Thanks,

Regards
Rudolf

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Rudolf Marek]

> 
> That is most likely the case with the uGuru (I know I would have read
> protected it). We could try to get the code out of a firmware update,
> but there don't seem to be any firmware updates, the bios updates use a
> standard awardflash program which (AFAIK) is not aware of the uGuru chip
> and the size of the bios updates also is a power of 2, which makes it
> unlikely that they also contain firmware for the uGuru.

I think this can be part of BIOS image. I can try to expand the image and examine the files inside
do you know any "classical" byte sequence of microchip 051 opcodes?

I looked to the winbond datasheet and it seems they provide a way to read the flash.
I did not check if this can be disabled on the other hand...

>> This is not what makes us happy. We simply need SAME interface for
>> every possible chip that provides voltages. We dont
>> want any "if uguru" in software libraries.

> 
> I guess that didn't come out as I intended it, sorry. I agree that the
> interface exported to userspace should be identical for all sensors. I
> was / am actually surprised by the chips.c stuff in lib-sensors  +
> sensors-app, I had expected all the chip specifics to be either in the
> kernel driver or sensors.conf.

I agree that the library is ungly, there is a plan to replace it with better one and that is the reason we
need well defined interface.

> I'll modify the driver to scale all register values to 0-3.5V this is
> correct for most inputs, the other non standard inputs will have to be
> handled in sensors.conf.

OK thanks

Regards
Rudolf

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Hans de Goede]

Rudolf Marek wrote:
>>That is most likely the case with the uGuru (I know I would have read
>>protected it). We could try to get the code out of a firmware update,
>>but there don't seem to be any firmware updates, the bios updates use a
>>standard awardflash program which (AFAIK) is not aware of the uGuru chip
>>and the size of the bios updates also is a power of 2, which makes it
>>unlikely that they also contain firmware for the uGuru.
> 
> 
> I think this can be part of BIOS image. I can try to expand the image and examine the files inside
> do you know any "classical" byte sequence of microchip 051 opcodes?
> 
> I looked to the winbond datasheet and it seems they provide a way to read the flash.
> I did not check if this can be disabled on the other hand...
> 

I didn't check either but I really don't know any microcontrollers for 
which the external reading of flash cannot be disabled, since most 
people like to keep there software propietary it is kinda hard to sell 
microcontrollers which can always be read externally. Also even if it is 
not read protectected you still need access to certain pins, which 
usually have more then 1 use, AFAIK these pins have not been connected 
to a header on the motherboard, so getting to them will be hard.

I find it unlikely that the bios holds the firmware it could be that the 
bios checks the firmware version of the uGuru and updates it if 
nescesarry, although that is rather tricky flashing a microcontroller 
take atleast 10-15 seconds, and a user could loose its patience and hit 
the reset switch. Even more problematic: during the reprogramming the 
microcontroller including pwm outputs etc stops running, since the uGuru 
controls cpu and ram voltages stopping it would be a BAD idea.

I really think that the uguru gets programmed once and is not meant to 
be updated through software, which also means that the ISP (in system 
programming) pins could have been reused for another purpose.

Although it is a nobel cause to try and get your hands on the firmware I 
don't think it is worth the trouble. My current driver supports the 
sensors part of the uGuru quite well. Although it would be nice to know 
how the uGuru really works instead of just using the magical multipliers 
for the register values the windows software use, using these 
multipliers actually works quite well.

Also by using Abit's algorithm's and not creating our own based on 
hardware specs, we get the exact same readings as the BIOS and window 
apps, giving the end user a nice fuzzy warm feeling that everything 
makes sense.

I know that there is a dislike among the lm_sensors developers against 
not having the exact hardware specs but in practice, we never have. Even 
if we have the sensorschip datasheets we still don't know how the 
motherboard manufacturer has hooked the sensorchip up.

Actually I have used lm_sensors for a long time and my current uGuru 
driver gives the most believable readings of all my setups all my 
previous (asus) motherboards always had a couple of readings which were 
significantly different from the BIOS, and those from the BIOS where 
more realistic imho.

I guess that we just have to accept that there will always be some guess 
work in lm_sensors, untill motherboard manufacturers start giving away 
full specs including schematics. Actually with things like using the 
asus acpi interface to sensors the blackbox factor is only going to get 
worse not better. But things will get better for the end user.

I'm a big believer of opensource and openness in general for both soft- 
and hardware (where are the good old days your radio/tv would come with 
full schematics?) but in the end I'm also pragmatic and when I have to 
choose between a blackbox approach to support XXX or bad/no support at 
all I choose for a blackbox approach*

Regards,

Hans

* going offtopic: One of the reasons for me to choose for a blackbox 
approach if nescesarry is because I want Linux or more general 
open-engineering to succeed, I really wish everything would be fully 
open. But untill that day we need todo what we can to support as much 
hardware as possible, so that people will be able to switch to an 
opensource OS, whatever their hardware. Once opensource has a 
significant place in the marketplace hopefully hardware will become more 
open too.

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Jean Delvare]

Hi Hans,

> I know that there is a dislike among the lm_sensors developers against 
> not having the exact hardware specs but in practice, we never have. Even 
> if we have the sensorschip datasheets we still don't know how the 
> motherboard manufacturer has hooked the sensorchip up.

Sometimes we do. I am currently writing a driver for the Fintek F71805F
Super-I/O hardware monitoring features. I have the full specifications
of the chip itself, and I also have the wiring schematics of the Jetway
K8M8MS motherboard it sits on, generously provided by Jetway. I had a
working configuration file in no time, and writing the driver was a
pleasure.

Anyway, the motherboard specific parts are not needed to write the
drivers. They are needed to write configuration files. I don't say it's
not important, and I do want (probably more than anyone else)
motherboard manufacturers to provide complete and accurate data for us
to write these configuration files. But just because most of them
currently do not is no excuse for chip makers not to provide technical
documentation for their chips.

Also, motherboard specific configuration (mostly resistor values and
input labels) can sometimes be guessed from the BIOS setup screen or
from Windows tools. It's not ideal, but doable even by an average user.
By contrast, deriving a driver from the BIOS code or a Windows tool's
code is way more difficult when not simply impossible, let alone the
fact that it isn't necessarily legal in all countries.

So I would be grateful if you could avoid irrelevant comparisons.
Undocumented chips suck more than anything else, period.

> Actually I have used lm_sensors for a long time and my current uGuru 
> driver gives the most believable readings of all my setups all my 
> previous (asus) motherboards always had a couple of readings which were 
> significantly different from the BIOS, and those from the BIOS where 
> more realistic imho.

If your other Asus boards were using an AS99127F or ASB100 chip, no
wonder as we did not have datasheets for these ones either - and this
is the exact reason why I do not want to support more undocumented
chips: people tend to complain to us while we did our best.

Asus boards do not exactly have a good reputation when it comes to
hardware monitoring, and this ain't related to lm_sensors. Windows
tools such as Motherboard Monitor had the same issues we had. Alex van
Kaam stopped developping it in part because of this.

> I guess that we just have to accept that there will always be some guess 
> work in lm_sensors, untill motherboard manufacturers start giving away 
> full specs including schematics.

Guessing 5% out of the 95% you have documentation for is fine with me,
and I don't actually expect anything better than that, for nothing is
perfect in the real world.

Guessing 95% out of 5% requires a completely different nature and
amount of work, and that's something I have no interest in. We also
know by experience that it unsurprisingly results in much lower quality
drivers.

> I'm a big believer of opensource and openness in general for both soft- 
> and hardware (where are the good old days your radio/tv would come with 
> full schematics?) but in the end I'm also pragmatic and when I have to 
> choose between a blackbox approach to support XXX or bad/no support at 
> all I choose for a blackbox approach*

No. What you are providing right now IS bad support. I've read the
thread by Matthew Stamp on this list, and I know it's only the first
one of a long series of "doesn't work for me" posts about the uGuru.
This is the unavoidable consequence of writing drivers without any
technical documentation.

Whether bad support is better or worse than no support at all is a
different and open question. My opinion is that no support is better
because it avoids fooling hardware buyers into thinking that a chip is
supported when it isn't really. But I can understand that others have a
different opinion, especially when these others have themselves already
bought the cursed hardware in question.

> * going offtopic: One of the reasons for me to choose for a blackbox 
> approach if nescesarry is because I want Linux or more general 
> open-engineering to succeed, I really wish everything would be fully 
> open. But untill that day we need todo what we can to support as much 
> hardware as possible, so that people will be able to switch to an 
> opensource OS, whatever their hardware.

Your reasoning would hold if hardware wasn't obsolete after only a few
years these days. Given the little manpower we have to run the
lm_sensors project, it is way more efficient to let everyone know what
hardware not to buy than trying to support every chip, whatever
undocumentd crap that chip is. This is my way of being pragmatic.

> Once opensource has a significant place in the marketplace hopefully
> hardware will become more open too.

So we have the same goal in mind, but have different views on the best
ways to reach it. I do want manufacturers to open up their
specifications, and you say you want that too. You think this will
happen when open source has been successful enough. I think this is a
requirement for open source to be successful, because the key to open
source success it product quality, and you can't achieve that without
proper technical documentation.

-- 
Jean Delvare

[lm-sensors] New Abit uGuru driver + libsensors patch, review

[Hans de Goede]

Jean Delvare wrote:

> No. What you are providing right now IS bad support. I've read the
> thread by Matthew Stamp on this list, and I know it's only the first
> one of a long series of "doesn't work for me" posts about the uGuru.
> This is the unavoidable consequence of writing drivers without any
> technical documentation.
> 

That is not really fair, Matthew's problem has been fixed by a simple 
module option, one which was already present in the module before he 
posted about his problem because I already knew the detection code was 
weak. I'm currently looking into this problem with Matthew and my goal 
is to fix the driver so that Matthew will no longer need the option.

Also this driver is less then a month old and his seen very little 
testing, if when it has matured it still generates lots of problems I 
might come around to your point of view, but untill then I'll do my very 
best to make the abituguru driver as good as possible.

<snip> lots of other discussion about if its a good idea to try to 
support undocumented IC's or not </snip>

I'm happy that in the end we both have the same goals. Lets just say we 
agree that we disagree on how to get there.


Regards,

Hans