[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

Hello All

I have an Asus P5B Deluxe WiFi AP motherboard.  It has an Intel P965
chipset, but I do not know and have not been able to find out from extensive
googling and searching on Asus's site what hardware monitoring chip it uses.

I am running Suse 10.1 and have sensors-2.10.0-10 and kernel
2.6.16.21-0.13-smp installed.

The bios shows two temperatures (CPU and MB) and three fans (CPU, Chassis
fan 2, and Power Fan), and they all show reasonable outputs in the bios and
in Windows XP using Asus's PCProbe utility.

However, under linux, after running sensors-detect it recomments the
following:

# Generated by sensors-detect on Sun Aug 20 07:10:14 2006
MODULE_0=i2c-i801
MODULE_1=i2c-isa
MODULE_2îprom
MODULE_3=lm78

The output of sensors is pretty wacko in terms of fan speeds, and it shows
only the following:

lm78-isa-0290
Adapter: ISA adapter
VCore 1:   +2.26 V  (min =  +2.85 V, max =  +3.15 V)
VCore 2:   +3.63 V  (min =  +2.85 V, max =  +3.15 V)
+3.3V:     +3.28 V  (min =  +3.14 V, max =  +3.47 V)
+5V:       +5.48 V  (min =  +4.76 V, max =  +5.24 V)
+12V:      +9.18 V  (min = +11.37 V, max = +12.59 V)
-12V:     -11.01 V  (min = -12.63 V, max = -11.40 V)
-5V:       -3.61 V  (min =  -5.25 V, max =  -4.74 V)
fan1:        0 RPM  (min = 7758 RPM, div = 2)
fan2:     13636 RPM  (min = 1350000 RPM, div = 1)
fan3:        0 RPM  (min = 20454 RPM, div = 2)
temp:      +28.0??C  (high =   +26??C, hyst =   +80??C)   ALARM
vid:       +3.00 V

I think it is doubtful that this current, state of the art motherboard has
an actual lm78 chip on it (although I guess it's possible).  I scanned the
board visually for a Winbond chip or anything else that looks like a hw
monitoring chip but did not find anything (perhaps it's just my bad old eyes).

Does anyone here have good sensors outputs from one of these boards, and if
so would you mind sharing your configuration?

Thank you

Michael

PS: In BIOS, the sensors show the following approximate values:

CPU temp:    50C
MB temp:     28C
CPU fan:     2096rpm
Ch fan 2:    958rpm
Power fan:   2000rpm

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Rudolf Marek]

Hi Michael,

Please provide the dsdt.bin file, and send it to me in private (binary 
attachments will be stripped in archive)

cat /proc/acpi/dsdt > /tmp/dsdt.bin

And to mailing list, output of sensors-detect.

Thanks,
regards
Rudolf

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Tue, Aug 22, 2006 at 10:27:18PM +0200, Rudolf Marek wrote:
> Hi Michael,
> 
> Please provide the dsdt.bin file, and send it to me in private (binary 
> attachments will be stripped in archive)
> 
> cat /proc/acpi/dsdt > /tmp/dsdt.bin
> 
> And to mailing list, output of sensors-detect.

Will do both tonight, thanks very much!

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Tue, Aug 22, 2006 at 10:27:18PM +0200, Rudolf Marek wrote:
> Hi Michael,
> 
> Please provide the dsdt.bin file, and send it to me in private (binary 
> attachments will be stripped in archive)
> 
> cat /proc/acpi/dsdt > /tmp/dsdt.bin
> 
> And to mailing list, output of sensors-detect.

Here's the output of sensors-detect, and I have sent you the dsdt.bin file
privately as requested.  Thanks!

Michael

Script started on Tue Aug 22 14:21:42 2006
seahunt:~ # sensors-detect
# sensors-detect revision 1.413 (2006/01/19 20:28:00)

This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.

It is generally safe and recommended to accept the default answers to all
questions, unless you know what you're doing.

 We can start with probing for (PCI) I2C or SMBus adapters.
 You do not need any special privileges for this.
 Do you want to probe now? (YES/no): 
Probing for PCI bus adapters...
Sorry, no PCI bus adapters found.

We will now try to load each adapter module in turn.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

 To continue, we need module `i2c-dev' to be loaded.
 If it is built-in into your kernel, you can safely skip this.
 i2c-dev is not loaded. Do you want to load it now? (YES/no): 
 Module loaded succesfully.

 We are now going to do the adapter probings. Some adapters may hang halfway
 through; we can't really help that. Also, some chips will be double detected;
 we choose the one with the highest confidence value in that case.
 If you found that the adapter hung after probing a certain address, you can
 specify that address to remain unprobed. That often
 includes address 0x69 (clock chip).

Next adapter: SMBus I801 adapter at 0400
Do you want to scan it? (YES/no/selectively): 
Client found at address 0x08
Client found at address 0x22
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83627HF'... Failed!
Client found at address 0x30
Client found at address 0x32
Client at address 0x50 can not be probed - unload all client drivers first!
Client at address 0x52 can not be probed - unload all client drivers first!
Client found at address 0x69

Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively): 

Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively): 
Client found at address 0x50
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Probing for `DDC monitor'... Success!
    (confidence 8, driver `eeprom'), other addresses: 0x51 0x52 0x53 0x54 0x55 0x56 0x57
Probing for `Maxim MAX6900'... Failed!
Client found at address 0x51
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Client found at address 0x52
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Client found at address 0x53
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Client found at address 0x54
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Client found at address 0x55
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Client found at address 0x56
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Client found at address 0x57
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Probing for `Sony Vaio EEPROM'... Failed!

Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively): 

Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan the ISA bus? (YES/no): 
Probing for `National Semiconductor LM78'
  Trying address 0x0290... Success!
    (confidence 6, driver `lm78')
Probing for `National Semiconductor LM78-J'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
  Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627EHF'
  Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
  Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
  Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
  Trying general detect... Failed!
Probing for `ITE IT8712F'
  Trying address 0x0290... Failed!
Probing for `ITE IT8705F / SiS 950'
  Trying address 0x0290... Failed!
Probing for `IPMI BMC KCS'
  Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
  Trying address 0x0ca8... Failed!

Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan for Super I/O sensors? (YES/no): 
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83627HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83627THF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83637HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83687THF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83697HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83697SF/UF Super IO PWM'
  Failed! (0xa0)
Probing for `Winbond W83L517D Super IO'
  Failed! (0xa0)
Probing for `Fintek F71805F/FG Super IO Sensors'
  Failed! (0xa021)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (0xa021)

Do you want to scan for secondary Super I/O sensors? (YES/no): 
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (skipping family)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (skipping family)

 Now follows a summary of the probes I have just done.
 Just press ENTER to continue: 

Driver `eeprom' (should be inserted):
  Detects correctly:
  * Bus `NVIDIA I2C Device'
    Busdriver `UNKNOWN', I2C address 0x50 (and 0x51 0x52 0x53 0x54 0x55 0x56 0x57)
    Chip `DDC monitor' (confidence: 8)

Driver `lm78' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
    Chip `National Semiconductor LM78' (confidence: 6)


I will now generate the commands needed to load the I2C modules.
Use of uninitialized value in numeric eq (=) at /usr/sbin/sensors-detect line 4924.
Use of uninitialized value in numeric eq (=) at /usr/sbin/sensors-detect line 4924.
Use of uninitialized value in numeric eq (=) at /usr/sbin/sensors-detect line 4924.

To make the sensors modules behave correctly, add these lines to
/etc/modprobe.conf:

#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----cut here----

To load everything that is needed, add this to some /etc/rc* file:

#----cut here----
# I2C adapter drivers
modprobe i2c-i801
# modprobe unknown adapter NVIDIA I2C Device
# modprobe unknown adapter NVIDIA I2C Device
modprobe i2c-isa
# I2C chip drivers
modprobe eeprom
modprobe lm78
# sleep 2 # optional
/usr/bin/sensors -s # recommended
#----cut here----

WARNING! If you have some things built into your kernel, the list above
will contain too many modules. Skip the appropriate ones! You really should
try these commands right now to make sure everything is working properly.
Monitoring programs won't work until it's done.

Do you want to generate /etc/sysconfig/lm_sensors? (YES/no): n
seahunt:~ # exit

Script done on Tue Aug 22 14:22:19 2006



-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi Michael,

> I think it is doubtful that this current, state of the art motherboard has
> an actual lm78 chip on it (although I guess it's possible).  I scanned the
> board visually for a Winbond chip or anything else that looks like a hw
> monitoring chip but did not find anything (perhaps it's just my bad old eyes).

I agree with you, this is most certainly a misdetection.

> Here's the output of sensors-detect (...)
> 
> Script started on Tue Aug 22 14:21:42 2006
> seahunt:~ # sensors-detect
> # sensors-detect revision 1.413 (2006/01/19 20:28:00)
> 
> This program will help you determine which I2C/SMBus modules you need to
> load to use lm_sensors most effectively. You need to have i2c and
> lm_sensors installed before running this program.
> Also, you need to be `root', or at least have access to the /dev/i2c-*
> files, for most things.
> If you have patched your kernel and have some drivers built in, you can
> safely answer NO if asked to load some modules. In this case, things may
> seem a bit confusing, but they will still work.
> 
> It is generally safe and recommended to accept the default answers to all
> questions, unless you know what you're doing.
> 
>  We can start with probing for (PCI) I2C or SMBus adapters.
>  You do not need any special privileges for this.
>  Do you want to probe now? (YES/no): 
> Probing for PCI bus adapters...
> Sorry, no PCI bus adapters found.

I guess you have an Intel ICH8 chip on the board. Our detection script
didn't recognize it, I just added it in SVN. No big deal anyway as the
required driver is automatically loaded.

> We will now try to load each adapter module in turn.
> If you have undetectable or unsupported adapters, you can have them
> scanned by manually loading the modules before running this script.
> 
>  To continue, we need module `i2c-dev' to be loaded.
>  If it is built-in into your kernel, you can safely skip this.
>  i2c-dev is not loaded. Do you want to load it now? (YES/no): 
>  Module loaded succesfully.
> 
>  We are now going to do the adapter probings. Some adapters may hang halfway
>  through; we can't really help that. Also, some chips will be double detected;
>  we choose the one with the highest confidence value in that case.
>  If you found that the adapter hung after probing a certain address, you can
>  specify that address to remain unprobed. That often
>  includes address 0x69 (clock chip).
> 
> Next adapter: SMBus I801 adapter at 0400
> Do you want to scan it? (YES/no/selectively): 
> Client found at address 0x08
> Client found at address 0x22
> Probing for `National Semiconductor LM78'... Failed!
> Probing for `National Semiconductor LM78-J'... Failed!
> Probing for `National Semiconductor LM79'... Failed!
> Probing for `Winbond W83781D'... Failed!
> Probing for `Winbond W83782D'... Failed!
> Probing for `Winbond W83627HF'... Failed!

I wonder what chip it can be. Can you please provide a dump of it?

To generate a dump you need to find out the correct i2c bus number.
Make sure i2c-dev is loaded, then run "i2cdetect -l" and find the i2c
bus number for "SMBus I801", then run "i2cdump N 0x22" where N is
that i2c bus number.

> Client found at address 0x30
> Client found at address 0x32
> Client at address 0x50 can not be probed - unload all client drivers first!
> Client at address 0x52 can not be probed - unload all client drivers first!
> Client found at address 0x69
> 
> Next adapter: NVIDIA I2C Device
> Do you want to scan it? (YES/no/selectively): 
> 
> Next adapter: NVIDIA I2C Device
> Do you want to scan it? (YES/no/selectively): 
> Client found at address 0x50
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Probing for `DDC monitor'... Success!
>     (confidence 8, driver `eeprom'), other addresses: 0x51 0x52 0x53 0x54 0x55 0x56 0x57
> Probing for `Maxim MAX6900'... Failed!
> Client found at address 0x51
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Client found at address 0x52
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Client found at address 0x53
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Client found at address 0x54
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Client found at address 0x55
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Client found at address 0x56
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Client found at address 0x57
> Probing for `SPD EEPROM'... Success!
>     (confidence 1, driver `eeprom')
> Probing for `Sony Vaio EEPROM'... Failed!
> 
> Next adapter: NVIDIA I2C Device
> Do you want to scan it? (YES/no/selectively): 

These are i2c busses provided by the proprietary nvidia graphics
driver. We shouldn't even accept to help you with this driver loaded...

> Some chips are also accessible through the ISA bus. ISA probes are
> typically a bit more dangerous, as we have to write to I/O ports to do
> this. This is usually safe though.
> 
> Do you want to scan the ISA bus? (YES/no): 
> Probing for `National Semiconductor LM78'
>   Trying address 0x0290... Success!
>     (confidence 6, driver `lm78')
> Probing for `National Semiconductor LM78-J'
>   Trying address 0x0290... Failed!
> Probing for `National Semiconductor LM79'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83781D'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83782D'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627HF'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627EHF'
>   Trying address 0x0290... Failed!
> Probing for `Silicon Integrated Systems SIS5595'
>   Trying general detect... Failed!
> Probing for `VIA Technologies VT82C686 Integrated Sensors'
>   Trying general detect... Failed!
> Probing for `VIA Technologies VT8231 Integrated Sensors'
>   Trying general detect... Failed!
> Probing for `ITE IT8712F'
>   Trying address 0x0290... Failed!
> Probing for `ITE IT8705F / SiS 950'
>   Trying address 0x0290... Failed!
> Probing for `IPMI BMC KCS'
>   Trying address 0x0ca0... Failed!
> Probing for `IPMI BMC SMIC'
>   Trying address 0x0ca8... Failed!
> 
> Some Super I/O chips may also contain sensors. Super I/O probes are
> typically a bit more dangerous, as we have to write to I/O ports to do
> this. This is usually safe though.
> 
> Do you want to scan for Super I/O sensors? (YES/no): 
> Probing for `ITE 8702F Super IO Sensors'
>   Failed! (skipping family)
> Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `SMSC 47B27x Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `VT1211 Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83627HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83627THF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83637HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83687THF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83697HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83697SF/UF Super IO PWM'
>   Failed! (0xa0)
> Probing for `Winbond W83L517D Super IO'
>   Failed! (0xa0)
> Probing for `Fintek F71805F/FG Super IO Sensors'
>   Failed! (0xa021)
> Probing for `Winbond W83627EHF/EHG Super IO Sensors'
>   Failed! (0xa021)

This Super-I/O device ID (0xa021) matches the new Winbond W83627DHG
chip. Your version of the sensors-detect script doesn't know about it
yet, but the one in SVN does.

So the good news is that we know what your hardware monitoring chip is.

The bad news is that we don't support that chip yet.

The not so bad news is that this chip might be more or less compatible
with the W83627EHG, which we do support.

Can you please provide a dump of the chip?
isadump 0x295 0x296

> Do you want to scan for secondary Super I/O sensors? (YES/no): 
> Probing for `ITE 8702F Super IO Sensors'
>   Failed! (skipping family)
> Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `SMSC 47B27x Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `VT1211 Super IO Sensors'
>   Failed! (skipping family)
> Probing for `Winbond W83627EHF/EHG Super IO Sensors'
>   Failed! (skipping family)
> 
>  Now follows a summary of the probes I have just done.
>  Just press ENTER to continue: 
> 
> Driver `eeprom' (should be inserted):
>   Detects correctly:
>   * Bus `NVIDIA I2C Device'
>     Busdriver `UNKNOWN', I2C address 0x50 (and 0x51 0x52 0x53 0x54 0x55 0x56 0x57)
>     Chip `DDC monitor' (confidence: 8)
> 
> Driver `lm78' (should be inserted):
>   Detects correctly:
>   * ISA bus address 0x0290 (Busdriver `i2c-isa')
>     Chip `National Semiconductor LM78' (confidence: 6)
> 
> 
> I will now generate the commands needed to load the I2C modules.
> Use of uninitialized value in numeric eq (=) at /usr/sbin/sensors-detect line 4924.
> Use of uninitialized value in numeric eq (=) at /usr/sbin/sensors-detect line 4924.
> Use of uninitialized value in numeric eq (=) at /usr/sbin/sensors-detect line 4924.

Hmm, this is bad. The line numbers don't seem to match sensors-detect
in lm_sensors 2.10.0 despite the version number, so I can't tell what's
wrong.

Can you please try the latest version of sensors-detect:
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
And tell us whether you still have these warnings?

> To make the sensors modules behave correctly, add these lines to
> /etc/modprobe.conf:
> 
> #----cut here----
> # I2C module options
> alias char-major-89 i2c-dev
> #----cut here----
> 
> To load everything that is needed, add this to some /etc/rc* file:
> 
> #----cut here----
> # I2C adapter drivers
> modprobe i2c-i801
> # modprobe unknown adapter NVIDIA I2C Device
> # modprobe unknown adapter NVIDIA I2C Device

This is odd too, this should be listed only once.

> modprobe i2c-isa
> # I2C chip drivers
> modprobe eeprom
> modprobe lm78
> # sleep 2 # optional
> /usr/bin/sensors -s # recommended
> #----cut here----
> 
> WARNING! If you have some things built into your kernel, the list above
> will contain too many modules. Skip the appropriate ones! You really should
> try these commands right now to make sure everything is working properly.
> Monitoring programs won't work until it's done.
> 
> Do you want to generate /etc/sysconfig/lm_sensors? (YES/no): n
> seahunt:~ # exit
> 
> Script done on Tue Aug 22 14:22:19 2006

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

BTW, I don't know if it matters, but this motherboard is running an Intel
Core2 Duo E6400 processor.  Perhaps that affects how the cpu temp is
determined?

I think this board will be a popular one since there aren't that many Core2
Duo - ready boards out yet, and this is one of them.

Thanks
Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

I tried with the SVN sensors-detect, and the results were different, but
apparently not correct.  It looked like this:

Script started on Sat Aug 26 06:03:29 2006
seahunt:/usr/local/src # ./sensors-detect 
# sensors-detect revision $Revision$ ($Date$)

This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.

It is generally safe and recommended to accept the default answers to all
questions, unless you know what you're doing.

 We can start with probing for (PCI) I2C or SMBus adapters.
 You do not need any special privileges for this.
 Do you want to probe now? (YES/no): 
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 00:1f.3: Intel ICH8
Probe successfully concluded.

We will now try to load each adapter module in turn.
Module `i2c-i801' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

 To continue, we need module `i2c-dev' to be loaded.
 If it is built-in into your kernel, you can safely skip this.
 i2c-dev is not loaded. Do you want to load it now? (YES/no): 
 Module loaded successfully.

 We are now going to do the adapter probings. Some adapters may hang halfway
 through; we can't really help that. Also, some chips will be double detected;
 we choose the one with the highest confidence value in that case.
 If you found that the adapter hung after probing a certain address, you can
 specify that address to remain unprobed. That often
 includes address 0x69 (clock chip).

Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively): 
Adapter cannot be probed, skipping.

Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively): 
Adapter cannot be probed, skipping.

Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively): 
Adapter cannot be probed, skipping.

Next adapter: SMBus I801 adapter at 0400
Do you want to scan it? (YES/no/selectively): 
Client found at address 0x08
Client found at address 0x22
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83627HF'... Failed!
Client found at address 0x30
Client found at address 0x32
Client found at address 0x50
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Probing for `EDID EEPROM'... Failed!
Probing for `Maxim MAX6900'... Failed!
Client found at address 0x52
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Client found at address 0x69

Some chips are also accessible through the ISA I/O ports. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!

Do you want to scan the ISA I/O ports? (YES/no): 
Probing for `National Semiconductor LM78'
  Trying address 0x0290... Success!
    (confidence 6, driver `lm78')
Probing for `National Semiconductor LM78-J'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
  Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627EHF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627DHG'
  Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
  Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
  Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
  Trying general detect... Failed!
Probing for `AMD K8 thermal sensors'
  Trying general detect... Failed!
Probing for `IPMI BMC KCS'
  Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
  Trying address 0x0ca8... Failed!

Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan for Super I/O sensors? (YES/no): 
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83627HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83627THF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83637HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83687THF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83697HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83697SF/UF Super IO PWM'
  Failed! (0xa0)
Probing for `Winbond W83L517D Super IO'
  Failed! (0xa0)
Probing for `Fintek F71805F/FG Super IO Sensors'
  Failed! (0xa021)
Probing for `Fintek F71872F/FG Super IO Sensors'
  Failed! (0xa021)
Probing for `Fintek F81218D Super IO'
  Failed! (0xa021)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (0xa021)
Probing for `Winbond W83627DHG Super IO Sensors'
  Success... found at address 0x0290

Do you want to scan for secondary Super I/O sensors? (YES/no): 
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (skipping family)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (skipping family)

 Now follows a summary of the probes I have just done.
 Just press ENTER to continue: 

Driver `eeprom' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 0400'
    Busdriver `i2c-i801', I2C address 0x50
    Chip `SPD EEPROM' (confidence: 8)
  * Bus `SMBus I801 adapter at 0400'
    Busdriver `i2c-i801', I2C address 0x52
    Chip `SPD EEPROM' (confidence: 8)

  EEPROMs are *NOT* sensors! They are data storage chips commonly
  found on memory modules (SPD), in monitors (EDID), or in some
  laptops, for example.

Driver `lm78' (may not be inserted):
  Misdetects:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
    Chip `National Semiconductor LM78' (confidence: 6)

Driver `w83627ehf' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
    Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)


I will now generate the commands needed to load the required modules.

To make the sensors modules behave correctly, add these lines to
/etc/modules.conf:

#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----cut here----

To load everything that is needed, add this to some /etc/rc* file:

#----cut here----
# I2C adapter drivers
modprobe i2c-i801
modprobe i2c-isa
# Chip drivers
modprobe eeprom
modprobe w83627ehf
# sleep 2 # optional
/usr/local/bin/sensors -s # recommended
#----cut here----

WARNING! If you have some things built into your kernel, the list above
will contain too many modules. Skip the appropriate ones! You really should
try these commands right now to make sure everything is working properly.
Monitoring programs won't work until it's done.

Do you want to generate /etc/sysconfig/lm_sensors? (YES/no): 
Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors
for initialization at boot time.


However.... running /etc/init.d/lm_sensors start says "FAILED" and if I try
to:

modprobe w83627ehf
FATAL: Error inserting w83627ehf
(/lib/modules/2.6.16.21-0.13-smp/kernel/drivers/hwmon/w83627ehf.ko): No such
device

So, I am back to using LM78 instead, which gives limited and probably bogus
information:

lm78-isa-0290
Adapter: ISA adapter
VCore 1:   +2.26 V  (min =  +2.85 V, max =  +3.15 V)
VCore 2:   +3.63 V  (min =  +2.85 V, max =  +3.15 V)
+3.3V:     +3.28 V  (min =  +3.14 V, max =  +3.47 V)
+5V:       +5.48 V  (min =  +4.76 V, max =  +5.24 V)
+12V:      +9.24 V  (min = +11.37 V, max = +12.59 V)
-12V:     -11.01 V  (min = -12.63 V, max = -11.40 V)
-5V:       -3.64 V  (min =  -5.25 V, max =  -4.74 V)
fan1:        0 RPM  (min = 7105 RPM, div = 2)
fan2:     1928 RPM  (min = 337500 RPM, div = 4)
fan3:        0 RPM  (min = 20454 RPM, div = 2)
temp:      +29.0??C  (high =   +26??C, hyst =   +80??C)   ALARM
vid:       +3.00 V

In contrast, the BIOS reports:

CPU Temp     	      51C
MB Temp	     	      30C
CPU Fan Speed	      2191 RPM
CPU Q-Fan control     disabled
Chassis fan 1	      N/A
Chassis fan 2	      969 RPM
Chassis fan 3	      N/A
Chassis Q-fan control disabled
Power fan speed	      2096
VCORE voltage	      1.224v
3.3V voltage	      3.264v
5V voltage	      5.068v
12V voltage	      11.932v


-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Michael,

> I tried with the SVN sensors-detect, and the results were different, but
> apparently not correct.  It looked like this:
> 
> Script started on Sat Aug 26 06:03:29 2006
> seahunt:/usr/local/src # ./sensors-detect 
> # sensors-detect revision $Revision$ ($Date$)
> 
> This program will help you determine which I2C/SMBus modules you need to
> load to use lm_sensors most effectively. You need to have i2c and
> lm_sensors installed before running this program.
> Also, you need to be `root', or at least have access to the /dev/i2c-*
> files, for most things.
> If you have patched your kernel and have some drivers built in, you can
> safely answer NO if asked to load some modules. In this case, things may
> seem a bit confusing, but they will still work.
> 
> It is generally safe and recommended to accept the default answers to all
> questions, unless you know what you're doing.
> 
>  We can start with probing for (PCI) I2C or SMBus adapters.
>  You do not need any special privileges for this.
>  Do you want to probe now? (YES/no): 
> Probing for PCI bus adapters...
> Use driver `i2c-i801' for device 00:1f.3: Intel ICH8
> Probe successfully concluded.
> 
> We will now try to load each adapter module in turn.
> Module `i2c-i801' already loaded.
> If you have undetectable or unsupported adapters, you can have them
> scanned by manually loading the modules before running this script.
> 
>  To continue, we need module `i2c-dev' to be loaded.
>  If it is built-in into your kernel, you can safely skip this.
>  i2c-dev is not loaded. Do you want to load it now? (YES/no): 
>  Module loaded successfully.
> 
>  We are now going to do the adapter probings. Some adapters may hang halfway
>  through; we can't really help that. Also, some chips will be double detected;
>  we choose the one with the highest confidence value in that case.
>  If you found that the adapter hung after probing a certain address, you can
>  specify that address to remain unprobed. That often
>  includes address 0x69 (clock chip).
> 
> Next adapter: NVIDIA I2C Device
> Do you want to scan it? (YES/no/selectively): 
> Adapter cannot be probed, skipping.
> 
> Next adapter: NVIDIA I2C Device
> Do you want to scan it? (YES/no/selectively): 
> Adapter cannot be probed, skipping.
> 
> Next adapter: NVIDIA I2C Device
> Do you want to scan it? (YES/no/selectively): 
> Adapter cannot be probed, skipping.
> 
> Next adapter: SMBus I801 adapter at 0400
> Do you want to scan it? (YES/no/selectively): 
> Client found at address 0x08
> Client found at address 0x22
> Probing for `National Semiconductor LM78'... Failed!
> Probing for `National Semiconductor LM78-J'... Failed!
> Probing for `National Semiconductor LM79'... Failed!
> Probing for `Winbond W83781D'... Failed!
> Probing for `Winbond W83782D'... Failed!
> Probing for `Winbond W83627HF'... Failed!
> Client found at address 0x30
> Client found at address 0x32
> Client found at address 0x50
> Probing for `SPD EEPROM'... Success!
>     (confidence 8, driver `eeprom')
> Probing for `EDID EEPROM'... Failed!
> Probing for `Maxim MAX6900'... Failed!
> Client found at address 0x52
> Probing for `SPD EEPROM'... Success!
>     (confidence 8, driver `eeprom')
> Client found at address 0x69
> 
> Some chips are also accessible through the ISA I/O ports. ISA probes are
> typically a bit more dangerous, as we have to write to I/O ports to do
> this. This is usually safe though.
> Yes, you do have ISA I/O ports even if you do not have any ISA slots!
> 
> Do you want to scan the ISA I/O ports? (YES/no): 
> Probing for `National Semiconductor LM78'
>   Trying address 0x0290... Success!
>     (confidence 6, driver `lm78')
> Probing for `National Semiconductor LM78-J'
>   Trying address 0x0290... Failed!
> Probing for `National Semiconductor LM79'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83781D'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83782D'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627HF'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627EHF'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627DHG'
>   Trying address 0x0290... Failed!
> Probing for `Silicon Integrated Systems SIS5595'
>   Trying general detect... Failed!
> Probing for `VIA Technologies VT82C686 Integrated Sensors'
>   Trying general detect... Failed!
> Probing for `VIA Technologies VT8231 Integrated Sensors'
>   Trying general detect... Failed!
> Probing for `AMD K8 thermal sensors'
>   Trying general detect... Failed!
> Probing for `IPMI BMC KCS'
>   Trying address 0x0ca0... Failed!
> Probing for `IPMI BMC SMIC'
>   Trying address 0x0ca8... Failed!
> 
> Some Super I/O chips may also contain sensors. Super I/O probes are
> typically a bit more dangerous, as we have to write to I/O ports to do
> this. This is usually safe though.
> 
> Do you want to scan for Super I/O sensors? (YES/no): 
> Probing for `ITE 8702F Super IO Sensors'
>   Failed! (skipping family)
> Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `SMSC 47B27x Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `VT1211 Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83627HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83627THF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83637HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83687THF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83697HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83697SF/UF Super IO PWM'
>   Failed! (0xa0)
> Probing for `Winbond W83L517D Super IO'
>   Failed! (0xa0)
> Probing for `Fintek F71805F/FG Super IO Sensors'
>   Failed! (0xa021)
> Probing for `Fintek F71872F/FG Super IO Sensors'
>   Failed! (0xa021)
> Probing for `Fintek F81218D Super IO'
>   Failed! (0xa021)
> Probing for `Winbond W83627EHF/EHG Super IO Sensors'
>   Failed! (0xa021)
> Probing for `Winbond W83627DHG Super IO Sensors'
>   Success... found at address 0x0290
> 
> Do you want to scan for secondary Super I/O sensors? (YES/no): 
> Probing for `ITE 8702F Super IO Sensors'
>   Failed! (skipping family)
> Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `SMSC 47B27x Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `VT1211 Super IO Sensors'
>   Failed! (skipping family)
> Probing for `Winbond W83627EHF/EHG Super IO Sensors'
>   Failed! (skipping family)
> 
>  Now follows a summary of the probes I have just done.
>  Just press ENTER to continue: 
> 
> Driver `eeprom' (should be inserted):
>   Detects correctly:
>   * Bus `SMBus I801 adapter at 0400'
>     Busdriver `i2c-i801', I2C address 0x50
>     Chip `SPD EEPROM' (confidence: 8)
>   * Bus `SMBus I801 adapter at 0400'
>     Busdriver `i2c-i801', I2C address 0x52
>     Chip `SPD EEPROM' (confidence: 8)
> 
>   EEPROMs are *NOT* sensors! They are data storage chips commonly
>   found on memory modules (SPD), in monitors (EDID), or in some
>   laptops, for example.
> 
> Driver `lm78' (may not be inserted):
>   Misdetects:
>   * ISA bus address 0x0290 (Busdriver `i2c-isa')
>     Chip `National Semiconductor LM78' (confidence: 6)
> 
> Driver `w83627ehf' (should be inserted):
>   Detects correctly:
>   * ISA bus address 0x0290 (Busdriver `i2c-isa')
>     Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)

Looks correct to me, this one is your hardware monitoring chip.

> 
> I will now generate the commands needed to load the required modules.
> 
> To make the sensors modules behave correctly, add these lines to
> /etc/modules.conf:
> 
> #----cut here----
> # I2C module options
> alias char-major-89 i2c-dev
> #----cut here----
> 
> To load everything that is needed, add this to some /etc/rc* file:
> 
> #----cut here----
> # I2C adapter drivers
> modprobe i2c-i801
> modprobe i2c-isa
> # Chip drivers
> modprobe eeprom
> modprobe w83627ehf
> # sleep 2 # optional
> /usr/local/bin/sensors -s # recommended
> #----cut here----
>
> WARNING! If you have some things built into your kernel, the list above
> will contain too many modules. Skip the appropriate ones! You really should
> try these commands right now to make sure everything is working properly.
> Monitoring programs won't work until it's done.
> 
> Do you want to generate /etc/sysconfig/lm_sensors? (YES/no): 
> Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors
> for initialization at boot time.
> 
> 
> However.... running /etc/init.d/lm_sensors start says "FAILED" and if I try
> to:
> 
> modprobe w83627ehf
> FATAL: Error inserting w83627ehf
> (/lib/modules/2.6.16.21-0.13-smp/kernel/drivers/hwmon/w83627ehf.ko): No such
> device

The W83627DHG is a bit different from the W83627EHF/EHG which is
supported by the w83627ehf driver. We need to add support for your
chip, so it's no surprise that it doesn't work yet.

> So, I am back to using LM78 instead, which gives limited and probably bogus
> information:
> 
> lm78-isa-0290
> Adapter: ISA adapter
> VCore 1:   +2.26 V  (min =  +2.85 V, max =  +3.15 V)
> VCore 2:   +3.63 V  (min =  +2.85 V, max =  +3.15 V)
> +3.3V:     +3.28 V  (min =  +3.14 V, max =  +3.47 V)
> +5V:       +5.48 V  (min =  +4.76 V, max =  +5.24 V)
> +12V:      +9.24 V  (min = +11.37 V, max = +12.59 V)
> -12V:     -11.01 V  (min = -12.63 V, max = -11.40 V)
> -5V:       -3.64 V  (min =  -5.25 V, max =  -4.74 V)
> fan1:        0 RPM  (min = 7105 RPM, div = 2)
> fan2:     1928 RPM  (min = 337500 RPM, div = 4)
> fan3:        0 RPM  (min = 20454 RPM, div = 2)
> temp:      +29.0??C  (high =   +26??C, hyst =   +80??C)   ALARM
> vid:       +3.00 V

No, forget about the LM78, your chip is completely different.

I will try to add some code in sensors-detect to prevent this
misdetection, as it might confuse other users.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Sat, Aug 26, 2006 at 11:21:32PM +0200, Jean Delvare wrote:

> >     Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)
> 
> Looks correct to me, this one is your hardware monitoring chip.

Cool!  Knowing what chip is on there makes me feel better, even if I can't
use it in Linux yet. 

> The W83627DHG is a bit different from the W83627EHF/EHG which is
> supported by the w83627ehf driver. We need to add support for your
> chip, so it's no surprise that it doesn't work yet.

Ok, understood.  

Thank you.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

I'm sorry Jean, I never saw your 8/23 response to this or I would have
responded to you.  Anyway, better late than never?

>I guess you have an Intel ICH8 chip on the board. Our detection script
>didn't recognize it, I just added it in SVN. No big deal anyway as the
>required driver is automatically loaded.

Yes, it's an ICH8.

>Can you please provide a dump of the chip?
>isadump 0x295 0x296

 # isadump 0x295 0x296
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x295 and data register 0x296.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 04 ff 04 4b 31 00 42 10 01 4b 01 01 3c 3c 0a 05
10: 04 ff 50 00 00 01 01 3c 43 17 00 00 ff ff ff c1
20: 8f e3 cc cc 97 c6 97 1d ff 61 ff c5 b2 c5 b2 d9
30: c4 c3 b1 cf bb e3 cd da c5 1a 50 57 01 21 19 ff
40: 03 10 00 de ff ff 00 15 2d 00 20 44 18 95 06 a3
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: 01 9b 31 52 9b 01 3c ff 12 ff 0a ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: 04 ff 04 4b 31 00 42 10 01 4b 01 01 3c 3c 0a 05
90: 04 ff 50 00 00 01 01 3c 43 17 00 00 ff ff ff c1
a0: 8f e3 cc cc 97 c6 97 1d ff 61 ff c5 b2 c5 b2 d9
b0: c4 c3 b1 cf bb e3 cd da c5 1a 50 57 01 21 19 ff
c0: 03 00 00 de ff ff 00 15 2d 00 20 44 18 95 06 a3
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: 01 9b 31 52 9b 01 3c ff 12 ff 0a ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

>Can you please try the latest version of sensors-detect:
>http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
>And tell us whether you still have these warnings?

Script started on Fri Sep  1 05:55:43 2006
seahunt:/usr/local/src # ./sensors-detect 
# sensors-detect revision $Revision$ ($Date$)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no): 
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 00:1f.3: Intel ICH8
Probe successfully concluded.

We will now try to load each adapter module in turn.
Load `i2c-i801' (say NO if built into your kernel)? (YES/no): 
Module loaded successfully.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

To continue, we need module `i2c-dev' to be loaded.
Do you want to load `i2c-dev' now? (YES/no): 
Module loaded successfully.

We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence value
in that case.
If you found that the adapter hung after probing a certain address, you
can specify that address to remain unprobed.

Next adapter: SMBus I801 adapter at 0400
Do you want to scan it? (YES/no/selectively): 
Client found at address 0x08
Client found at address 0x22
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83627HF'... Failed!
Client found at address 0x30
Client found at address 0x32
Client found at address 0x50
Probing for `Analog Devices ADM1033'... Failed!
Probing for `Analog Devices ADM1034'... Failed!
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Probing for `EDID EEPROM'... Failed!
Probing for `Maxim MAX6900'... Failed!
Client found at address 0x52
Probing for `Analog Devices ADM1033'... Failed!
Probing for `Analog Devices ADM1034'... Failed!
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Client found at address 0x69

Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to do this. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): 
Probing for `National Semiconductor LM78'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM78-J'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
  Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627EHF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627DHG'
  Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
  Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
  Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
  Trying general detect... Failed!
Probing for `AMD K8 thermal sensors'
  Trying general detect... Failed!
Probing for `IPMI BMC KCS'
  Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
  Trying address 0x0ca8... Failed!

Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to do this. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83627HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83627THF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83637HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83687THF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83697HF Super IO Sensors'
  Failed! (0xa0)
Probing for `Winbond W83697SF/UF Super IO PWM'
  Failed! (0xa0)
Probing for `Winbond W83L517D Super IO'
  Failed! (0xa0)
Probing for `Fintek F71805F/FG Super IO Sensors'
  Failed! (0xa021)
Probing for `Fintek F71872F/FG Super IO Sensors'
  Failed! (0xa021)
Probing for `Fintek F81218D Super IO'
  Failed! (0xa021)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (0xa021)
Probing for `Winbond W83627DHG Super IO Sensors'
  Success... found at address 0x0290

Do you want to scan for secondary Super I/O sensors? (YES/no): 
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (skipping family)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (skipping family)

Now follows a summary of the probes I have just done.
Just press ENTER to continue: 

Driver `eeprom' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 0400'
    Busdriver `i2c-i801', I2C address 0x50
    Chip `SPD EEPROM' (confidence: 8)
  * Bus `SMBus I801 adapter at 0400'
    Busdriver `i2c-i801', I2C address 0x52
    Chip `SPD EEPROM' (confidence: 8)

  EEPROMs are *NOT* sensors! They are data storage chips commonly
  found on memory modules (SPD), in monitors (EDID), or in some
  laptops, for example.

Driver `w83627ehf' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
    Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)

I will now generate the commands needed to load the required modules.
Just press ENTER to continue: 

To make the sensors modules behave correctly, add these lines to
/etc/modules.conf:

#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----cut here----

To load everything that is needed, add this to some /etc/rc* file:

#----cut here----
# I2C adapter drivers
modprobe i2c-i801
modprobe i2c-isa
# Chip drivers
modprobe eeprom
modprobe w83627ehf
# sleep 2 # optional
/usr/local/bin/sensors -s # recommended
#----cut here----

If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones! You really
should try these commands right now to make sure everything is
working properly. Monitoring programs won't work until the needed
modules are loaded.

Do you want to generate /etc/sysconfig/lm_sensors? (YES/no): no
seahunt:/usr/local/src # exit

Script done on Fri Sep  1 05:58:20 2006

Thank you!

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi Michael,

> I'm sorry Jean, I never saw your 8/23 response to this or I would have
> responded to you.  Anyway, better late than never?

Yep, I seem to remember I received a bounce for my mail, like your mail
server didn't like my SMTP or something like that. Sorry about that. To
prevent this from happening again, I am replying to the list only this
time.

> >I guess you have an Intel ICH8 chip on the board. Our detection script
> >didn't recognize it, I just added it in SVN. No big deal anyway as the
> >required driver is automatically loaded.
> 
> Yes, it's an ICH8.
> 
> >Can you please provide a dump of the chip?
> >isadump 0x295 0x296
> 
>  # isadump 0x295 0x296
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address register 0x295 and data register 0x296.
> Continue? [Y/n]
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 04 ff 04 4b 31 00 42 10 01 4b 01 01 3c 3c 0a 05
> 10: 04 ff 50 00 00 01 01 3c 43 17 00 00 ff ff ff c1
> 20: 8f e3 cc cc 97 c6 97 1d ff 61 ff c5 b2 c5 b2 d9
> 30: c4 c3 b1 cf bb e3 cd da c5 1a 50 57 01 21 19 ff
> 40: 03 10 00 de ff ff 00 15 2d 00 20 44 18 95 06 a3
> 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 60: 01 9b 31 52 9b 01 3c ff 12 ff 0a ff ff ff ff ff
> 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 80: 04 ff 04 4b 31 00 42 10 01 4b 01 01 3c 3c 0a 05
> 90: 04 ff 50 00 00 01 01 3c 43 17 00 00 ff ff ff c1
> a0: 8f e3 cc cc 97 c6 97 1d ff 61 ff c5 b2 c5 b2 d9
> b0: c4 c3 b1 cf bb e3 cd da c5 1a 50 57 01 21 19 ff
> c0: 03 00 00 de ff ff 00 15 2d 00 20 44 18 95 06 a3
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> e0: 01 9b 31 52 9b 01 3c ff 12 ff 0a ff ff ff ff ff
> f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

OK, thanks. I've added it to my collection.

> >Can you please try the latest version of sensors-detect:
> >http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
> >And tell us whether you still have these warnings?
> 
> Script started on Fri Sep  1 05:55:43 2006
> seahunt:/usr/local/src # ./sensors-detect 
> # sensors-detect revision $Revision$ ($Date$)
> 
> This program will help you determine which kernel modules you need
> to load to use lm_sensors most effectively. It is generally safe
> and recommended to accept the default answers to all questions,
> unless you know what you're doing.
> 
> We can start with probing for (PCI) I2C or SMBus adapters.
> Do you want to probe now? (YES/no): 
> Probing for PCI bus adapters...
> Use driver `i2c-i801' for device 00:1f.3: Intel ICH8
> Probe successfully concluded.

Good.

> 
> We will now try to load each adapter module in turn.
> Load `i2c-i801' (say NO if built into your kernel)? (YES/no): 
> Module loaded successfully.
> If you have undetectable or unsupported adapters, you can have them
> scanned by manually loading the modules before running this script.
> 
> To continue, we need module `i2c-dev' to be loaded.
> Do you want to load `i2c-dev' now? (YES/no): 
> Module loaded successfully.
> 
> We are now going to do the I2C/SMBus adapter probings. Some chips may
> be double detected; we choose the one with the highest confidence value
> in that case.
> If you found that the adapter hung after probing a certain address, you
> can specify that address to remain unprobed.
> 
> Next adapter: SMBus I801 adapter at 0400
> Do you want to scan it? (YES/no/selectively): 
> Client found at address 0x08
> Client found at address 0x22
> Probing for `National Semiconductor LM78'... Failed!
> Probing for `National Semiconductor LM78-J'... Failed!
> Probing for `National Semiconductor LM79'... Failed!
> Probing for `Winbond W83781D'... Failed!
> Probing for `Winbond W83782D'... Failed!
> Probing for `Winbond W83627HF'... Failed!
> Client found at address 0x30
> Client found at address 0x32
> Client found at address 0x50
> Probing for `Analog Devices ADM1033'... Failed!
> Probing for `Analog Devices ADM1034'... Failed!
> Probing for `SPD EEPROM'... Success!
>     (confidence 8, driver `eeprom')
> Probing for `EDID EEPROM'... Failed!
> Probing for `Maxim MAX6900'... Failed!
> Client found at address 0x52
> Probing for `Analog Devices ADM1033'... Failed!
> Probing for `Analog Devices ADM1034'... Failed!
> Probing for `SPD EEPROM'... Success!
>     (confidence 8, driver `eeprom')
> Client found at address 0x69
> 
> Some chips are also accessible through the ISA I/O ports. We have to
> write to arbitrary I/O ports to do this. This is usually safe though.
> Yes, you do have ISA I/O ports even if you do not have any ISA slots!
> Do you want to scan the ISA I/O ports? (YES/no): 
> Probing for `National Semiconductor LM78'
>   Trying address 0x0290... Failed!

My misdetection prevention measures worked :)

> Probing for `National Semiconductor LM78-J'
>   Trying address 0x0290... Failed!
> Probing for `National Semiconductor LM79'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83781D'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83782D'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627HF'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627EHF'
>   Trying address 0x0290... Failed!
> Probing for `Winbond W83627DHG'
>   Trying address 0x0290... Failed!

This legacy detection method failed, I guess the heuristics are not
working for your chip.

Given that these 3 last chips (W83627HF, W83627EHF and W83627DHG) are
Super-I/O chips and are detected again later using a  more reliable
method, I suggest we drop the legacy detection method for them. I've
already done so for the ITE family some weeks ago. Objection anyone?

> Probing for `Silicon Integrated Systems SIS5595'
>   Trying general detect... Failed!
> Probing for `VIA Technologies VT82C686 Integrated Sensors'
>   Trying general detect... Failed!
> Probing for `VIA Technologies VT8231 Integrated Sensors'
>   Trying general detect... Failed!
> Probing for `AMD K8 thermal sensors'
>   Trying general detect... Failed!
> Probing for `IPMI BMC KCS'
>   Trying address 0x0ca0... Failed!
> Probing for `IPMI BMC SMIC'
>   Trying address 0x0ca8... Failed!
> 
> Some Super I/O chips may also contain sensors. We have to write to
> standard I/O ports to do this. This is usually safe.
> Do you want to scan for Super I/O sensors? (YES/no): 
> Probing for `ITE 8702F Super IO Sensors'
>   Failed! (skipping family)
> Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `SMSC 47B27x Super IO Fan Sensors'
>   Failed! (skipping family)
> Probing for `VT1211 Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83627HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83627THF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83637HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83687THF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83697HF Super IO Sensors'
>   Failed! (0xa0)
> Probing for `Winbond W83697SF/UF Super IO PWM'
>   Failed! (0xa0)
> Probing for `Winbond W83L517D Super IO'
>   Failed! (0xa0)
> Probing for `Fintek F71805F/FG Super IO Sensors'
>   Failed! (0xa021)
> Probing for `Fintek F71872F/FG Super IO Sensors'
>   Failed! (0xa021)
> Probing for `Fintek F81218D Super IO'
>   Failed! (0xa021)
> Probing for `Winbond W83627EHF/EHG Super IO Sensors'
>   Failed! (0xa021)
> Probing for `Winbond W83627DHG Super IO Sensors'
>   Success... found at address 0x0290

This confirms my earlier guess. Good. As I said before, we don't have
support right now, but support could be added to the w83627ehf driver
with relatively little effort. You'll have to wait until this happens.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi Jean, Michael, and Yuan,

Yuan: can I request the W83627DHF/DHG datasheet?

> Given that these 3 last chips (W83627HF, W83627EHF and W83627DHG) are
> Super-I/O chips and are detected again later using a  more reliable
> method, I suggest we drop the legacy detection method for them. I've
> already done so for the ITE family some weeks ago. Objection anyone?

No objections here.

> This confirms my earlier guess. Good. As I said before, we don't have
> support right now, but support could be added to the w83627ehf driver
> with relatively little effort. You'll have to wait until this happens.

From the Winbond website
(http://www.winbond-usa.com/mambo/content/view/143/273/) there is one
less Vin, and some VID I/O. The datasheet is available by request
only. But if Yuan Mu could send a datasheet, I would greatly
appreciate it. In fact, Yuan, can you CC Jean on that? He will
probably need it too.

I'd be happy to add the support. If Michael wouldn't mind testing the
driver, we could get started.

David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi David, Yuan,

> > Given that these 3 last chips (W83627HF, W83627EHF and W83627DHG) are
> > Super-I/O chips and are detected again later using a  more reliable
> > method, I suggest we drop the legacy detection method for them. I've
> > already done so for the ITE family some weeks ago. Objection anyone?
> 
> No objections here.

Good.

> > This confirms my earlier guess. Good. As I said before, we don't have
> > support right now, but support could be added to the w83627ehf driver
> > with relatively little effort. You'll have to wait until this happens.
> 
> From the Winbond website
> (http://www.winbond-usa.com/mambo/content/view/143/273/) there is one
> less Vin, and some VID I/O.

Here are my own comparison notes of some says ago:

* 8-bit VID instead of 6-bit
* No VIN4 (I don't know which one this is in the driver)
* Additional critical limit for the 3 temperature sensors - part of the
  automatic fan speed regulation interface

This was only after a quick glance, I could have overlooked something,
but all in all adding support for that chip should be pretty
straightforward.

> The datasheet is available by request
> only. But if Yuan Mu could send a datasheet, I would greatly
> appreciate it. In fact, Yuan, can you CC Jean on that? He will
> probably need it too.

I do have it already, our Winbond partners were kind enough to share it
with Rudolf Marek and me. But I cannot send it to you without the
express agreement of Yuan Mu or another Winbond representative, as the
datasheet is not public, as you found out yourself.

> I'd be happy to add the support. If Michael wouldn't mind testing the
> driver, we could get started.

Yuan, I would have added support for the W83627DHG myself but it seems
I am out of time. So I think we have a great opportunity if David does
have the time to add support. Can I share the datasheet with him? He
already contributed to our w83627ehf driver, I think we can trust him.

Thanks,
-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Fri, Sep 01, 2006 at 11:24:24PM -0700, David Hubbard wrote:

> I'd be happy to add the support. If Michael wouldn't mind testing the
> driver, we could get started.

I'd be happy to.  Please advise when I can help in some way.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hello, all,

On 9/2/06, Michael Walle <michael at walle.cc> wrote:
> Subject: Re: W83627DHG driver / Asus P5B [reference to [lm-sensors] Asus P5B Deluxe WiFi AP Sensors]
>
> Hi David,
>
> i'm also having a W83627DHG sensors chip with an ICH8 (non R) southbridge. (Asus
> P5B)
> Though i'm not subscribed to the lmsensors mailinglist, i would be pleased to
> help testing the driver.
> So if you need some information, don't hesitate to ask me.
>
> --
> Mit freundlichen Gr??en,
>  Michael Walle

On 9/2/06, Michael Nelson <michaelnel at comcast.net> wrote:
> On Fri, Sep 01, 2006 at 11:24:24PM -0700, David Hubbard wrote:
>
> > I'd be happy to add the support. If Michael wouldn't mind testing the
> > driver, we could get started.
>
> I'd be happy to.  Please advise when I can help in some way.
>
> Michael
>
> --
>
> San Francisco, CA

I will start referring to you by last name to avoid confusion.

Once we have the datasheet from Winbond, I can get started making
changes to the driver.

I will email you with requests for testing the driver.

Note to Michael Walle: by subscribing to the lm-sensors list, you will
know of further developments after the initial driver is finished. For
instance, a bug may be found months down the road, and the
announcement will appear on this list. Or, the driver will of course
be included in an upcoming kernel. Once there is a standard kernel
with the driver you want, you can continue to use it until newer
kernels bring you more updates.

Thanks,
David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

> > Given that these 3 last chips (W83627HF, W83627EHF and W83627DHG) are
> > Super-I/O chips and are detected again later using a  more reliable
> > method, I suggest we drop the legacy detection method for them. I've
> > already done so for the ITE family some weeks ago. Objection anyone?
> 
> No objections here.

Done. In fact I left W83627HF, as our w83781d driver still supports
that chip and uses the legacy ISA probing method. At some point, I
think we should drop W83627HF support from the w83781d driver entirely,
as this is redundant with the w83627hf driver, and then we can drop ISA
probing in sensors-detect too. I'd rather postpone that change to until
after the upcoming lm-sensors release though.

Thanks,
-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Yuan Mu]

Hi Jean,

Sorry i did not notice this mail :(

>>> Given that these 3 last chips (W83627HF, W83627EHF and W83627DHG) are
>>> Super-I/O chips and are detected again later using a  more reliable
>>> method, I suggest we drop the legacy detection method for them. I've
>>> already done so for the ITE family some weeks ago. Objection anyone?
>> No objections here.
> 
> Good.
> 
>>> This confirms my earlier guess. Good. As I said before, we don't have
>>> support right now, but support could be added to the w83627ehf driver
>>> with relatively little effort. You'll have to wait until this happens.
>> From the Winbond website
>> (http://www.winbond-usa.com/mambo/content/view/143/273/) there is one
>> less Vin, and some VID I/O.
> 
> Here are my own comparison notes of some says ago:
> 
> * 8-bit VID instead of 6-bit
> * No VIN4 (I don't know which one this is in the driver)
> * Additional critical limit for the 3 temperature sensors - part of the
>   automatic fan speed regulation interface
> 
> This was only after a quick glance, I could have overlooked something,
> but all in all adding support for that chip should be pretty
> straightforward.
> 
>> The datasheet is available by request
>> only. But if Yuan Mu could send a datasheet, I would greatly
>> appreciate it. In fact, Yuan, can you CC Jean on that? He will
>> probably need it too.
> 
> I do have it already, our Winbond partners were kind enough to share it
> with Rudolf Marek and me. But I cannot send it to you without the
> express agreement of Yuan Mu or another Winbond representative, as the
> datasheet is not public, as you found out yourself.
> 

It's great if David are willing to add dhg support, so i think you may share the datasheet with him.
Thanks!


>> I'd be happy to add the support. If Michael wouldn't mind testing the
>> driver, we could get started.
> 
> Yuan, I would have added support for the W83627DHG myself but it seems
> I am out of time. So I think we have a great opportunity if David does
> have the time to add support. Can I share the datasheet with him? He
> already contributed to our w83627ehf driver, I think we can trust him.
> 

Sorry i'm busy these days ... I trust him too :)


-- 
Best Regards
Yuan Mu


=============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi all,

I have received the datasheet and am reading it. Thanks to Yuan and
all at Winbond for supporting work on the linux driver.

I expect to email the lm-sensors list, Michael Walle and Michael
Nelson in a few days with a driver to test.

Thanks,
David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Tue, Sep 05, 2006 at 09:05:54AM -0600, David Hubbard wrote:

> I expect to email the lm-sensors list, Michael Walle and Michael
> Nelson in a few days with a driver to test.

Terrific!  Looking forward to testing it!

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hello again,

Here is a first shot at w83627dhg support. The datasheet files were
very helpful, especially the file that showed just the differences
between the EHF and DHG chips.

@Jean: Could you give me some feedback on the attached patch? Thanks!

@Michael Walle and Michael Nelson:

You can patch -p1 on a linux-2.6.18-rc4 kernel, or you can replace
/usr/src/linux/drivers/hwmon/w83627ehf.c with the attached
w83627ehf.c. The driver now prints a line as it detects your chip:

w83627ehf 9191-0290: detected W83627EHF/EHG (A1)

or

w83627ehf 9191-0290: detected W83627DHG (C1)

(You must turn on driver debug messages in your kernel config to see
this message.)

I have also attached w83627ehf_regression.sh, which should check that
your module loads and unloads correctly, verify that the sysfs files
have sane values, and runs the fans through their paces. Please at
least glance at the source of the script if you are thinking of
running it. :-)

The new driver works fine on my machine, and detects my chip
correctly. Please try it out and let me know how it goes.

Thanks,
David
-------------- next part --------------
Add support for w83627dhg.
Bug: driver may not currently be reading under-voltage alarm

diff -ur linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c
--- linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-05 22:38:38.000000000 -0700
+++ linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-05 23:17:54.000000000 -0700
@@ -34,6 +34,7 @@
 
     Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
     w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
+    w83627dhg    9      5       4       3       0xa0,0xc1  0x5ca3
 */
 
 #include <linux/module.h>
@@ -115,9 +116,42 @@
 
 #define W83627EHF_REG_BANK		0x4E
 #define W83627EHF_REG_CONFIG		0x40
-#define W83627EHF_REG_CHIP_ID		0x49
+#define W83627EHF_REG_CHIP_ID		0x58
 #define W83627EHF_REG_MAN_ID		0x4F
 
+/*
+ * Please remember when implementing more features that the following registers
+ * have different functions on the w83627ehf and w83627dhg. Registers may also
+ * have different power-on default values, but the BIOS has probably also set
+ * default values, so chip-specific differences are not important for that.
+ *
+ * ISA Register      Explanation of difference
+ * ----------------- -------------------------
+ *              0x49 DHG only: selects temp used for SmartFan AUX fan, CPU fan0
+ *              0x4a not completely documented on EHF, and DHG docs assign
+ *                   different behavior to bits 7 and 6. Also EHF might only
+ *                   select temp input for SmartFan III, DHG selects temp input
+ *                   in any SmartFan mode. Further EHF testing is required.
+ * 0x50-0x55, bank 0 EHF docs say "Test Reg," DHG docs say "Reserved Reg"
+ * 0x50-0x57, bank 6 EHF docs say "Test Reg," DHG docs say "Reserved Reg"
+ *      0x58, bank 0 Chip ID, of course. EHF: 0xa1. DHG: 0xc1
+ *      0x5e, bank 0 DHG only: enable bits for current mode for thermal diodes
+ *                   and critical temperature protection feature
+ *      0x50, bank 4 EHF only: bit 3, vin4 over limit
+ *      0x5b, bank 4 EHF only: bit 3, vin4 under limit
+ *      0x52, bank 5 EHF only: vin4 from A/D
+ *      0x58, bank 5 EHF only: vin4 high limit
+ *      0x59, bank 5 EHF only: vin4 low limit
+ *              0x6b DHG only: SYS fan critical temperature limit
+ *              0x6c DHG only: CPU fan0 critical temperature limit
+ *              0x6d DHG only: AUX fan critical temperature limit
+ *              0x6e DHG only: CPU fan1 critical temperature limit
+ *
+ * The w83627dhg supports Intel PECI and SST interfaces for new CPU's (e.g.
+ * Intel Core). DHG queries PECI interface on CPU to read temps, and ICH8
+ * chipset can read DHG temp data and drive fans. SST is a 1-wire serial bus.
+ */
+
 static const u16 W83627EHF_REG_FAN[] = { 0x28, 0x29, 0x2a, 0x3f, 0x553 };
 static const u16 W83627EHF_REG_FAN_MIN[] = { 0x3b, 0x3c, 0x3d, 0x3e, 0x55c };
 
@@ -252,6 +286,7 @@
 	u8 fan[5];
 	u8 fan_min[5];
 	u8 fan_div[5];
+	u8 num_in;		/* 10 VIN for ehf, 9 VIN for dhg */
 	u8 has_fan;		/* some fan inputs can be disabled */
 	s8 temp1;
 	s8 temp1_max;
@@ -425,7 +460,7 @@
 		}
 
 		/* Measured voltages and limits */
-		for (i = 0; i < 10; i++) {
+		for (i = 0; i < data->num_in; i++) {
 			data->in[i] = w83627ehf_read_value(client,
 				      W83627EHF_REG_IN(i));
 			data->in_min[i] = w83627ehf_read_value(client,
@@ -1214,7 +1249,23 @@
 	fan5pin = superio_inb(0x24) & 0x2;
 	fan4pin = superio_inb(0x29) & 0x6;
 	superio_exit();
-	
+
+	/* Detect w83627ehf (10 VIN) and w83627dhg (9 VIN) */
+	i = w83627ehf_read_value(client, W83627EHF_REG_CHIP_ID);
+	if (i = 0xa1) {	/* w83627ehf */
+		dev_dbg(dev, "detected W83627EHF/EHG (A1)\n");
+		data->num_in = 10;
+	}
+	else if (i = 0xc1) {	/* w83627dhg */
+		dev_dbg(dev, "detected W83627DHG (C1)\n");
+		data->num_in = 9;
+	}
+	else {
+		dev_err(dev, "unknown CHIP_ID (0x%02x)\n", i);
+		err = -ENODEV;
+		goto exit_remove;
+	}
+
 	/* It looks like fan4 and fan5 pins can be alternatively used
 	   as fan on/off switches */
 	
@@ -1238,7 +1289,7 @@
 				goto exit_remove;
 		}
 
-	for (i = 0; i < 10; i++)
+	for (i = 0; i < data->num_in; i++)
 		if ((err = device_create_file(dev, &sda_in_input[i].dev_attr))
 			|| (err = device_create_file(dev,
 				&sda_in_alarm[i].dev_attr))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83627ehf.c
Type: application/octet-stream
Size: 46305 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060905/b016fd6d/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83627ehf_regression.sh
Type: application/x-sh
Size: 16291 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060905/b016fd6d/attachment-0001.sh 

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

The attachments seem to have all been base64-encoded. Apologies, still
working on that.

David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Tue, Sep 05, 2006 at 10:31:41PM -0700, David Hubbard wrote:

> The new driver works fine on my machine, and detects my chip
> correctly. Please try it out and let me know how it goes.

I tried it, and although the 2.6.18-rc4 kernel and modules compiled OK, the
kernel segfaults and dies during boot (well before any lm-sensors stuff
happens).  I am looking into that now.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Wed, Sep 06, 2006 at 05:15:09AM -0700, Michael Nelson wrote:

> I tried it, and although the 2.6.18-rc4 kernel and modules compiled OK, the
> kernel segfaults and dies during boot (well before any lm-sensors stuff
> happens).  I am looking into that now.

I have tried recompiling the kernel & modules several times now, with less
and less stuff being included in the .config... but the kernel still
segfaults just before trying to load the jbd and ext3 modules.  

Honestly, for the past few years I have been using production, rpm-based
kernels, and although years ago I used to build every kernel that came out,
I am way out of practice.

I am not sure how to troubleshoot this.  The segfault and associated error
messages happens pretty early in the kernel load, after scsi and ata drivers
are loaded... but then it scrolls almost all the way off screen and I can't
see what the beginning of the error was.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi Michael,

> On Wed, Sep 06, 2006 at 05:15:09AM -0700, Michael Nelson wrote:
> 
> > I tried it, and although the 2.6.18-rc4 kernel and modules compiled OK, the
> > kernel segfaults and dies during boot (well before any lm-sensors stuff
> > happens).  I am looking into that now.
> 
> I have tried recompiling the kernel & modules several times now, with less
> and less stuff being included in the .config... but the kernel still
> segfaults just before trying to load the jbd and ext3 modules.  
> 
> Honestly, for the past few years I have been using production, rpm-based
> kernels, and although years ago I used to build every kernel that came out,
> I am way out of practice.
> 
> I am not sure how to troubleshoot this.  The segfault and associated error
> messages happens pretty early in the kernel load, after scsi and ata drivers
> are loaded... but then it scrolls almost all the way off screen and I can't
> see what the beginning of the error was.

You should start with a self-compiled 2.6.17.11 kernel first. If it
works, try 2.6.18-rc6. It's a bit odd to try -rc4 when -rc6 is already
there. The problem you are hitting may have been fixed already.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Wed, Sep 06, 2006 at 04:03:37PM +0200, Jean Delvare wrote:

> You should start with a self-compiled 2.6.17.11 kernel first. If it
> works, try 2.6.18-rc6. It's a bit odd to try -rc4 when -rc6 is already
> there. The problem you are hitting may have been fixed already.

Hmmm.  I tried the 2.6.18-rc4 because that is the one the patch is against.
I will grab the -rc6 and see if that works.

The stock Suse kernel that works fine but without support for my chip is
2.6.16.21-0.13-smp.  I have not tried the 2.6.17.11 kernel at all.

I doubt I will get much more done on this this morning, as I have to leave
for work soon.

Thanks for the help.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Wed, Sep 06, 2006 at 07:07:49AM -0700, Michael Nelson wrote:

> Hmmm.  I tried the 2.6.18-rc4 because that is the one the patch is against.
> I will grab the -rc6 and see if that works.

The patch fails to apply on rc6:

File to patch: linux/drivers/hwmon/w83627ehf.c
patching file linux/drivers/hwmon/w83627ehf.c
Hunk #1 FAILED at 34.
Hunk #2 succeeded at 113 (offset -3 lines).
Hunk #3 succeeded at 249 (offset -37 lines).
Hunk #4 succeeded at 412 (offset -48 lines).
Hunk #5 FAILED at 1201.
Hunk #6 FAILED at 1241.
3 out of 6 hunks FAILED -- saving rejects to file
linux/drivers/hwmon/w83627ehf.c.rej

I don't think I can hand apply this patch to either the suse 2.6.16 source
or this rc6... I am over my head here, folks, sorry.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

> On Wed, Sep 06, 2006 at 07:07:49AM -0700, Michael Nelson wrote:
> 
> > Hmmm.  I tried the 2.6.18-rc4 because that is the one the patch is against.
> > I will grab the -rc6 and see if that works.
> 
> The patch fails to apply on rc6:
> 
> File to patch: linux/drivers/hwmon/w83627ehf.c
> patching file linux/drivers/hwmon/w83627ehf.c
> Hunk #1 FAILED at 34.
> Hunk #2 succeeded at 113 (offset -3 lines).
> Hunk #3 succeeded at 249 (offset -37 lines).
> Hunk #4 succeeded at 412 (offset -48 lines).
> Hunk #5 FAILED at 1201.
> Hunk #6 FAILED at 1241.
> 3 out of 6 hunks FAILED -- saving rejects to file
> linux/drivers/hwmon/w83627ehf.c.rej

The file drivers/hwmon/w83627ehf.c did not change between rc4 and rc6,
so if the patch applied to rc4 it should apply fine to rc6 as well. I
guess you messed up somewhere... Please retry.

> I don't think I can hand apply this patch to either the suse 2.6.16 source
> or this rc6... I am over my head here, folks, sorry.

I confirm it won't work on Suse's 2.6.16, as the driver had a big
update in 2.6.17 and once more in 2.6.18-rc1.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Wed, Sep 06, 2006 at 07:26:50AM -0700, Michael Nelson wrote:

I got the 2.6.18-rc6 kernel to build and boot.  Now to see if I can get that
patch to apply.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Wed, Sep 06, 2006 at 08:07:24AM -0700, Michael Nelson wrote:
> On Wed, Sep 06, 2006 at 07:26:50AM -0700, Michael Nelson wrote:
> 
> I got the 2.6.18-rc6 kernel to build and boot.  Now to see if I can get that
> patch to apply.

I dropped the w83627ehf.c file into the
/usr/src/linux-2.6.18-rc6/drivers/hwmon directory and rebuilt kernel and
modules. It built fine, but after reboot it fails to load:

# sh /home/michaeln/w83627ehf_regression.sh
* WARNING: This will run your system fans through many possible
           combinations. There is a possibility your system will
           overheat. Use this script at your own risk!
No w83627ehf driver in system. Loading module.
FATAL: Error inserting w83627ehf
(/lib/modules/2.6.18-rc6-smp/kernel/drivers/hwmon/w83627ehf.ko): No such
device

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

I just realized that the patch I sent is against the newest w83627ehf
driver, which is not in the kernel yet. However, the .c file includes
all the patches. Please use that file.

The "No such device" error is probably here in the source code:
		dev_err(dev, "unknown CHIP_ID (0x%02x)\n", i);
		err = -ENODEV;
		goto exit_remove;

This error occurs if the chip is not recognized in w83627ehf_detect():

	/* Detect w83627ehf (10 VIN) and w83627dhg (9 VIN) */
	i = w83627ehf_read_value(client, W83627EHF_REG_CHIP_ID);
	if (i = 0xa1) {	/* w83627ehf */
		dev_dbg(dev, "detected W83627EHF/EHG (A1)\n");
		data->num_in = 10;
	}
	else if (i = 0xc1) {	/* w83627dhg */
		dev_dbg(dev, "detected W83627DHG (C1)\n");
		data->num_in = 9;
	}
	else {
		dev_err(dev, "unknown CHIP_ID (0x%02x)\n", i);
		err = -ENODEV;
		goto exit_remove;
	}

You should see the "unknown CHIP_ID" message in dmesg. You may need to
turn on driver debug messages, although I thought dev_err() will show
up in dmesg even with them off.

Can you please send the output of "lspci -n"?

Thanks,
David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Wed, Sep 06, 2006 at 12:08:33PM -0600, David Hubbard wrote:
> I just realized that the patch I sent is against the newest w83627ehf
> driver, which is not in the kernel yet. However, the .c file includes
> all the patches. Please use that file.

That's what I used.

> Can you please send the output of "lspci -n"?

:~$  /sbin/lspci -n
00:00.0 Class 0600: 8086:29a0 (rev 02)
00:01.0 Class 0604: 8086:29a1 (rev 02)
00:1a.0 Class 0c03: 8086:2834 (rev 02)
00:1a.1 Class 0c03: 8086:2835 (rev 02)
00:1a.7 Class 0c03: 8086:283a (rev 02)
00:1b.0 Class 0403: 8086:284b (rev 02)
00:1c.0 Class 0604: 8086:283f (rev 02)
00:1c.4 Class 0604: 8086:2847 (rev 02)
00:1c.5 Class 0604: 8086:2849 (rev 02)
00:1d.0 Class 0c03: 8086:2830 (rev 02)
00:1d.1 Class 0c03: 8086:2831 (rev 02)
00:1d.2 Class 0c03: 8086:2832 (rev 02)
00:1d.7 Class 0c03: 8086:2836 (rev 02)
00:1e.0 Class 0604: 8086:244e (rev f2)
00:1f.0 Class 0601: 8086:2810 (rev 02)
00:1f.2 Class 0106: 8086:2821 (rev 02)
00:1f.3 Class 0c05: 8086:283e (rev 02)
01:00.0 Class 0300: 10de:0391 (rev a1)
02:00.0 Class 0200: 11ab:4364 (rev 12)
03:00.0 Class 0106: 197b:2363 (rev 02)
03:00.1 Class 0101: 197b:2363 (rev 02)
05:02.0 Class 0100: 9005:0080 (rev 02)
05:03.0 Class 0c00: 104c:8023
05:04.0 Class 0200: 11ab:4320 (rev 13)

Thanks.  I'm at work now, will work with it some more tonight.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi David,

> The "No such device" error is probably here in the source code:
> 		dev_err(dev, "unknown CHIP_ID (0x%02x)\n", i);
> 		err = -ENODEV;
> 		goto exit_remove;
> 
> This error occurs if the chip is not recognized in w83627ehf_detect():
> 
> 	/* Detect w83627ehf (10 VIN) and w83627dhg (9 VIN) */
> 	i = w83627ehf_read_value(client, W83627EHF_REG_CHIP_ID);
> 	if (i = 0xa1) {	/* w83627ehf */
> 		dev_dbg(dev, "detected W83627EHF/EHG (A1)\n");
> 		data->num_in = 10;
> 	}
> 	else if (i = 0xc1) {	/* w83627dhg */
> 		dev_dbg(dev, "detected W83627DHG (C1)\n");
> 		data->num_in = 9;
> 	}
> 	else {
> 		dev_err(dev, "unknown CHIP_ID (0x%02x)\n", i);
> 		err = -ENODEV;
> 		goto exit_remove;
> 	}

No, actually the error occurs before that. You didn't add the Super-I/O
ID of the W83627DHG in w83627ehf_find, so that function will return
-ENODEV.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi David,

> Here is a first shot at w83627dhg support. The datasheet files were
> very helpful, especially the file that showed just the differences
> between the EHF and DHG chips.
> 
> @Jean: Could you give me some feedback on the attached patch? Thanks!

Here you go:

> diff -ur linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c
> --- linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-05 22:38:38.000000000 -0700
> +++ linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-05 23:17:54.000000000 -0700
> @@ -34,6 +34,7 @@
>  
>      Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
>      w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
> +    w83627dhg    9      5       4       3       0xa0,0xc1  0x5ca3

Where does the "0xa0" comes from? I only see 0xC1 in the datasheet.

>  */
>  
>  #include <linux/module.h>
> @@ -115,9 +116,42 @@
>  
>  #define W83627EHF_REG_BANK		0x4E
>  #define W83627EHF_REG_CONFIG		0x40
> -#define W83627EHF_REG_CHIP_ID		0x49
> +#define W83627EHF_REG_CHIP_ID		0x58
>  #define W83627EHF_REG_MAN_ID		0x4F

Good catch.

>  
> +/*
> + * Please remember when implementing more features that the following registers
> + * have different functions on the w83627ehf and w83627dhg. Registers may also
> + * have different power-on default values, but the BIOS has probably also set
> + * default values, so chip-specific differences are not important for that.
> + *
> + * ISA Register      Explanation of difference
> + * ----------------- -------------------------
> + *              0x49 DHG only: selects temp used for SmartFan AUX fan, CPU fan0
> + *              0x4a not completely documented on EHF, and DHG docs assign
> + *                   different behavior to bits 7 and 6. Also EHF might only
> + *                   select temp input for SmartFan III, DHG selects temp input
> + *                   in any SmartFan mode. Further EHF testing is required.
> + * 0x50-0x55, bank 0 EHF docs say "Test Reg," DHG docs say "Reserved Reg"
> + * 0x50-0x57, bank 6 EHF docs say "Test Reg," DHG docs say "Reserved Reg"

"Test Reg" and "Reserved Reg" is really the same, not worth documenting.

> + *      0x58, bank 0 Chip ID, of course. EHF: 0xa1. DHG: 0xc1
> + *      0x5e, bank 0 DHG only: enable bits for current mode for thermal diodes
> + *                   and critical temperature protection feature
> + *      0x50, bank 4 EHF only: bit 3, vin4 over limit
> + *      0x5b, bank 4 EHF only: bit 3, vin4 under limit
> + *      0x52, bank 5 EHF only: vin4 from A/D
> + *      0x58, bank 5 EHF only: vin4 high limit
> + *      0x59, bank 5 EHF only: vin4 low limit
> + *              0x6b DHG only: SYS fan critical temperature limit
> + *              0x6c DHG only: CPU fan0 critical temperature limit
> + *              0x6d DHG only: AUX fan critical temperature limit
> + *              0x6e DHG only: CPU fan1 critical temperature limit
> + *
> + * The w83627dhg supports Intel PECI and SST interfaces for new CPU's (e.g.
> + * Intel Core). DHG queries PECI interface on CPU to read temps, and ICH8
> + * chipset can read DHG temp data and drive fans. SST is a 1-wire serial bus.
> + */

That's interesting documentation, but I'd move it to
Documentation/hwmon/w83627ehf. Also I think you can be more concise at
times, for example "DHG has no in9" summarizes 5 lines above. The
datasheet is there for the details, what we want in the documentation
is a summary of the differences that matter to us.

> +
>  static const u16 W83627EHF_REG_FAN[] = { 0x28, 0x29, 0x2a, 0x3f, 0x553 };
>  static const u16 W83627EHF_REG_FAN_MIN[] = { 0x3b, 0x3c, 0x3d, 0x3e, 0x55c };
>  
> @@ -252,6 +286,7 @@
>  	u8 fan[5];
>  	u8 fan_min[5];
>  	u8 fan_div[5];
> +	u8 num_in;		/* 10 VIN for ehf, 9 VIN for dhg */
>  	u8 has_fan;		/* some fan inputs can be disabled */
>  	s8 temp1;
>  	s8 temp1_max;
> @@ -425,7 +460,7 @@
>  		}
>  
>  		/* Measured voltages and limits */
> -		for (i = 0; i < 10; i++) {
> +		for (i = 0; i < data->num_in; i++) {
>  			data->in[i] = w83627ehf_read_value(client,
>  				      W83627EHF_REG_IN(i));
>  			data->in_min[i] = w83627ehf_read_value(client,
> @@ -1214,7 +1249,23 @@
>  	fan5pin = superio_inb(0x24) & 0x2;
>  	fan4pin = superio_inb(0x29) & 0x6;
>  	superio_exit();
> -	
> +
> +	/* Detect w83627ehf (10 VIN) and w83627dhg (9 VIN) */
> +	i = w83627ehf_read_value(client, W83627EHF_REG_CHIP_ID);
> +	if (i = 0xa1) {	/* w83627ehf */
> +		dev_dbg(dev, "detected W83627EHF/EHG (A1)\n");
> +		data->num_in = 10;
> +	}
> +	else if (i = 0xc1) {	/* w83627dhg */
> +		dev_dbg(dev, "detected W83627DHG (C1)\n");
> +		data->num_in = 9;
> +	}

A1 and C1 are really only arbitrary hexadecimal numbers, I see little
benefit in exporting them to userspace.

> +	else {
> +		dev_err(dev, "unknown CHIP_ID (0x%02x)\n", i);

I'd make it a warning rather than an error. Nothing really bad happened.

> +		err = -ENODEV;
> +		goto exit_remove;
> +	}

A switch/case might look better.

> +
>  	/* It looks like fan4 and fan5 pins can be alternatively used
>  	   as fan on/off switches */
>  	
> @@ -1238,7 +1289,7 @@
>  				goto exit_remove;
>  		}
>  
> -	for (i = 0; i < 10; i++)
> +	for (i = 0; i < data->num_in; i++)
>  		if ((err = device_create_file(dev, &sda_in_input[i].dev_attr))
>  			|| (err = device_create_file(dev,
>  				&sda_in_alarm[i].dev_attr))

You don't use data->num for file removal... I agree it'll work
(removing a non-existing file isn't an error) but given that you have
the value available, using it looks both more logical and more
efficient.

Super-I/O detection of the W83627DHG is missing, so the patch won't
work, as I pointed out in a previous post already. Just add that and
your patch should work fine.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi all,

On 9/6/06, Jean Delvare <khali at linux-fr.org> wrote:
> No, actually the error occurs before that. You didn't add the Super-I/O
> ID of the W83627DHG in w83627ehf_find, so that function will return
> -ENODEV.

I'll make the changes when I get home and send out an updated patch &
w83627ehf.c tonight. Thanks for the feedback.

David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Walle]

David Hubbard <david.c.hubbard at gmail.com> schrieb am Wed, Sep 06, 2006 at 03:42:08PM -0600:
> Hi all,
> 
> On 9/6/06, Jean Delvare <khali at linux-fr.org> wrote:
> >No, actually the error occurs before that. You didn't add the Super-I/O
> >ID of the W83627DHG in w83627ehf_find, so that function will return
> >-ENODEV.
> 
> I'll make the changes when I get home and send out an updated patch &
> w83627ehf.c tonight. Thanks for the feedback.

Hi,

With the correct SuperIO ID and mask (0xa020/0xfff0) the driver seems to work
here on:
  Linux thanatos 2.6.17.7-mh1 #16 SMP PREEMPT Thu Sep 7 00:21:21 CEST 2006
  i686 Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz GNU/Linux

But fan5_input (my second case fan) jumps between 0 and something around
30000 RPM.
If I slow down my other case fan by hand (fan1), I'll get wrong values, too
(around 12000k).

Also the fan?_min have some strange values:
  thanatos device # cat fan?_min
  10546
  2960
  10546
  10546
  337500


-- 
Sincerly,
 Michael Walle

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Thu, Sep 07, 2006 at 01:02:07AM +0200, Michael Walle wrote:

> With the correct SuperIO ID and mask (0xa020/0xfff0) the driver seems to work
> here on:
>   Linux thanatos 2.6.17.7-mh1 #16 SMP PREEMPT Thu Sep 7 00:21:21 CEST 2006
>   i686 Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz GNU/Linux

Cool!  That's the same processor I'm running on my board.  Hopefully it'll
work on mine too.

Michael 

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi all,

I have attached an updated patch (it now includes changes to
drivers/hwmon/w83627ehf.c and a new Documentation/hwmon/w83627ehf
file), plus w83627ehf.c. Michael and Michael, please try out the new
driver. No changes to w83627ehf_regression.sh.

> >      Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
> >      w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
> > +    w83627dhg    9      5       4       3       0xa0,0xc1  0x5ca3
>
> Where does the "0xa0" comes from? I only see 0xC1 in the datasheet.

For an EHF CR[0x20] = 0x88, and for a DHG CR[0x20] = 0xa0. Thanks to
Michael Walle for catching this:

> With the correct SuperIO ID and mask (0xa020/0xfff0)
> the driver seems to work here

It's in the new patch, please comment :-)

> "Test Reg" and "Reserved Reg" is really the same, not worth documenting.

OK

> That's interesting documentation, but I'd move it to
> Documentation/hwmon/w83627ehf. Also I think you can be more concise at
> times, for example "DHG has no in9" summarizes 5 lines above. The
> datasheet is there for the details, what we want in the documentation
> is a summary of the differences that matter to us.

Done, added new file Documentation/hwmon/w83627ehf. By the way, I used
the w83627hf documentation as a template, and it has this link in it:
http://www2.lm-sensors.nu/~lm78/cvs/browse.cgi/lm_sensors2/doc/vid

Does that link need to be updated?

> A1 and C1 are really only arbitrary hexadecimal numbers, I see little
> benefit in exporting them to userspace.
>
> I'd make it a warning rather than an error. Nothing really bad happened.
>
> A switch/case might look better.

OK

> You don't use data->num for file removal... I agree it'll work
> (removing a non-existing file isn't an error) but given that you have
> the value available, using it looks both more logical and more
> efficient.

OK

David
-------------- next part --------------
Add support for w83627dhg.
Add Documentation/hwmon/w83627ehf
Bug: driver may not currently be reading under-voltage alarm

diff -ur linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c
--- linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-05 22:38:38.000000000 -0700
+++ linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-07 00:16:48.000000000 -0700
@@ -32,8 +32,9 @@
 
     Supports the following chips:
 
-    Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
-    w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
+    Chip        #vin    #fan    #pwm    #temp  sio_ID & 0xfff0 chip_id mfg_id
+    w83627ehf   10      5       4       3      0x8860          0xa1    0x5ca3
+    w83627dhg    9      5       4       3      0xa020          0xc1    0x5ca3
 */
 
 #include <linux/module.h>
@@ -65,8 +66,9 @@
 #define SIO_REG_ENABLE		0x30	/* Logical device enable */
 #define SIO_REG_ADDR		0x60	/* Logical device address (2 bytes) */
 
-#define SIO_W83627EHF_ID	0x8840
-#define SIO_ID_MASK		0xFFC0
+#define SIO_W83627EHF_ID	0x8860
+#define SIO_W83627DHG_ID	0xa020
+#define SIO_ID_MASK		0xFFF0
 
 static inline void
 superio_outb(int reg, int val)
@@ -115,7 +117,7 @@
 
 #define W83627EHF_REG_BANK		0x4E
 #define W83627EHF_REG_CONFIG		0x40
-#define W83627EHF_REG_CHIP_ID		0x49
+#define W83627EHF_REG_CHIP_ID		0x58
 #define W83627EHF_REG_MAN_ID		0x4F
 
 static const u16 W83627EHF_REG_FAN[] = { 0x28, 0x29, 0x2a, 0x3f, 0x553 };
@@ -252,6 +254,7 @@
 	u8 fan[5];
 	u8 fan_min[5];
 	u8 fan_div[5];
+	u8 num_in;		/* 10 VIN for ehf, 9 VIN for dhg */
 	u8 has_fan;		/* some fan inputs can be disabled */
 	s8 temp1;
 	s8 temp1_max;
@@ -425,7 +428,7 @@
 		}
 
 		/* Measured voltages and limits */
-		for (i = 0; i < 10; i++) {
+		for (i = 0; i < data->num_in; i++) {
 			data->in[i] = w83627ehf_read_value(client,
 				      W83627EHF_REG_IN(i));
 			data->in_min[i] = w83627ehf_read_value(client,
@@ -1107,7 +1110,8 @@
  * Driver and client management
  */
 
-static void w83627ehf_device_remove_files(struct device *dev)
+static void w83627ehf_device_remove_files(struct device *dev,
+					  struct w83627ehf_data *data)
 {
 	/* some entries in the following arrays may not have been used in
 	 * device_create_file(), but device_remove_file() will ignore them */
@@ -1117,7 +1121,7 @@
 		device_remove_file(dev, &sda_sf3_arrays[i].dev_attr);
 	for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan4); i++)
 		device_remove_file(dev, &sda_sf3_arrays_fan4[i].dev_attr);
-	for (i = 0; i < 10; i++) {
+	for (i = 0; i < data->num_in; i++) {
 		device_remove_file(dev, &sda_in_input[i].dev_attr);
 		device_remove_file(dev, &sda_in_alarm[i].dev_attr);
 		device_remove_file(dev, &sda_in_min[i].dev_attr);
@@ -1215,6 +1219,23 @@
 	fan4pin = superio_inb(0x29) & 0x6;
 	superio_exit();
 	
+	/* Detect w83627ehf (10 VIN) and w83627dhg (9 VIN) */
+	i = w83627ehf_read_value(client, W83627EHF_REG_CHIP_ID);
+	switch (i) {
+	case 0xa1:	/* w83627ehf */
+		dev_dbg(dev, "detected W83627EHF/EHG\n");
+		data->num_in = 10;
+		break;
+	case 0xc1:	/* w83627dhg */
+		dev_dbg(dev, "detected W83627DHG\n");
+		data->num_in = 9;
+		break;
+	default:
+		dev_warn(dev, "unknown CHIP_ID (0x%02x), 9 VIN only.\n", i);
+		data->num_in = 9;
+		break;
+	}
+
 	/* It looks like fan4 and fan5 pins can be alternatively used
 	   as fan on/off switches */
 	
@@ -1238,7 +1259,7 @@
 				goto exit_remove;
 		}
 
-	for (i = 0; i < 10; i++)
+	for (i = 0; i < data->num_in; i++)
 		if ((err = device_create_file(dev, &sda_in_input[i].dev_attr))
 			|| (err = device_create_file(dev,
 				&sda_in_alarm[i].dev_attr))
@@ -1288,7 +1309,7 @@
 	return 0;
 
 exit_remove:
-	w83627ehf_device_remove_files(dev);
+	w83627ehf_device_remove_files(dev, data);
 	i2c_detach_client(client);
 exit_free:
 	kfree(data);
@@ -1303,7 +1324,7 @@
 	struct w83627ehf_data *data = i2c_get_clientdata(client);
 	int err;
 
-	w83627ehf_device_remove_files(&client->dev);
+	w83627ehf_device_remove_files(&client->dev, data);
 	hwmon_device_unregister(data->class_dev);
 
 	if ((err = i2c_detach_client(client)))
@@ -1332,7 +1353,13 @@
 
 	val = (superio_inb(SIO_REG_DEVID) << 8)
 	    | superio_inb(SIO_REG_DEVID + 1);
-	if ((val & SIO_ID_MASK) != SIO_W83627EHF_ID) {
+	switch (val & SIO_ID_MASK) {
+	case SIO_W83627EHF_ID:
+	case SIO_W83627DHG_ID:
+		break;
+	default:
+		printk(KERN_DEBUG "w83627ehf: unknown SuperIO ID: "
+			"0x%04x & 0x%04x\n", val, SIO_ID_MASK);
 		superio_exit();
 		return -ENODEV;
 	}
--- linux-2.6.18-rc4/Documentation/hwmon/w83627ehf	2006-09-07 00:15:30.000000000 -0700
+++ linux-2.6.18-rc4/Documentation/hwmon/w83627ehf	2006-09-07 00:15:07.000000000 -0700
@@ -0,0 +1,62 @@
+Kernel driver w83627ehf
+===========+
+Supported chips:
+  * Winbond W83627EHF and W83627EHG (lead-free version)
+    Addresses scanned: ISA address retrieved from Super I/O registers
+  * Winbond W83627DHG
+    Addresses scanned: ISA address retrieved from Super I/O registers
+
+Authors:
+        Jean Delvare <khali at linux-fr.org>
+        Yuan Mu <Ymu at Winbond.com.tw>,
+        Rudolf Marek <r.marek at sh.cvut.cz>
+        David Hubbard <david.c.hubbard at gmail.com>
+
+Module Parameters
+-----------------
+
+Currently none.
+
+Description
+-----------
+
+This driver implements support for the W83627EHF, W83627EHG, and W83627DHG
+Super I/O chips.
+
+For further information on this driver see the lm-sensors Wiki at
+http://www.lm-sensors.org/wiki
+
+Please remember when implementing more features that the following registers
+have different functions on the w83627ehf and w83627dhg. Registers may also
+have different power-on default values, but the BIOS has probably also set
+default values, so chip-specific differences are not important for that.
+
+ISA Register      Explanation of difference
+----------------- -------------------------
+             0x49 DHG only: selects temp used for SmartFan AUX fan, CPU fan0
+
+             0x4a not completely documented on EHF, and DHG docs assign
+                  different behavior to bits 7 and 6. Also EHF might only
+                  select temp input for SmartFan III, DHG selects temp input
+                  in any SmartFan mode. Further EHF testing is required.
+
+     0x58, bank 0 Chip ID, of course. EHF: 0xa1. DHG: 0xc1
+
+     0x5e, bank 0 DHG only: enable bits for current mode for thermal diodes
+                  and critical temperature protection feature
+
+     0x50, bank 4, bit 3, 0x5b, bank 4, bit 3, 0x52, bank 5, 0x58, bank 5, and
+     0x59, bank 5 EHF only: DHG has no in9 (vin4)
+
+             0x6b DHG only: SYS fan critical temperature limit
+
+             0x6c DHG only: CPU fan0 critical temperature limit
+
+             0x6d DHG only: AUX fan critical temperature limit
+
+             0x6e DHG only: CPU fan1 critical temperature limit
+
+The W83627DHG supports Intel PECI and SST interfaces for new CPU's (e.g.
+Intel Core). DHG queries PECI interface on CPU to read temps, and ICH8
+chipset can read DHG temp data and drive fans. SST is a 1-wire serial bus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83627ehf.c
Type: application/octet-stream
Size: 44681 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060906/b139bc4d/attachment-0001.obj 

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

David,

> I have attached an updated patch (it now includes changes to
> drivers/hwmon/w83627ehf.c and a new Documentation/hwmon/w83627ehf
> file), plus w83627ehf.c. Michael and Michael, please try out the new
> driver. No changes to w83627ehf_regression.sh.
> 
> > >      Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
> > >      w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
> > > +    w83627dhg    9      5       4       3       0xa0,0xc1  0x5ca3
> >
> > Where does the "0xa0" comes from? I only see 0xC1 in the datasheet.
> 
> For an EHF CR[0x20] = 0x88, and for a DHG CR[0x20] = 0xa0. Thanks to
> Michael Walle for catching this:

You're mixing two different things here. The CR[0x20] references the
Super-I/O configuration space, while the value documented above is for
register 0x58 in the device's own I/O space. Early W83627EHF were seen
with chip ID 0x88 in register 0x58, newer ones with 0xA1 (as documented
in the datasheet) which is why we listed both values above. It happens
that 0x88 is also the value of the Super-I/O's CR[0x20] for the
W83627EHF/EHG, but this isn't what we attempted to document above.

See this thread for the full story:
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-February/010542.html

> Done, added new file Documentation/hwmon/w83627ehf. By the way, I used
> the w83627hf documentation as a template, and it has this link in it:
> http://www2.lm-sensors.nu/~lm78/cvs/browse.cgi/lm_sensors2/doc/vid
> 
> Does that link need to be updated?

Yes, and so do the 5 other references to the old site in the linux 2.6
tree. And the 84 references in the lm-sensors SVN tree, and the 6
references in the i2c SVN tree, and the 3 references in the linux 2.4
tree. I expected the people who organized the site migration to provide
patches to update all the links, but it did not happen (yet.)

> Add support for w83627dhg.
> Add Documentation/hwmon/w83627ehf

Huu, we already have this documentation file in -mm. It was contributed
by Rudolf Marek some weeks ago.

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-i2c/hwmon-w83627ehf-documentation.patch

Please improve it rather than creating your own from scratch.

> Bug: driver may not currently be reading under-voltage alarm

Can you give some details about that? Is is W83627DHG-specific, or an
older bug?

> diff -ur linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c
> --- linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-05 22:38:38.000000000 -0700
> +++ linux-2.6.18-rc4/drivers/hwmon/w83627ehf.c	2006-09-07 00:16:48.000000000 -0700
> @@ -32,8 +32,9 @@
>  
>      Supports the following chips:
>  
> -    Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
> -    w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
> +    Chip        #vin    #fan    #pwm    #temp  sio_ID & 0xfff0 chip_id mfg_id
> +    w83627ehf   10      5       4       3      0x8860          0xa1    0x5ca3
> +    w83627dhg    9      5       4       3      0xa020          0xc1    0x5ca3
>  */

As explained above, chip_id may also be 0x88 for early W83627EHFs.

I also note that our sensors-detect script was looking for chip_id =
0xa2 for the W83627DHG. Don't know where this value comes from. Rudolf?

>  
>  #include <linux/module.h>
> @@ -65,8 +66,9 @@
>  #define SIO_REG_ENABLE		0x30	/* Logical device enable */
>  #define SIO_REG_ADDR		0x60	/* Logical device address (2 bytes) */
>  
> -#define SIO_W83627EHF_ID	0x8840
> -#define SIO_ID_MASK		0xFFC0
> +#define SIO_W83627EHF_ID	0x8860
> +#define SIO_W83627DHG_ID	0xa020
> +#define SIO_ID_MASK		0xFFF0

You'll break support of older W83627EHF chips if you do that. Quote
from sensors-detect:

	# W83627EHF datasheet says 0x886x but 0x8853 was seen, thus the
	# broader mask. W83627EHG was seen with ID 0x8863.

This is probably the same chip which had chip_id = 0x88, BTW. If you
really want 0xFFF0 as the mask, please define SIO_W83627EHF_ALT_ID or
something similar for the older chips.

>  
>  static inline void
>  superio_outb(int reg, int val)
> @@ -115,7 +117,7 @@
>  
>  #define W83627EHF_REG_BANK		0x4E
>  #define W83627EHF_REG_CONFIG		0x40
> -#define W83627EHF_REG_CHIP_ID		0x49
> +#define W83627EHF_REG_CHIP_ID		0x58
>  #define W83627EHF_REG_MAN_ID		0x4F
>  
>  static const u16 W83627EHF_REG_FAN[] = { 0x28, 0x29, 0x2a, 0x3f, 0x553 };
> @@ -252,6 +254,7 @@
>  	u8 fan[5];
>  	u8 fan_min[5];
>  	u8 fan_div[5];
> +	u8 num_in;		/* 10 VIN for ehf, 9 VIN for dhg */
>  	u8 has_fan;		/* some fan inputs can be disabled */
>  	s8 temp1;
>  	s8 temp1_max;
> @@ -425,7 +428,7 @@
>  		}
>  
>  		/* Measured voltages and limits */
> -		for (i = 0; i < 10; i++) {
> +		for (i = 0; i < data->num_in; i++) {
>  			data->in[i] = w83627ehf_read_value(client,
>  				      W83627EHF_REG_IN(i));
>  			data->in_min[i] = w83627ehf_read_value(client,
> @@ -1107,7 +1110,8 @@
>   * Driver and client management
>   */
>  
> -static void w83627ehf_device_remove_files(struct device *dev)
> +static void w83627ehf_device_remove_files(struct device *dev,
> +					  struct w83627ehf_data *data)
>  {
>  	/* some entries in the following arrays may not have been used in
>  	 * device_create_file(), but device_remove_file() will ignore them */
> @@ -1117,7 +1121,7 @@
>  		device_remove_file(dev, &sda_sf3_arrays[i].dev_attr);
>  	for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan4); i++)
>  		device_remove_file(dev, &sda_sf3_arrays_fan4[i].dev_attr);
> -	for (i = 0; i < 10; i++) {
> +	for (i = 0; i < data->num_in; i++) {
>  		device_remove_file(dev, &sda_in_input[i].dev_attr);
>  		device_remove_file(dev, &sda_in_alarm[i].dev_attr);
>  		device_remove_file(dev, &sda_in_min[i].dev_attr);
> @@ -1215,6 +1219,23 @@
>  	fan4pin = superio_inb(0x29) & 0x6;
>  	superio_exit();
>  	
> +	/* Detect w83627ehf (10 VIN) and w83627dhg (9 VIN) */
> +	i = w83627ehf_read_value(client, W83627EHF_REG_CHIP_ID);
> +	switch (i) {
> +	case 0xa1:	/* w83627ehf */

Add 0x88.

> +		dev_dbg(dev, "detected W83627EHF/EHG\n");
> +		data->num_in = 10;
> +		break;
> +	case 0xc1:	/* w83627dhg */
> +		dev_dbg(dev, "detected W83627DHG\n");
> +		data->num_in = 9;
> +		break;
> +	default:
> +		dev_warn(dev, "unknown CHIP_ID (0x%02x), 9 VIN only.\n", i);
> +		data->num_in = 9;
> +		break;
> +	}
> +

Maybe you could do that detection before giving the i2c client its
name? I guess we want w83627dhg to appear as such, so that userspace
knows which chip is there. If nothing else, it will let sensors skip the
missing voltage input.

Note that you won't be able to use dev_dbg and dev_warn before
i2c_attach_client() is called.

>  	/* It looks like fan4 and fan5 pins can be alternatively used
>  	   as fan on/off switches */
>  	
> @@ -1238,7 +1259,7 @@
>  				goto exit_remove;
>  		}
>  
> -	for (i = 0; i < 10; i++)
> +	for (i = 0; i < data->num_in; i++)
>  		if ((err = device_create_file(dev, &sda_in_input[i].dev_attr))
>  			|| (err = device_create_file(dev,
>  				&sda_in_alarm[i].dev_attr))
> @@ -1288,7 +1309,7 @@
>  	return 0;
>  
>  exit_remove:
> -	w83627ehf_device_remove_files(dev);
> +	w83627ehf_device_remove_files(dev, data);
>  	i2c_detach_client(client);
>  exit_free:
>  	kfree(data);
> @@ -1303,7 +1324,7 @@
>  	struct w83627ehf_data *data = i2c_get_clientdata(client);
>  	int err;
>  
> -	w83627ehf_device_remove_files(&client->dev);
> +	w83627ehf_device_remove_files(&client->dev, data);
>  	hwmon_device_unregister(data->class_dev);
>  
>  	if ((err = i2c_detach_client(client)))
> @@ -1332,7 +1353,13 @@
>  
>  	val = (superio_inb(SIO_REG_DEVID) << 8)
>  	    | superio_inb(SIO_REG_DEVID + 1);
> -	if ((val & SIO_ID_MASK) != SIO_W83627EHF_ID) {
> +	switch (val & SIO_ID_MASK) {
> +	case SIO_W83627EHF_ID:
> +	case SIO_W83627DHG_ID:
> +		break;
> +	default:
> +		printk(KERN_DEBUG "w83627ehf: unknown SuperIO ID: "
> +			"0x%04x & 0x%04x\n", val, SIO_ID_MASK);
>  		superio_exit();
>  		return -ENODEV;
>  	}

I see no benefit in printing the mask value here.

> --- linux-2.6.18-rc4/Documentation/hwmon/w83627ehf	2006-09-07 00:15:30.000000000 -0700
> +++ linux-2.6.18-rc4/Documentation/hwmon/w83627ehf	2006-09-07 00:15:07.000000000 -0700
> @@ -0,0 +1,62 @@
> +Kernel driver w83627ehf
> +===========> +
> +Supported chips:
> +  * Winbond W83627EHF and W83627EHG (lead-free version)
> +    Addresses scanned: ISA address retrieved from Super I/O registers
> +  * Winbond W83627DHG
> +    Addresses scanned: ISA address retrieved from Super I/O registers
> +
> +Authors:
> +        Jean Delvare <khali at linux-fr.org>
> +        Yuan Mu <Ymu at Winbond.com.tw>,
> +        Rudolf Marek <r.marek at sh.cvut.cz>
> +        David Hubbard <david.c.hubbard at gmail.com>
> +
> +Module Parameters
> +-----------------
> +
> +Currently none.
> +
> +Description
> +-----------
> +
> +This driver implements support for the W83627EHF, W83627EHG, and W83627DHG
> +Super I/O chips.
> +
> +For further information on this driver see the lm-sensors Wiki at
> +http://www.lm-sensors.org/wiki
> +
> +Please remember when implementing more features that the following registers
> +have different functions on the w83627ehf and w83627dhg. Registers may also
> +have different power-on default values, but the BIOS has probably also set
> +default values, so chip-specific differences are not important for that.
> +
> +ISA Register      Explanation of difference
> +----------------- -------------------------
> +             0x49 DHG only: selects temp used for SmartFan AUX fan, CPU fan0
> +
> +             0x4a not completely documented on EHF, and DHG docs assign
> +                  different behavior to bits 7 and 6. Also EHF might only
> +                  select temp input for SmartFan III, DHG selects temp input
> +                  in any SmartFan mode. Further EHF testing is required.
> +
> +     0x58, bank 0 Chip ID, of course. EHF: 0xa1. DHG: 0xc1
> +
> +     0x5e, bank 0 DHG only: enable bits for current mode for thermal diodes
> +                  and critical temperature protection feature
> +
> +     0x50, bank 4, bit 3, 0x5b, bank 4, bit 3, 0x52, bank 5, 0x58, bank 5, and
> +     0x59, bank 5 EHF only: DHG has no in9 (vin4)
> +
> +             0x6b DHG only: SYS fan critical temperature limit
> +
> +             0x6c DHG only: CPU fan0 critical temperature limit
> +
> +             0x6d DHG only: AUX fan critical temperature limit
> +
> +             0x6e DHG only: CPU fan1 critical temperature limit
> +
> +The W83627DHG supports Intel PECI and SST interfaces for new CPU's (e.g.
> +Intel Core). DHG queries PECI interface on CPU to read temps, and ICH8
> +chipset can read DHG temp data and drive fans. SST is a 1-wire serial bus.

Thanks,
-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi Michael,

> With the correct SuperIO ID and mask (0xa020/0xfff0) the driver seems to work
> here on:
>   Linux thanatos 2.6.17.7-mh1 #16 SMP PREEMPT Thu Sep 7 00:21:21 CEST 2006
>   i686 Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz GNU/Linux
> 
> But fan5_input (my second case fan) jumps between 0 and something around
> 30000 RPM.

This can happen if you are using fan speed control on 3-wire fans. When
the speed goes really low, the tachometer fails to sense the speed
properly and you get wacky readings. Try restoring the fan to full
speed, the reading should be back. What value is reported in the BIOS?

Also, the w83627ehf driver attempts to automatically pick the best fan
clock divider depending on the fan speed. Maybe tha algorithm has some
issues. If you enable debugging in the driver, it'll tell you the
decisions it takes, that might help pinpoint the problem.

> If I slow down my other case fan by hand (fan1), I'll get wrong values, too
> (around 12000k).

Yes, as I explained above, that's a known issue. This is a physical
limitation, there's not much you can do about that. I have observed the
same here with a different chip a few days ago. Below 50% of its full
speed value, the fan would report wacky speeds.

> Also the fan?_min have some strange values:
>   thanatos device # cat fan?_min
>   10546
>   2960
>   10546
>   10546
>   337500

The low speed limits are uninitialized. It's up to you to set the
values you want. Define them in sensors.conf (e.g. "set fan1_min 2000")
then run "sensors -s" to apply the changes.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Wed, Sep 06, 2006 at 11:20:00PM -0700, David Hubbard wrote:

> I have attached an updated patch (it now includes changes to
> drivers/hwmon/w83627ehf.c and a new Documentation/hwmon/w83627ehf
> file), plus w83627ehf.c. Michael and Michael, please try out the new
> driver. 

Thank you!  It seems to work, somewhat:

seahunt:~ # sensors
w83627ehf-isa-0290
Adapter: ISA adapter
Case Fan:    0 RPM  (min = 1318 RPM, div = 128)
CPU Fan:   865 RPM  (min = 1704 RPM, div = 8)
fan3:     1997 RPM  (min = 21093 RPM, div = 4)
fan4:        0 RPM  (min = 10546 RPM, div = 128)
fan5:        0 RPM  (min = 168750 RPM, div = 8)
Sys Temp:    +28??C  (high =   +45??C, hyst =   +40??C)
CPU Temp:  +49.5??C  (high = +45.0??C, hyst = +40.0??C)
temp3:     +58.5??C  (high = +68.0??C, hyst = +66.0??C)

It doesn't show any voltages though.  But the voltages do show up in gkrellm.

I'm not sure what that temp3 is in the sensors output.  I think the one
labeled fan3 is actually the CPU Fan, at least from looking at the BIOS
values.  I probably need to tweak /etc/sensors.conf some.

>No changes to w83627ehf_regression.sh

It blows up for me:

seahunt:~ # sh /home/michaeln/w83627ehf_regression.sh
* WARNING: This will run your system fans through many possible
           combinations. There is a possibility your system will
           overheat. Use this script at your own risk!
cat: in9_input: No such file or directory


Thanks so much for the work you folks have done on this so far!

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Rudolf Marek]

>> -    Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
>> -    w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
>> +    Chip        #vin    #fan    #pwm    #temp  sio_ID & 0xfff0 chip_id mfg_id
>> +    w83627ehf   10      5       4       3      0x8860          0xa1    0x5ca3
>> +    w83627dhg    9      5       4       3      0xa020          0xc1    0x5ca3
>>  */
> 
> As explained above, chip_id may also be 0x88 for early W83627EHFs.
> 
> I also note that our sensors-detect script was looking for chip_id =
> 0xa2 for the W83627DHG. Don't know where this value comes from. Rudolf?

Hi all,

I'm back to my mail. Bad news is that I dont know where I got 0xa2. I check all 
docs I had and it is not there. I'm sorry I can't explain where it comes from.

MIchael, or whoever with the DHG chip please:

Please unload the driver and do:

isaset -y 0x295 0x296 0x4e 0
isadump -y 0x295 0x296

This will show us the bank0 and also the ID reg. (we would need to fix it for 
the i2c...)

And BTW Jean,

	incorrectly presented itself as mallaury.nerim.net
X-Scanned: No viruses found.
X-Scan-Signature: 6c8541cafecc71ce735155c6942fb964
Cc: Marek <r.marek at sh.cvut.cz>, Michael Walle <michael at walle.cc>,
	Rudolf at ATrpms.net, LM Sensors <lm-sensors at lm-sensors.org>
Subject: Re: [lm-sensors] Asus P5B Deluxe WiFi AP Sensors
X-BeenThere: lm-sensors at lm-sensors.org

There is something wrong with the CC field of your last mail...

Thanks,
Regards
Rudolf

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Walle]

Rudolf Marek <r.marek at sh.cvut.cz> schrieb am Thu, Sep 07, 2006 at 09:34:35PM +0200:
> >>-    Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
> >>-    w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
> >>+    Chip        #vin    #fan    #pwm    #temp  sio_ID & 0xfff0 chip_id 
> >>mfg_id
> >>+    w83627ehf   10      5       4       3      0x8860          0xa1    
> >>0x5ca3
> >>+    w83627dhg    9      5       4       3      0xa020          0xc1    
> >>0x5ca3
> >> */
> >
> >As explained above, chip_id may also be 0x88 for early W83627EHFs.
> >
> >I also note that our sensors-detect script was looking for chip_id =
> >0xa2 for the W83627DHG. Don't know where this value comes from. Rudolf?
> 
> Hi all,
> 
> I'm back to my mail. Bad news is that I dont know where I got 0xa2. I check 
> all docs I had and it is not there. I'm sorry I can't explain where it 
> comes from.
> 
> MIchael, or whoever with the DHG chip please:
> 
> Please unload the driver and do:
> 
> isaset -y 0x295 0x296 0x4e 0
> isadump -y 0x295 0x296

Hi,

here is it:

thanatos mw # isaset -y 0x295 0x296 0x4e 0
thanatos mw # isadump -y 0x295 0x296
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 04 9b 04 4b 35 55 42 13 9b 4b 9b 01 3c 3c 0a 05 
10: 04 ff 30 00 00 01 01 3c 43 17 00 00 ff ff ff c7 
20: 96 e3 cc cb b8 c6 c1 27 ff 3b ff da 00 a0 94 78 
30: 90 11 82 c0 ca f0 99 b0 80 09 a6 44 39 48 b4 ff 
40: 03 de 2b de ff ff 00 15 2d 00 20 44 18 95 00 a3 
50: ff ff 00 ff ff ff 00 80 c1 64 ff ff 19 44 04 05 
60: 01 7f 00 00 01 01 3c ff 12 ff 01 ff ff ff ff ff 
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
80: 04 9b 04 4b 35 55 42 13 9b 4b 9b 01 3c 3c 0a 05 
90: 04 ff 30 00 00 01 01 3c 43 17 00 00 ff ff ff c7 
a0: 96 e3 cc cb b8 c6 c1 27 ff 3b ff da 00 a0 94 78 
b0: 90 11 82 c0 ca f0 99 b0 80 09 a6 44 39 48 b4 ff 
c0: 03 00 00 de ff ff 00 15 2d 00 20 44 18 95 00 a3 
d0: ff ff 00 ff ff ff 00 80 c1 64 ff ff 19 44 04 05 
e0: 01 7f 00 00 01 01 3c ff 12 ff 01 ff ff ff ff ff 
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

-- 
Mit freundlichen Gr??en,
 Michael Walle

In den Rohrwiesen 1a
66440 Blieskastel
michael at walle.cc

---
Don't cry because it is over, smile because it happened.

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Thu, Sep 07, 2006 at 09:34:35PM +0200, Rudolf Marek wrote:
> MIchael, or whoever with the DHG chip please:
> 
> Please unload the driver and do:
> 
> isaset -y 0x295 0x296 0x4e 0
> isadump -y 0x295 0x296

Here it is:

seahunt:~ # isaset -y 0x295 0x296 0x4e 0
seahunt:~ # isadump -y 0x295 0x296
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 04 ff 04 4b 31 00 42 10 01 4b 01 01 3c 3c 0a 05
10: 01 59 50 00 00 01 01 3c 43 17 00 00 ff ff ff c5
20: 99 e3 cc cc 98 c6 97 1e ff c1 a1 c5 b2 c5 b2 d9
30: c4 c3 b1 cf bb e3 cd da c5 46 28 11 63 08 01 ff
40: 03 b0 20 de ff ff 00 f5 2d 00 20 84 88 95 00 a3
50: ff ff 00 ff ff ff 00 80 c1 6f ff ff 19 24 04 05
60: 01 9b 31 52 9b 01 3c ff 12 ff 0a ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: 04 ff 04 4b 31 00 42 10 01 4b 01 01 3c 3c 0a 05
90: 01 59 50 00 00 01 01 3c 43 17 00 00 ff ff ff c5
a0: 99 e3 cc cc 98 c6 97 1e ff c1 a1 c5 b2 c5 b2 d9
b0: c4 c3 b1 cf bb e3 cd da c5 46 28 11 63 08 01 ff
c0: 03 00 00 de ff ff 00 f5 2d 00 20 84 88 95 00 a3
d0: ff ff 00 ff ff ff 00 80 c1 6f ff ff 19 24 04 05
e0: 01 9b 31 52 9b 01 3c ff 12 ff 0a ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
seahunt:~ #

Hope that helps you.

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

I have the output making more sense now:

w83627ehf-isa-0290
Adapter: ISA adapter
Case Fan:  878 RPM  (min = 1704 RPM, div = 8)
CPU Fan:  2057 RPM  (min = 84375 RPM, div = 4)
Power Fan: 975 RPM  (min = 168750 RPM, div = 8)
MB Temp:     +30??C  (high =   +35??C, hyst =   +40??C)
CPU Temp:  +51.0??C  (high = +70.0??C, hyst = +40.0??C)

I guess I need to fix up those min values for the fans though...

... but no voltages are shown.  Michael in Germany, can you share your
sensors.conf stuff for this chip and board with me please?

Thanks
Michael in USA

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi Michael,

> Thank you!  It seems to work, somewhat:
> 
> seahunt:~ # sensors
> w83627ehf-isa-0290
> Adapter: ISA adapter
> Case Fan:    0 RPM  (min = 1318 RPM, div = 128)
> CPU Fan:   865 RPM  (min = 1704 RPM, div = 8)
> fan3:     1997 RPM  (min = 21093 RPM, div = 4)
> fan4:        0 RPM  (min = 10546 RPM, div = 128)
> fan5:        0 RPM  (min = 168750 RPM, div = 8)
> Sys Temp:    +28?C  (high =   +45?C, hyst =   +40?C)
> CPU Temp:  +49.5?C  (high = +45.0?C, hyst = +40.0?C)
> temp3:     +58.5?C  (high = +68.0?C, hyst = +66.0?C)
> 
> It doesn't show any voltages though.  But the voltages do show up in gkrellm.

You need lm_sensors SVN for voltage values:
http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4155-20060908.tar.bz2

> >No changes to w83627ehf_regression.sh
> 
> It blows up for me:
> 
> seahunt:~ # sh /home/michaeln/w83627ehf_regression.sh
> * WARNING: This will run your system fans through many possible
>            combinations. There is a possibility your system will
>            overheat. Use this script at your own risk!
> cat: in9_input: No such file or directory

Expected, as the W83627DHG doesn't have this voltage input. You'd need
to edit the script to skip in9 completely.

> Thanks so much for the work you folks have done on this so far!

Thanks for testing :)

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Sun, Sep 10, 2006 at 07:52:59PM +0200, Jean Delvare wrote:

> You need lm_sensors SVN for voltage values:
> http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4155-20060908.tar.bz2

OK, I will grab that.

> Expected, as the W83627DHG doesn't have this voltage input. You'd need
> to edit the script to skip in9 completely.

I just noticed this morning that in the BIOS setup at the top of one of the
pages it says "Configure Win627EHF Super IO Chipset".  I had not noticed
that before (perhaps it wasn't there before, I just updated my BIOS to the
latest one).

Anyway, that doesn't appear to be the same chip, does it?

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

On Sun, Sep 10, 2006 at 12:46:22PM -0700, Michael Nelson wrote:
> On Sun, Sep 10, 2006 at 07:52:59PM +0200, Jean Delvare wrote:
> 
> > You need lm_sensors SVN for voltage values:
> > http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4155-20060908.tar.bz2
> 
> OK, I will grab that.

Here's the output using that:

$  /usr/local/bin/sensors
w83627ehf-isa-0290
Adapter: ISA adapter
VCor1:     +1.14 V  (min =  +0.00 V, max =  +1.74 V)
VCor2:     +1.82 V  (min =  +1.06 V, max =  +1.05 V) ALARM
+3.3V:     +3.26 V  (min =  +2.61 V, max =  +0.10 V) ALARM
+5V:       +5.48 V  (min =  +0.22 V, max =  +0.81 V) ALARM
+12V:      +4.62 V  (min =  +0.00 V, max =  +1.22 V) ALARM
-12V:      -6.77 V  (min = -11.78 V, max =  -5.00 V)
-5V:       -3.92 V  (min =  -7.66 V, max =  -2.81 V)
V5SB:      +5.51 V  (min =  +0.11 V, max =  +5.78 V)
VBat:      +3.10 V  (min =  +1.34 V, max =  +2.56 V) ALARM
CPU Fan:   869 RPM  (min =  803 RPM, div = 16)
Case Fan: 2083 RPM  (min = 1704 RPM, div = 8)
Power Fan: 948 RPM  (min =  803 RPM, div = 16)
MB Temp:     +30??C  (high =   +35??C, hyst =   +40??C)
CPU Temp:  +44.5??C  (high = +70.0??C, hyst = +40.0??C)

Some of the readings and settings look screwy.  More /etc/sensors.conf
tweaking needed.

Thanks

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi Michael,

> > Expected, as the W83627DHG doesn't have this voltage input. You'd need
> > to edit the script to skip in9 completely.
> 
> I just noticed this morning that in the BIOS setup at the top of one of the
> pages it says "Configure Win627EHF Super IO Chipset".  I had not noticed
> that before (perhaps it wasn't there before, I just updated my BIOS to the
> latest one).
> 
> Anyway, that doesn't appear to be the same chip, does it?

It is the same chip, for sure. But this chip has many functions, so the
menu might be to setup other functions rather than the hardware
monitoring functions.

-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Was: Re: P5B mobo

Hi Mr. Green,

Be sure to include lm-sensors at lm-sensors.org in the email conversation.

> Hi David,
>
> I am having issues with my Asus P5B mobo sensors, understand you have a
> patch that may work
>
> What output, information  etc .. do you need ? I would like to help out...

The patch is here:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-September/017625.html

It won't apply to a stock kernel, because it depends on patches in the
-mm kernel. But look at the bottom of the page:
http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060906/b139bc4d/attachment-0001.obj

Download the link to linux/drivers/hwmon/w83627ehf.c, and it has the
patch applied to it. Michael Nelson has compiled it and it worked for
him. I'd be interested to know if it works for you.

> I have same issue with my mobo but I use a patched
> 2.6.18-rc6 at the moment so have dvd drive working

Remember that the w83627ehf.c above has not been accepted into the -mm
kernel source. I am working on Super-I/O locks and should have an
updated patch ready soon. So although the file will provide useful
information, and should work on your mobo, it is broken in several
ways. (One is that it doesn't correctly support early revs of the EHF
chip.) When support for your motherboard and the w83627dhg chip is
ready in the mainline kernel, discard the w83627ehf.c file from here.

HTH,
David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Michael Nelson]

I grabbed the 2.6.18 released kernel source, applied the jmicron patch Mr.
Green sent me and the w83627ehf.c file David gave us, compiled it all and
it's all working.  I have my DVD, and I have sensors.

Thanks guys!

Michael

-- 

San Francisco, CA

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi Jean,

This is my proposed patch to add support for the w83627dhg to the
w83627ehf driver. This thread is where the patch was last discussed.
Once we get it in an approved form, I'll email the patch and
instructions for installing it to all the people who have requested
any updates since September.

The discussion for this patch and future patches is spread across
multiple email threads and several months in the mailing list
archives, so I have summarized w83627ehf's status briefly at the top
of the patch. For instance, I have updated Rudolf Marek's email
address where it occurs in the code and documentation.

David
-------------- next part --------------
This patch adds support for the w83627dhg chip.
Also includes an update to Rudolf Marek's email address.
The plan for the w83627ehf driver development from here is:
1. Add support for the 627DHG chip.
2. Convert the driver to a platform driver and remove three global variables.
3. Work on a cleaner super-io implementation including super-io locking.

--- linux-2.6.19-rc6/drivers/hwmon/w83627ehf.c	2006-12-10 14:44:32.000000000 -0800
+++ linux-2.6.19-rc6/drivers/hwmon/w83627ehf.c	2006-12-10 16:14:39.000000000 -0800
@@ -3,7 +3,7 @@
                 the Winbond W83627EHF Super-I/O chip
     Copyright (C) 2005  Jean Delvare <khali at linux-fr.org>
     Copyright (C) 2006  Yuan Mu (Winbond),
-                        Rudolf Marek <r.marek at sh.cvut.cz>
+                        Rudolf Marek <r.marek at assembler.cz>
                         David Hubbard <david.c.hubbard at gmail.com>
 
     Shamelessly ripped from the w83627hf driver
@@ -32,8 +32,10 @@
 
     Supports the following chips:
 
-    Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
-    w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
+    Chip        #vin    #fan    #pwm    #temp  chip IDs       mfg ID
+    w83627ehf   10      5       4       3      0x8853 0x88    0x5ca3
+                                               0x8863 0xa1
+    w83627dhg    9      5       4       3      0xa020 0xc1    0x5ca3
 */
 
 #include <linux/module.h>
@@ -55,8 +57,18 @@
  * Super-I/O constants and functions
  */
 
+/*
+ * The three following globals are initialized in w83627ehf_find(), before
+ * the i2c-isa device is created. Otherwise, they could be stored in
+ * w83627ehf_data. This is ugly, but necessary. and when the driver is next
+ * updated to become a platform driver, the globals will disappear.
+ */
 static int REG;		/* The register to read/write */
 static int VAL;		/* The value to read/write */
+/* The w83627ehf/ehg have 10 voltage inputs, but the w83627dhg has 9. This
+ * value is also used in w83627ehf_detect() to export a device name in sysfs
+ * (e.g. w83627ehf or w83627dhg) */
+static int w83627ehf_num_in;
 
 #define W83627EHF_LD_HWM	0x0b
 
@@ -65,8 +77,10 @@
 #define SIO_REG_ENABLE		0x30	/* Logical device enable */
 #define SIO_REG_ADDR		0x60	/* Logical device address (2 bytes) */
 
-#define SIO_W83627EHF_ID	0x8840
-#define SIO_ID_MASK		0xFFC0
+#define SIO_W83627EHF_ID	0x8850
+#define SIO_W83627EHG_ID	0x8860
+#define SIO_W83627DHG_ID	0xa020
+#define SIO_ID_MASK		0xFFF0
 
 static inline void
 superio_outb(int reg, int val)
@@ -115,8 +129,10 @@
 
 #define W83627EHF_REG_BANK		0x4E
 #define W83627EHF_REG_CONFIG		0x40
-#define W83627EHF_REG_CHIP_ID		0x49
+
+/* Not currently used. REG_MAN_ID = 0x5ca3. REG_CHIP_ID = 0x88/0xa1/0xc1 */
 #define W83627EHF_REG_MAN_ID		0x4F
+#define W83627EHF_REG_CHIP_ID		0x58
 
 static const u16 W83627EHF_REG_FAN[] = { 0x28, 0x29, 0x2a, 0x3f, 0x553 };
 static const u16 W83627EHF_REG_FAN_MIN[] = { 0x3b, 0x3c, 0x3d, 0x3e, 0x55c };
@@ -429,7 +445,7 @@
 		}
 
 		/* Measured voltages and limits */
-		for (i = 0; i < 10; i++) {
+		for (i = 0; i < w83627ehf_num_in; i++) {
 			data->in[i] = w83627ehf_read_value(client,
 				      W83627EHF_REG_IN(i));
 			data->in_min[i] = w83627ehf_read_value(client,
@@ -1121,7 +1137,7 @@
 		device_remove_file(dev, &sda_sf3_arrays[i].dev_attr);
 	for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan4); i++)
 		device_remove_file(dev, &sda_sf3_arrays_fan4[i].dev_attr);
-	for (i = 0; i < 10; i++) {
+	for (i = 0; i < w83627ehf_num_in; i++) {
 		device_remove_file(dev, &sda_in_input[i].dev_attr);
 		device_remove_file(dev, &sda_in_alarm[i].dev_attr);
 		device_remove_file(dev, &sda_in_min[i].dev_attr);
@@ -1196,7 +1212,11 @@
 	client->flags = 0;
 	dev = &client->dev;
 
-	strlcpy(client->name, "w83627ehf", I2C_NAME_SIZE);
+	if (w83627ehf_num_in = 9)
+		strlcpy(client->name, "w83627dhg", I2C_NAME_SIZE);
+	else	/* just say ehf. 627EHG is 627EHF in lead-free packaging. */
+		strlcpy(client->name, "w83627ehf", I2C_NAME_SIZE);
+
 	data->valid = 0;
 	mutex_init(&data->update_lock);
 
@@ -1246,7 +1266,7 @@
 				goto exit_remove;
 		}
 
-	for (i = 0; i < 10; i++)
+	for (i = 0; i < w83627ehf_num_in; i++)
 		if ((err = device_create_file(dev, &sda_in_input[i].dev_attr))
 			|| (err = device_create_file(dev,
 				&sda_in_alarm[i].dev_attr))
@@ -1340,7 +1360,17 @@
 
 	val = (superio_inb(SIO_REG_DEVID) << 8)
 	    | superio_inb(SIO_REG_DEVID + 1);
-	if ((val & SIO_ID_MASK) != SIO_W83627EHF_ID) {
+	switch (val & SIO_ID_MASK) {
+	case SIO_W83627DHG_ID:
+		w83627ehf_num_in = 9;
+		break;
+	case SIO_W83627EHF_ID:
+	case SIO_W83627EHG_ID:
+		w83627ehf_num_in = 10;
+		break;
+	default:
+		printk(KERN_WARNING "w83627ehf: unknown ID: 0x%04x "
+			"(is this really a w83627?)\n", val);
 		superio_exit();
 		return -ENODEV;
 	}
--- linux-2.6.19-rc6/Documentation/hwmon/w83627ehf	2006-12-10 16:09:12.000000000 -0800
+++ linux-2.6.19-rc6/Documentation/hwmon/w83627ehf	2006-12-10 16:23:42.000000000 -0800
@@ -2,26 +2,29 @@
 =========== 
 Supported chips:
-  * Winbond W83627EHF/EHG (ISA access ONLY)
+  * Winbond W83627EHF/EHG/DHG (ISA access ONLY)
     Prefix: 'w83627ehf'
     Addresses scanned: ISA address retrieved from Super I/O registers
-    Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
+    Datasheet:
+        http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
+	DHG datasheet confidential.
 
 Authors:
         Jean Delvare <khali at linux-fr.org>
         Yuan Mu (Winbond)
-        Rudolf Marek <r.marek at sh.cvut.cz>
+        Rudolf Marek <r.marek at assembler.cz>
+        David Hubbard <david.c.hubbard at gmail.com>
 
 Description
 -----------
 
-This driver implements support for the Winbond W83627EHF and W83627EHG
-super I/O chips. We will refer to them collectively as Winbond chips.
+This driver implements support for the Winbond W83627EHF, W83627EHG, and
+W83627DHG super I/O chips. We will refer to them collectively as Winbond chips.
 
 The chips implement three temperature sensors, five fan rotation
-speed sensors, ten analog voltage sensors, alarms with beep warnings (control
-unimplemented), and some automatic fan regulation strategies (plus manual
-fan control mode).
+speed sensors, ten analog voltage sensors (only nine for the 627DHG), alarms
+with beep warnings (control unimplemented), and some automatic fan regulation
+strategies (plus manual fan control mode).
 
 Temperatures are measured in degrees Celsius and measurement resolution is 1
 degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
@@ -55,6 +58,9 @@
 /sys files
 ----------
 
+name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG,
+       it is set to "w83627ehf" and for the W83627DHG it is set to "w83627dhg."
+
 pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range:
 	   0 (stop) to 255 (full)
 
@@ -83,3 +89,36 @@
 
 Note: last two functions are influenced by other control bits, not yet exported
       by the driver, so a change might not have any effect.
+
+Implementation Details
+----------------------
+Future driver development should bear in mind that the following registers have
+different functions on the 627EHF and the 627DHG. Some registers also have
+different power-on default values, but BIOS should already be loading
+appropriate defaults. Note that bank selection must be performed as is currently
+done in the driver for all register addresses.
+
+0x49:  only on DHG, selects temperature source for AUX fan, CPU fan0
+0x4a:  not completely documented for the EHF and the DHG documentation assigns
+       different behavior to bits 7 and 6, including extending the temperature
+       input selection to SmartFan I, not just SmartFan III. Testing on the EHF
+       will reveal whether they are compatible or not.
+
+0x58:  Chip ID: 0xa1=EHF 0xc1=DHG
+0x5e:  only on DHG, has bits to enable "current mode" temperature detection and
+       critical temperature protection
+0x45b: only on EHF, bit 3, vin4 alarm (EHF supports 10 inputs, only 9 on DHG)
+0x552: only on EHF, vin4
+0x558: only on EHF, vin4 high limit
+0x559: only on EHF, vin4 low limit
+0x6b:  only on DHG, SYS fan critical temperature
+0x6c:  only on DHG, CPU fan0 critical temperature
+0x6d:  only on DHG, AUX fan critical temperature
+0x6e:  only on DHG, CPU fan1 critical temperature
+
+0x50-0x55 and 0x650-0x657 are marked "Test Register" for the EHF, but "Reserved
+       Register" for the DHG
+
+The DHG also supports PECI, where the DHG queries Intel CPU temperatures, and
+the ICH8 southbridge gets that data via PECI from the DHG, so that the
+southbridge drives the fans. And the DHG supports SST, a one-wire serial bus.

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi David,

Here are some things you could do (pick any that appeal to you):
- Subscribe to the lm-sensors list
(http://lists.lm-sensors.org/mailman/listinfo/lm-sensors)
- What hardware monitoring chip do you have on your motherboard? If
you have a 627ehf/ehg/dhg jump in with testing the new driver -- and
there are some bugs I could point you to, also. Or if you have another
chip, I'm sure it needs development too. Do you want to work in the
linux kernel?
- The lm-sensors project also has work, which I'm sure Jean Delvare
and Rudolf Marek could tell you more about.

David

On 12/10/06, David Holl <david at ad5ey.net> wrote:
> Hi David, I recently saw your Sept discussion messages about the P5B Deluxe
> WiFi motherboards.  If you'd like another debugger / beta tester / guinea
> pig, I would like to help.  :)  (proficient in c/asm/unix but new to
> lm-sensors)
>
> - David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Holl]

>
> Hi David,
>
> Here are some things you could do (pick any that appeal to you):
> - Subscribe to the lm-sensors list (
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors)


Already done.  :)

- What hardware monitoring chip do you have on your motherboard?


W83627DHG / ICH8 -- I have the same P5B+WiFi board that's discussed in this
post:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-August/017332.html

If you have a 627ehf/ehg/dhg jump in with testing the new driver -- and
> there are some bugs I could point you to, also. Or if you have another chip,
> I'm sure it needs development too.


I could try my hand with some 627DHG bugs.  So what's the best way to
start?  Install 2.6.19 w/ the patch you just sent the other day?
(w83627ehf_add_w83627dhg_support.patch) ?  I also switched up to lm-sensors
v2.10.1.

Do you want to work in the linux kernel?
> - The lm-sensors project also has work, which I'm sure Jean Delvare and
> Rudolf Marek could tell you more about.


I'll work wherever you guys would need me too.  (I'm only finishing my
dissertation now anyways...)

David
>

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061211/0820ee29/attachment.html 

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hello again!

> > - Subscribe to the lm-sensors list
> (http://lists.lm-sensors.org/mailman/listinfo/lm-sensors)
>
> Already done.  :)
>
> > - What hardware monitoring chip do you have on your motherboard?
>
> W83627DHG / ICH8 -- I have the same P5B+WiFi board that's discussed in this
> post:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-August/017332.html
>
> > If you have a 627ehf/ehg/dhg jump in with testing the new driver -- and
> there are some bugs I could point you to, also. Or if you have another chip,
> I'm sure it needs development too.
>
> I could try my hand with some 627DHG bugs.  So what's the best way to start?
>  Install 2.6.19 w/ the patch you just sent the other day?
> (w83627ehf_add_w83627dhg_support.patch) ?  I also switched
> up to lm-sensors v2.10.1.

Feel free to install the patch I posted and test it. I have a test
script but I'm waiting for Jean to get back (I believe he's on
vacation for a few weeks) and then I'll send out the patch to everyone
for testing. So yeah, go ahead!

Here is another bug report that you could work on:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-November/018268.html

(I'll probably get on that one in January, but if you figure it out,
that's great!)

> > - The lm-sensors project also has work, which I'm sure Jean Delvare and
> Rudolf Marek could tell you more about.
>
> I'll work wherever you guys would need me too.  (I'm only finishing my
> dissertation now anyways...)

This is a list of all the active tickets:
http://www.lm-sensors.org/report/1

It's also very useful to just keep up to date on the discussion on the
lm-sensors list. There are lots of useful things to learn by watching
the devel process.

David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Holl]

>
> Feel free to install the patch I posted and test it. I have a test script
> but I'm waiting for Jean to get back (I believe he's on vacation for a few
> weeks) and then I'll send out the patch to everyone for testing. So yeah, go
> ahead!


All right -- I've applied your patch to kernel 2.6.19, and I'm just
familiarizing myself with sensors.conf & how my particular board is wired.
Just to ground myself --- When I run "sensors", I only get two lines of
output; this is bad, correct?

roo2d2 src # sensors
w83627dhg-isa-0290
Adapter: ISA adapter

I'm poking at creating a chip  "w83627dhg-*" section in sensors.conf, but
the sensors command still does not return any additional output.  Is this
the right approach?

Otherwise, I appear to have all the entries under
/sys/devices/platform/i2c-9191/9191-0290
  fan[1-5]_*  in[0-8]_*  pwm[1-4]*  temp[123]_*
and I've already reproduced an earlier observation on this list that
fan[145] are all controlled via pwm4.

Here is another bug report that you could work on:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-November/018268.html
>
> (I'll probably get on that one in January, but if you figure it out,
> that's great!)

This is a list of all the active tickets: http://www.lm-sensors.org/report/1
>
> It's also very useful to just keep up to date on the discussion on the
> lm-sensors list. There are lots of useful things to learn by watching the
> devel process.


Nifty -- I'll keep an eye out for anything I could help with.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061211/f15b1776/attachment.html 

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi David,

> All right -- I've applied your patch to kernel 2.6.19, and I'm just
> familiarizing myself with sensors.conf & how my particular board is wired.
> Just to ground myself --- When I run "sensors", I only get two lines of
> output; this is bad, correct?
>
> roo2d2 src # sensors
> w83627dhg-isa-0290
> Adapter: ISA adapter
>
> I'm poking at creating a chip  "w83627dhg-*" section in sensors.conf, but
> the sensors command still does not return any additional output.  Is this
> the right approach?

I'm at work now (and will not be sleeping much in the next few days)
but if you can roust anyone else (maybe Rudolf Marek?) they can walk
you through tweaking sensors.conf.

> Otherwise, I appear to have all the entries under
> /sys/devices/platform/i2c-9191/9191-0290
>   fan[1-5]_*  in[0-8]_*  pwm[1-4]*  temp[123]_*
> and I've already reproduced an earlier observation on this list that
> fan[145] are all controlled via pwm4.

This is good. I'd suggest just running the new module on your system
continuously. Make sure the temperatures, voltages, and fan RPMs read
correctly and don't do anything unexpected. To verify temps, voltages,
and fans are correct, compare them to what's reported in the BIOS.
This is a first step for getting a good sensors.conf anyway.

David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

Hi Colin,

Thanks for doing that! I have attached a similar patch I submitted for
review 4 days ago. Jean is on vacation right now and will probably
look at both patches when he gets back. (I don't know exactly when
that is.) How would you feel about downloading and testing the patch I
have. One of the significant improvements is that it only reports 9
voltage inputs, where your patch reports 10. The 627DHG only has 9
inputs. In the patch I'm sending you, there's an update to
linux/Documentation/hwmon/w83627ehf, which describes a lot of the
relevant information about the 627DHG.

Anyway, I'd love to work with you to get 627DHG support in the kernel.

David

On 12/14/06, Con Kolivas <kernel at kolivas.org> wrote:
> Hi all
>
> Browsing the past archives I saw that the W83627DHG chip was a lot like the
> w83627ehf driver and support shouldn't be too hard to add. So I probed my own
> hardware to see what it returned and added a small patch to try to make it
> work. The output of  sensors after that seems accurate apart from AUX Temp
> which seems to jump around a bit. The cpu and system temperature, fan speeds
> and voltages that I have all seem pretty close too.
>
> Here is a patch that I created for the 2.6.19 kernel that gave me the output I
> required. I doubt very much that this is the correct and final approach so it
> may blow up your machine etc etc so for those who are desparate and want to
> try it all the usual warnings apply and so on... :D
>
> ---
> Hack for W83627DHG support from W83627EHF hwmon driver.
>
> Signed-off-by: Con Kolivas <kernel at kolivas.org>
>
> ---
>  drivers/hwmon/w83627ehf.c |    8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> Index: linux-2.6.19-ck2/drivers/hwmon/w83627ehf.c
> =================================> --- linux-2.6.19-ck2.orig/drivers/hwmon/w83627ehf.c     2006-12-15 13:07:54.000000000 +1100
> +++ linux-2.6.19-ck2/drivers/hwmon/w83627ehf.c  2006-12-15 13:18:23.000000000 +1100
> @@ -66,6 +66,7 @@ static int VAL;               /* The value to read/wr
>  #define SIO_REG_ADDR           0x60    /* Logical device address (2 bytes) */
>
>  #define SIO_W83627EHF_ID       0x8840
> +#define SIO_W83627DHG_ID       0xA000
>  #define SIO_ID_MASK            0xFFC0
>
>  static inline void
> @@ -1340,9 +1341,10 @@ static int __init w83627ehf_find(int sio
>
>         val = (superio_inb(SIO_REG_DEVID) << 8)
>             | superio_inb(SIO_REG_DEVID + 1);
> -       if ((val & SIO_ID_MASK) != SIO_W83627EHF_ID) {
> -               superio_exit();
> -               return -ENODEV;
> +       if (((val & SIO_ID_MASK) != SIO_W83627EHF_ID) &&
> +               ((val & SIO_ID_MASK) != SIO_W83627DHG_ID)) {
> +                       superio_exit();
> +                       return -ENODEV;
>         }
>
>         superio_select(W83627EHF_LD_HWM);
>
>
> --
> -ck
-------------- next part --------------
This patch adds support for the w83627dhg chip.
Also includes an update to Rudolf Marek's email address.
The plan for the w83627ehf driver development from here is:
1. Add support for the 627DHG chip.
2. Convert the driver to a platform driver and remove three global variables.
3. Work on a cleaner super-io implementation including super-io locking.

--- linux-2.6.19-rc6/drivers/hwmon/w83627ehf.c	2006-12-10 14:44:32.000000000 -0800
+++ linux-2.6.19-rc6/drivers/hwmon/w83627ehf.c	2006-12-10 16:14:39.000000000 -0800
@@ -3,7 +3,7 @@
                 the Winbond W83627EHF Super-I/O chip
     Copyright (C) 2005  Jean Delvare <khali at linux-fr.org>
     Copyright (C) 2006  Yuan Mu (Winbond),
-                        Rudolf Marek <r.marek at sh.cvut.cz>
+                        Rudolf Marek <r.marek at assembler.cz>
                         David Hubbard <david.c.hubbard at gmail.com>
 
     Shamelessly ripped from the w83627hf driver
@@ -32,8 +32,10 @@
 
     Supports the following chips:
 
-    Chip        #vin    #fan    #pwm    #temp   chip_id    man_id
-    w83627ehf   10      5       4       3       0x88,0xa1  0x5ca3
+    Chip        #vin    #fan    #pwm    #temp  chip IDs       mfg ID
+    w83627ehf   10      5       4       3      0x8853 0x88    0x5ca3
+                                               0x8863 0xa1
+    w83627dhg    9      5       4       3      0xa020 0xc1    0x5ca3
 */
 
 #include <linux/module.h>
@@ -55,8 +57,18 @@
  * Super-I/O constants and functions
  */
 
+/*
+ * The three following globals are initialized in w83627ehf_find(), before
+ * the i2c-isa device is created. Otherwise, they could be stored in
+ * w83627ehf_data. This is ugly, but necessary. and when the driver is next
+ * updated to become a platform driver, the globals will disappear.
+ */
 static int REG;		/* The register to read/write */
 static int VAL;		/* The value to read/write */
+/* The w83627ehf/ehg have 10 voltage inputs, but the w83627dhg has 9. This
+ * value is also used in w83627ehf_detect() to export a device name in sysfs
+ * (e.g. w83627ehf or w83627dhg) */
+static int w83627ehf_num_in;
 
 #define W83627EHF_LD_HWM	0x0b
 
@@ -65,8 +77,10 @@
 #define SIO_REG_ENABLE		0x30	/* Logical device enable */
 #define SIO_REG_ADDR		0x60	/* Logical device address (2 bytes) */
 
-#define SIO_W83627EHF_ID	0x8840
-#define SIO_ID_MASK		0xFFC0
+#define SIO_W83627EHF_ID	0x8850
+#define SIO_W83627EHG_ID	0x8860
+#define SIO_W83627DHG_ID	0xa020
+#define SIO_ID_MASK		0xFFF0
 
 static inline void
 superio_outb(int reg, int val)
@@ -115,8 +129,10 @@
 
 #define W83627EHF_REG_BANK		0x4E
 #define W83627EHF_REG_CONFIG		0x40
-#define W83627EHF_REG_CHIP_ID		0x49
+
+/* Not currently used. REG_MAN_ID = 0x5ca3. REG_CHIP_ID = 0x88/0xa1/0xc1 */
 #define W83627EHF_REG_MAN_ID		0x4F
+#define W83627EHF_REG_CHIP_ID		0x58
 
 static const u16 W83627EHF_REG_FAN[] = { 0x28, 0x29, 0x2a, 0x3f, 0x553 };
 static const u16 W83627EHF_REG_FAN_MIN[] = { 0x3b, 0x3c, 0x3d, 0x3e, 0x55c };
@@ -429,7 +445,7 @@
 		}
 
 		/* Measured voltages and limits */
-		for (i = 0; i < 10; i++) {
+		for (i = 0; i < w83627ehf_num_in; i++) {
 			data->in[i] = w83627ehf_read_value(client,
 				      W83627EHF_REG_IN(i));
 			data->in_min[i] = w83627ehf_read_value(client,
@@ -1121,7 +1137,7 @@
 		device_remove_file(dev, &sda_sf3_arrays[i].dev_attr);
 	for (i = 0; i < ARRAY_SIZE(sda_sf3_arrays_fan4); i++)
 		device_remove_file(dev, &sda_sf3_arrays_fan4[i].dev_attr);
-	for (i = 0; i < 10; i++) {
+	for (i = 0; i < w83627ehf_num_in; i++) {
 		device_remove_file(dev, &sda_in_input[i].dev_attr);
 		device_remove_file(dev, &sda_in_alarm[i].dev_attr);
 		device_remove_file(dev, &sda_in_min[i].dev_attr);
@@ -1196,7 +1212,11 @@
 	client->flags = 0;
 	dev = &client->dev;
 
-	strlcpy(client->name, "w83627ehf", I2C_NAME_SIZE);
+	if (w83627ehf_num_in = 9)
+		strlcpy(client->name, "w83627dhg", I2C_NAME_SIZE);
+	else	/* just say ehf. 627EHG is 627EHF in lead-free packaging. */
+		strlcpy(client->name, "w83627ehf", I2C_NAME_SIZE);
+
 	data->valid = 0;
 	mutex_init(&data->update_lock);
 
@@ -1246,7 +1266,7 @@
 				goto exit_remove;
 		}
 
-	for (i = 0; i < 10; i++)
+	for (i = 0; i < w83627ehf_num_in; i++)
 		if ((err = device_create_file(dev, &sda_in_input[i].dev_attr))
 			|| (err = device_create_file(dev,
 				&sda_in_alarm[i].dev_attr))
@@ -1340,7 +1360,17 @@
 
 	val = (superio_inb(SIO_REG_DEVID) << 8)
 	    | superio_inb(SIO_REG_DEVID + 1);
-	if ((val & SIO_ID_MASK) != SIO_W83627EHF_ID) {
+	switch (val & SIO_ID_MASK) {
+	case SIO_W83627DHG_ID:
+		w83627ehf_num_in = 9;
+		break;
+	case SIO_W83627EHF_ID:
+	case SIO_W83627EHG_ID:
+		w83627ehf_num_in = 10;
+		break;
+	default:
+		printk(KERN_WARNING "w83627ehf: unknown ID: 0x%04x "
+			"(is this really a w83627?)\n", val);
 		superio_exit();
 		return -ENODEV;
 	}
--- linux-2.6.19-rc6/Documentation/hwmon/w83627ehf	2006-12-10 16:09:12.000000000 -0800
+++ linux-2.6.19-rc6/Documentation/hwmon/w83627ehf	2006-12-10 16:23:42.000000000 -0800
@@ -2,26 +2,29 @@
 =========== 
 Supported chips:
-  * Winbond W83627EHF/EHG (ISA access ONLY)
+  * Winbond W83627EHF/EHG/DHG (ISA access ONLY)
     Prefix: 'w83627ehf'
     Addresses scanned: ISA address retrieved from Super I/O registers
-    Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
+    Datasheet:
+        http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
+	DHG datasheet confidential.
 
 Authors:
         Jean Delvare <khali at linux-fr.org>
         Yuan Mu (Winbond)
-        Rudolf Marek <r.marek at sh.cvut.cz>
+        Rudolf Marek <r.marek at assembler.cz>
+        David Hubbard <david.c.hubbard at gmail.com>
 
 Description
 -----------
 
-This driver implements support for the Winbond W83627EHF and W83627EHG
-super I/O chips. We will refer to them collectively as Winbond chips.
+This driver implements support for the Winbond W83627EHF, W83627EHG, and
+W83627DHG super I/O chips. We will refer to them collectively as Winbond chips.
 
 The chips implement three temperature sensors, five fan rotation
-speed sensors, ten analog voltage sensors, alarms with beep warnings (control
-unimplemented), and some automatic fan regulation strategies (plus manual
-fan control mode).
+speed sensors, ten analog voltage sensors (only nine for the 627DHG), alarms
+with beep warnings (control unimplemented), and some automatic fan regulation
+strategies (plus manual fan control mode).
 
 Temperatures are measured in degrees Celsius and measurement resolution is 1
 degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
@@ -55,6 +58,9 @@
 /sys files
 ----------
 
+name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG,
+       it is set to "w83627ehf" and for the W83627DHG it is set to "w83627dhg."
+
 pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range:
 	   0 (stop) to 255 (full)
 
@@ -83,3 +89,36 @@
 
 Note: last two functions are influenced by other control bits, not yet exported
       by the driver, so a change might not have any effect.
+
+Implementation Details
+----------------------
+Future driver development should bear in mind that the following registers have
+different functions on the 627EHF and the 627DHG. Some registers also have
+different power-on default values, but BIOS should already be loading
+appropriate defaults. Note that bank selection must be performed as is currently
+done in the driver for all register addresses.
+
+0x49:  only on DHG, selects temperature source for AUX fan, CPU fan0
+0x4a:  not completely documented for the EHF and the DHG documentation assigns
+       different behavior to bits 7 and 6, including extending the temperature
+       input selection to SmartFan I, not just SmartFan III. Testing on the EHF
+       will reveal whether they are compatible or not.
+
+0x58:  Chip ID: 0xa1=EHF 0xc1=DHG
+0x5e:  only on DHG, has bits to enable "current mode" temperature detection and
+       critical temperature protection
+0x45b: only on EHF, bit 3, vin4 alarm (EHF supports 10 inputs, only 9 on DHG)
+0x552: only on EHF, vin4
+0x558: only on EHF, vin4 high limit
+0x559: only on EHF, vin4 low limit
+0x6b:  only on DHG, SYS fan critical temperature
+0x6c:  only on DHG, CPU fan0 critical temperature
+0x6d:  only on DHG, AUX fan critical temperature
+0x6e:  only on DHG, CPU fan1 critical temperature
+
+0x50-0x55 and 0x650-0x657 are marked "Test Register" for the EHF, but "Reserved
+       Register" for the DHG
+
+The DHG also supports PECI, where the DHG queries Intel CPU temperatures, and
+the ICH8 southbridge gets that data via PECI from the DHG, so that the
+southbridge drives the fans. And the DHG supports SST, a one-wire serial bus.

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Holl]

Hey David, I figured out why running the "sensors" didn't produce any output
for my DHG chip --- It wasn't added yet to svn:lm-sensors/trunk!  (or is
there a different svn branch I should've checked out?)

Anyhow, I attached a patch (svn diff) of the edits to add the DHG to
libsensors, sensors, and sensord.  I basically copied the EHF driver but
removed any reference to voltage sensor in9.  If you'd prefer, I could try
to maximize the code overlap between the EHF & DHG if yall think that'll
make the code easier to maintain in the long run.  But for now, I just made
the DHG functions & constants completely separate from (but near identical
to) their EHF equivalents.

So now, running sensors or sensord actually prints my temps / voltages / fan
speeds.  :)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061215/00518f33/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lm-sensors_w83627dhg.patch
Type: text/x-patch
Size: 20369 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061215/00518f33/attachment-0001.bin 

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Con Kolivas]

On Friday 15 December 2006 14:34, David Hubbard wrote:
> Hi Colin,
>
> Thanks for doing that! I have attached a similar patch I submitted for
> review 4 days ago. Jean is on vacation right now and will probably
> look at both patches when he gets back. (I don't know exactly when
> that is.) How would you feel about downloading and testing the patch I
> have. One of the significant improvements is that it only reports 9
> voltage inputs, where your patch reports 10. The 627DHG only has 9
> inputs. In the patch I'm sending you, there's an update to
> linux/Documentation/hwmon/w83627ehf, which describes a lot of the
> relevant information about the 627DHG.
>
> Anyway, I'd love to work with you to get 627DHG support in the kernel.

Oh mine was never meant to be comprehensive, just a hack as I needed to see 
the cpu temp. From the looks of your patch it doesn't appear that you need my 
help anyway :) Thanks for the effort.

-- 
-ck

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Hubbard]

David,

I remember seeing some emails a few weeks ago where people
successfully detected the 627DHG using the latest sensors checked out
from the source repository at lm-sensors.org. I haven't verified
what's there, but I just thought I should point you in that direction.
(I'm not even sure who to contact about sensorsd, libsensors, and
sensors. Jean?)

Glad to hear you're getting good results.

David

On 12/14/06, David Holl <david at ad5ey.net> wrote:
> Hey David, I figured out why running the "sensors" didn't produce any output
> for my DHG chip --- It wasn't added yet to svn:lm-sensors/trunk!  (or is
> there a different svn branch I should've checked out?)
>
>  Anyhow, I attached a patch (svn diff) of the edits to add the DHG to
> libsensors, sensors, and sensord.  I basically copied the EHF driver but
> removed any reference to voltage sensor in9.  If you'd prefer, I could try
> to maximize the code overlap between the EHF & DHG if yall think that'll
> make the code easier to maintain in the long run.  But for now, I just made
> the DHG functions & constants completely separate from (but near identical
> to) their EHF equivalents.
>
> So now, running sensors or sensord actually prints my temps / voltages / fan
> speeds.  :)
>
> - David

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[David Holl]

Yes, I checked out the head branch (
http://lm-sensors.org/svn/lm-sensors/trunk) when the stock version
(2.10.1in my Linux distro) didn't work -- and I confirmed the code in
the
repository was also incapable of printing anything out from the "sensors"
command.  (or sensord)

In brief summary: sensors & sensord would query libsensors, which had no
idea what the string "w83627dhg" mapped to so the library would return error
codes.  So in my patch, I added w83627dhg using w83627ehf as a model, to
libsensors, sensord and sensors.

If some one was successful in getting repository code for "sensors" to print
out temps+fans+voltages from w83627dhg, then they weren't using
lm-sensors/trunk, or support was removed from the time they used trunk to
the time I checked it out.  <shrug>  Even without modifying the lm-sensors
svn code, I could still see temps using gkrellm via the /sys interface, but
it felt "unclean" that I had to tell gkrellm how to scale the raw numbers
into voltages, etc -- separately from ksensors, xsensors, etc... I like the
centrality of libsensors for that -- hence my motivation for updating my
sensors.conf and consequently, investigating why did the "sensors" command
did not print anything out for my chipset.

(I was originally wondering if I still had a syntax error in sensors.conf,
so I used gdb+ddd to step through the program execution -- that's how I
found there was No support for *dhg in the repository code.)

- David


On 12/15/06, David Hubbard <david.c.hubbard at gmail.com> wrote:
>
> David,
>
> I remember seeing some emails a few weeks ago where people successfully
> detected the 627DHG using the latest sensors checked out from the source
> repository at lm-sensors.org. I haven't verified what's there, but I just
> thought I should point you in that direction. (I'm not even sure who to
> contact about sensorsd, libsensors, and sensors. Jean?)
>
> Glad to hear you're getting good results.
>
> David
>
> On 12/14/06, David Holl <david at ad5ey.net> wrote:
> > Hey David, I figured out why running the "sensors" didn't produce any
> output
> > for my DHG chip --- It wasn't added yet to svn:lm-sensors/trunk!  (or is
> > there a different svn branch I should've checked out?)
> >
> >  Anyhow, I attached a patch (svn diff) of the edits to add the DHG to
> > libsensors, sensors, and sensord.  I basically copied the EHF driver but
> > removed any reference to voltage sensor in9.  If you'd prefer, I could
> try
> > to maximize the code overlap between the EHF & DHG if yall think that'll
> > make the code easier to maintain in the long run.  But for now, I just
> made
> > the DHG functions & constants completely separate from (but near
> identical
> > to) their EHF equivalents.
> >
> > So now, running sensors or sensord actually prints my temps / voltages /
> fan
> > speeds.  :)
> >
> > - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061216/0b4da146/attachment.html 

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

David,

On Sun, 10 Dec 2006 15:30:03 -0800, David Hubbard wrote:
> This is my proposed patch to add support for the w83627dhg to the
> w83627ehf driver. This thread is where the patch was last discussed.
> Once we get it in an approved form, I'll email the patch and
> instructions for installing it to all the people who have requested
> any updates since September.
> 
> The discussion for this patch and future patches is spread across
> multiple email threads and several months in the mailing list
> archives, so I have summarized w83627ehf's status briefly at the top
> of the patch. For instance, I have updated Rudolf Marek's email
> address where it occurs in the code and documentation.

Bad idea, as this was already fixed upstream, and as a result your
patch will no longer apply there. The golden rule is that a patch
should make just one thing - for this reason exactly.

Care to provide a patch which would apply cleanly on top of 2.6.20-rc1?
I would also suggest that you start a new thread for this, to make the
subsequent discussion more visible.

Thanks,
-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

David, Con,

On Thu, 14 Dec 2006 20:34:13 -0700, David Hubbard wrote:
> Thanks for doing that! I have attached a similar patch I submitted for
> review 4 days ago. Jean is on vacation right now and will probably
> look at both patches when he gets back. (I don't know exactly when
> that is.) How would you feel about downloading and testing the patch I
> have. One of the significant improvements is that it only reports 9
> voltage inputs, where your patch reports 10. The 627DHG only has 9
> inputs. In the patch I'm sending you, there's an update to
> linux/Documentation/hwmon/w83627ehf, which describes a lot of the
> relevant information about the 627DHG.

No, I wasn't on vacation, I was away from home for my work. I will be
in vacation later this month (as pretty much everyone, I guess.)

I don't know when I'll have time to review your patch, as I am
currently busy with large i2c-core cleanups, and am also spending a
log of time preparing a talk I am giving by the end of January (a
significant part of that time being needed to just tame OpenOffice
Impress). Rudolf Marek might be quicker than me on this one.

Thanks,
-- 
Jean Delvare

[lm-sensors] Asus P5B Deluxe WiFi AP Sensors

[Jean Delvare]

Hi David,

On Fri, 15 Dec 2006 00:05:40 -0500, David Holl wrote:
> Hey David, I figured out why running the "sensors" didn't produce any output
> for my DHG chip --- It wasn't added yet to svn:lm-sensors/trunk!  (or is
> there a different svn branch I should've checked out?)

Your analysis is correct.

> Anyhow, I attached a patch (svn diff) of the edits to add the DHG to
> libsensors, sensors, and sensord.  I basically copied the EHF driver but
> removed any reference to voltage sensor in9.  If you'd prefer, I could try
> to maximize the code overlap between the EHF & DHG if yall think that'll
> make the code easier to maintain in the long run.  But for now, I just made
> the DHG functions & constants completely separate from (but near identical
> to) their EHF equivalents.
> 
> So now, running sensors or sensord actually prints my temps / voltages / fan
> speeds.  :)

Good. However, as I answered in ticket #2157, I would prefer a much
smaller patch reusing all the w83627ehf structures rather than
duplicating them. Can you please submit a patch doing this?

Thanks,
-- 
Jean Delvare