[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Timothy Findlay]

Hi Folks,

I've got a zippy new P5WD2 Premium, which is based on the Intel 955 
chipset (Intel 801 SMBus) ... here's my output from "sensors-detect":

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 0x30
Client found at address 0x32
Client found at address 0x44
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
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

Searching my motherboard, I found a myriad of other chips, but I'm 
pretty sure the Winbond W83627EHG-A is the one we're after.

I searched your site a bit, and wondered if I could use the w83627ehf 
driver ? If so, how ?

Here's my output from the following, which address should I use ? or do 
I just start guessing ?

[root@localhost ~]# i2cdetect -l
i2c-0   unknown         SMBus I801 adapter at 0400              
Algorithm unavailable

[root@localhost ~]# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX 08 XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
30: 30 XX 32 XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX 44 XX XX XX XX XX XX XX XX XX XX XX
50: UU XX UU XX XX XX XX XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX

I am basically capable, though hesitant to start hacking/recompiling my 
kernel ... is there any other way to get this driver working ?

I'm running a 2.6.12-1.1390 kernel .... is the new driver likely to be 
bundled in soon ?

PS. I'm using Fedore Core 4 btw ...

Regards,
Tim.

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Rudolf Marek]

Hi Timothy,

Please can you post here whole output of sensors-detect?
Thanks

I wont be here today/tomorrow. Jean please can you eventualy take over :)?

Regards

Rudolf

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Timothy Findlay]

Hi Ruholf/Jean,

I'm not exactly sure how close the 83627EHG-A is, but I'd be happy to 
try and force one of the other 83627 drivers you've got ?

If you need a datasheet or something, I'm happy to bribe/grovel with 
ASUS/Winbond to see what I can get out of them. Anyway, Here's the full 
output of of sensors-detect:
[root@localhost ~]# sensors-detect

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.

 IF THIS IS AN IBM THINKPAD, PRESS CTRL-C NOW!
 IBM Thinkpads have a severely broken i2c/SMBus implementation, just 
scanning
 the bus will break your Thinkpad forever!
 If this is a non-Thinkpad IBM, we still suggest you press CTRL+C. We have
 had users reporting system breakage on other IBM systems as well.

 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): YES
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): YES
 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): YES
Client found at address 0x08
Client found at address 0x30
Client found at address 0x32
Client found at address 0x44
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
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

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): YES
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 W83697HF'
  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 IT8705F / IT8712F / 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): YES
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! (0x88)
Probing for `Winbond W83627HF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83627THF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83637HF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83697HF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83697SF/UF Super IO PWM'
  Failed! (0x88)
Probing for `Winbond W83L517D Super IO'
  Failed! (0x88)

Do you want to scan for secondary Super I/O sensors? (YES/no): YES
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)

 Sorry, no chips were detected.
 Either your sensors are not supported, or they are
 connected to an I2C bus adapter that we do not support.
 See doc/FAQ, doc/lm_sensors-FAQ.html, or
 http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/lm_sensors-FAQ.html
 (FAQ #4.24.3) for further information.
 If you find out what chips are on your board, see
 http://secure.netroedge.com/~lm78/newdrivers.html for driver status.

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Rudolf Marek]

Hi,

OOps you used quite old version of sensors-detect. Please can you retry with newer one from CVS?

wget http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/prog/detect/sensors-detect
chmod 755 sensors-detect
./sensors-detect

Thanks.

We have contacts at Winbond and I will ask them about the chip.

Regards

Rudolf

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Rudolf Marek]

Hello DZSchen,

We have a request of support from and user with Winbond 83627EHG-A.
Please can you provide a datasheet to us or information how the hardware monitoring part and identification regs differs from
W83627EHF? (If you do not want to disclose the datasheet please give it to me and Jean)

Thank you,

Regards
Rudolf

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Timothy Findlay]

Hi Rudolf,

I've followed your instructions (thankyou!) and it's come up with a 
"Success!" line! Hooray!
Following the instructions, I didnt have a module.conf, so I added it to 
my modprobe.conf instead. There was nothing specific about the second 
bit, so I put it in /etc/rc.d/rc.local

When I rebooted I got the following:
FATAL: Module w83627ehf not found.

I'm running 2.6.12-1_1390_FC4smp kernel, so I ran a "make menuconfig" 
and it was chosen as a module, but I got all sorts of errors when I 
tried a "make modules" and doing a "find ..." under the kernel source I 
couldnt find anything containing 83267 in the filename, so I might be 
missing some pieces. I really didnt want to start customising my kernel 
though! Someone on fedoraforum.org suggested I try the w83627hf driver 
which I did as follows:

[root@localhost rc.d]# modprobe w83627hf
FATAL: Error inserting w83627hf 
(/lib/modules/2.6.12-1.1390_FC4smp/kernel/drivers/i2c/chips/w83627hf.ko): 
No such device

Anyway, here's the long-winded output from sensors-detect:
[root@localhost ~]# ./sensors-detect

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): YES
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 00:1f.3: Intel ICH7
Probe succesfully 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 already loaded.

 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): YES
Client found at address 0x08
Client found at address 0x30
Client found at address 0x32
Client found at address 0x44
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
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

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): YES
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 W83697HF'
  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): YES
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! (0x88)
Probing for `Winbond W83627HF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83627THF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83637HF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83697HF Super IO Sensors'
  Failed! (0x88)
Probing for `Winbond W83697SF/UF Super IO PWM'
  Failed! (0x88)
Probing for `Winbond W83L517D Super IO'
  Failed! (0x88)
Probing for `Winbond W83627EHF Super IO Sensors'
  Success... found at address 0x0290

Do you want to scan for secondary Super I/O sensors? (YES/no): YES
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 Super IO Sensors'
  Failed! (skipping family)

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

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


 I will now generate the commands needed to load the I2C modules.
 Sometimes, a chip is available both through the ISA bus and an I2C bus.
 ISA bus access is faster, but you need to load an additional driver module
 for it. If you have the choice, do you want to use the ISA bus or the
 I2C/SMBus (ISA/smbus)? ISA

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-isa
# I2C chip drivers
# Warning: the required module w83627ehf is not currently installed on 
your system.
# For status of 2.6 kernel ports see 
http://secure.netroedge.com/~lm78/supported.html
# If driver is built-in to the kernel, or unavailable, comment out the 
following line.
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): YES
Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors
for initialization at boot time.
[root@localhost ~]#



Rudolf Marek wrote:

>Hi,
>
>OOps you used quite old version of sensors-detect. Please can you retry with newer one from CVS?
>
>wget http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/prog/detect/sensors-detect
>chmod 755 sensors-detect
>./sensors-detect
>
>Thanks.
>
>We have contacts at Winbond and I will ask them about the chip.
>
>Regards
>
>Rudolf
>  
>

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Jean Delvare]

Hi Timothy,

> I've followed your instructions (thankyou!) and it's come up with a 
> "Success!" line! Hooray!
> Following the instructions, I didnt have a module.conf, so I added it
> to my modprobe.conf instead. There was nothing specific about the
> second bit, so I put it in /etc/rc.d/rc.local
> 
> When I rebooted I got the following:
> FATAL: Module w83627ehf not found.
> 
> I'm running 2.6.12-1_1390_FC4smp kernel, so I ran a "make menuconfig" 
> and it was chosen as a module, (...)

I doubt that. The w83627ehf driver is new in 2.6.13-rc1.

> (...) but I got all sorts of errors when I 
> tried a "make modules" and doing a "find ..." under the kernel source
> I couldnt find anything containing 83267 in the filename, so I might
> be missing some pieces.

This is 627, not 267.

> I really didnt want to start customising my
> kernel  though! Someone on fedoraforum.org suggested I try the
> w83627hf driver  which I did as follows:
> 
> [root@localhost rc.d]# modprobe w83627hf
> FATAL: Error inserting w83627hf 
> (/lib/modules/2.6.12-1.1390_FC4smp/kernel/drivers/i2c/chips/w83627hf.ko):
> No such device

There are two different drivers: the original w83627hf driver supports
the W83627HF, W83627THF, W83637HF and W83697HF chips. The new w83627ehf
driver (partly) supports the W83627EHF chip, and possibly the W83627EHG
as well. All these drivers and chips have very similar names so you have
to pay attention to which driver supports exactly what chips.

The driver you need is really the new w83627ehf driver. You will have to
either upgrade your kernel to 2.6.13-rc1 or later, or backport the
w83627ehf driver to the kernel you are using (we can help you do so, it
should be easy.) The least intrusive approach would be to compile the
backported driver outside of the kernel tree. Let us know if you want to
do that.

> Anyway, here's the long-winded output from sensors-detect:
> [root@localhost ~]# ./sensors-detect
> (...)
> Probing for `Winbond W83627EHF Super IO Sensors'
>   Success... found at address 0x0290

This means that your chip has an ID similar to those of the W83627EHF.
I'd like to know the exact 16-bit ID though, in case we need to
differenciate between both chips in the driver. Could you possibly get
isadump from lm_sensors 2.9.1 or CVS, and run the following command:

isadump -y -k 0x87,0x87 0x2e 0x2f 0x0b

This should give us the exact ID.

Thanks,
-- 
Jean Delvare

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Timothy Findlay]

Hi Jean,


Jean Delvare wrote:

>Hi Timothy,
>I doubt that. The w83627ehf driver is new in 2.6.13-rc1.
>  
>
Correct, I'll be chasing down a new kernel by the looks of it .... I'm 
hanging for the 2.6.13 to finally get released under "yum" ... I noticed 
and -rc3 patch is now available, and I dont mind whipp'n it down and 
having a go if I have to, but I didnt want to run "obscure" kernel 
versions or break too far away from the base updates (if possible).

>This is 627, not 267.
>  
>
whoops! sorry about the typo ..... I'll be more careful in future ....

>>I really didnt want to start customising my
>>kernel  though! Someone on fedoraforum.org suggested I try the
>>w83627hf driver  which I did as follows:
>>
>>[root@localhost rc.d]# modprobe w83627hf
>>FATAL: Error inserting w83627hf 
>>(/lib/modules/2.6.12-1.1390_FC4smp/kernel/drivers/i2c/chips/w83627hf.ko):
>>No such device
>>    
>>
>
>There are two different drivers: the original w83627hf driver supports
>the W83627HF, W83627THF, W83637HF and W83697HF chips. The new w83627ehf
>driver (partly) supports the W83627EHF chip, and possibly the W83627EHG
>as well. All these drivers and chips have very similar names so you have
>to pay attention to which driver supports exactly what chips.
>  
>
Thanks for that, I'll abandon the 83627hf driver idea ....

>The driver you need is really the new w83627ehf driver. You will have to
>either upgrade your kernel to 2.6.13-rc1 or later, or backport the
>w83627ehf driver to the kernel you are using (we can help you do so, it
>should be easy.) The least intrusive approach would be to compile the
>backported driver outside of the kernel tree. Let us know if you want to
>do that.
>  
>
Yep, I'll have a go at backporting then, mind you, the last time I 
touched any C code was in a "Hello World" program! haha!  ... So I'll 
start reading around how to do this, of course any hints/tips would be 
appreciated (though I recognise your time is important, and I dont 
expect to be hand-fed).

I've now downloaded a 22-June-05 build of "w83627ehf.c" (by Greg) from 
GIT (which I dont really get understand)... though not sure how/where to 
complile it yet ... (I'm just wing'n it! haha)

>>Anyway, here's the long-winded output from sensors-detect:
>>[root@localhost ~]# ./sensors-detect
>>(...)
>>Probing for `Winbond W83627EHF Super IO Sensors'
>>  Success... found at address 0x0290
>>    
>>
>This means that your chip has an ID similar to those of the W83627EHF.
>I'd like to know the exact 16-bit ID though, in case we need to
>differenciate between both chips in the driver. Could you possibly get
>isadump from lm_sensors 2.9.1 or CVS, and run the following command:
>
>isadump -y -k 0x87,0x87 0x2e 0x2f 0x0b
>
>This should give us the exact ID.
>  
>

In the mean time, here's the "isadump" you asked for ... I built this 
from the CVS version.

[root@localhost dump]# ./isadump -y -k 0x87,0x87 0x2e 0x2f 0x0b
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff ff ff ff ff ff 0b ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: 88 63 ff 00 44 00 00 ff 50 04 00 00 9a 21 00 ff
30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: 02 90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: c1 17 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[root@localhost dump]#  

Hope that helps! If theres anything else you'd like (photo of the chip 
?) just sing out!

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050716/3740e1f4/attachment.html

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Jean Delvare]

Hi Timothy,

> Yep, I'll have a go at backporting then, mind you, the last time I 
> touched any C code was in a "Hello World" program! haha!  ... So I'll 
> start reading around how to do this, of course any hints/tips would 
> be appreciated (though I recognise your time is important, and I dont 
> expect to be hand-fed).
> 
> I've now downloaded a 22-June-05 build of "w83627ehf.c" (by Greg)
> from GIT (which I dont really get understand)... though not sure
> how/where to complile it yet ... (I'm just wing'n it! haha)

From there, create a Makefile with this line:

obj-m	+= w83627ehf.o

Then run:

make -C /usr/src/linux SUBDIRS=$PWD modules

(replace /usr/src/linux with the path to your real kernel source tree).

That should do it. If there are warnings or errors, you'll have to
figure out how to fix them (or ask us). Then modprobe the new driver and
see how it goes.

> >This should give us the exact ID.
> 
> In the mean time, here's the "isadump" you asked for ... I built this 
> from the CVS version.
> 
> [root@localhost dump]# ./isadump -y -k 0x87,0x87 0x2e 0x2f 0x0b
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: ff ff ff ff ff ff ff 0b ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: 88 63 ff 00 44 00 00 ff 50 04 00 00 9a 21 00 ff

For the records, your chip has ID 0x8863, which matches the W83627EHF
datasheet (it says 0x886x), but oddly enough not the ID of the only
W83627EHF chip we saw so far (which had 0x8853). I have good hope that
both chips will be compatible as far as hardware monitoring is
concerned.

Oh, and remember that my w83627ehf driver is not finished, it only
implements half of the features the chip has, due to a lack of time and
hardware to test my work. Someone else is working on improving it. Or I
might do if someone considers a hardware donation.

-- 
Jean Delvare

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Timothy Findlay]

Hi Jean,

Well, I built it, (had to pull the newer lm_78.c from the 2.6.13 kernel 
also, but I eventually got it to compile ok, and got a .ko file and 
plonked it into:
 /lib/modules/2.6.12.1-1390_FC4smp/kernel/drivers/i2c/chips/
I ran a depmod, and rebooted....

It all appeared to load up ok, and showed up in the /proc/modules 
listing ... but as soon as I loaded up GkRellm, my PC locked. :(
I searched the /var/log/messages but couldnt find any errors or 
anything... If its not too much to ask, can you give me any hints/tips 
to debug it ?

Regards,
Tim.

Jean Delvare wrote:

>Hi Timothy,
>
>  
>
>>Yep, I'll have a go at backporting then, mind you, the last time I 
>>touched any C code was in a "Hello World" program! haha!  ... So I'll 
>>start reading around how to do this, of course any hints/tips would 
>>be appreciated (though I recognise your time is important, and I dont 
>>expect to be hand-fed).
>>
>>I've now downloaded a 22-June-05 build of "w83627ehf.c" (by Greg)
>>from GIT (which I dont really get understand)... though not sure
>>how/where to complile it yet ... (I'm just wing'n it! haha)
>>    
>>
>
>>From there, create a Makefile with this line:
>
>obj-m	+= w83627ehf.o
>
>Then run:
>
>make -C /usr/src/linux SUBDIRS=$PWD modules
>
>(replace /usr/src/linux with the path to your real kernel source tree).
>
>That should do it. If there are warnings or errors, you'll have to
>figure out how to fix them (or ask us). Then modprobe the new driver and
>see how it goes.
>
>  
>
>>>This should give us the exact ID.
>>>      
>>>
>>In the mean time, here's the "isadump" you asked for ... I built this 
>>from the CVS version.
>>
>>[root@localhost dump]# ./isadump -y -k 0x87,0x87 0x2e 0x2f 0x0b
>>     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>00: ff ff ff ff ff ff ff 0b ff ff ff ff ff ff ff ff
>>10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>20: 88 63 ff 00 44 00 00 ff 50 04 00 00 9a 21 00 ff
>>    
>>
>
>For the records, your chip has ID 0x8863, which matches the W83627EHF
>datasheet (it says 0x886x), but oddly enough not the ID of the only
>W83627EHF chip we saw so far (which had 0x8853). I have good hope that
>both chips will be compatible as far as hardware monitoring is
>concerned.
>
>Oh, and remember that my w83627ehf driver is not finished, it only
>implements half of the features the chip has, due to a lack of time and
>hardware to test my work. Someone else is working on improving it. Or I
>might do if someone considers a hardware donation.
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050717/869cd82c/attachment.html

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Jean Delvare]

Hi Timothy,

> Well, I built it, (had to pull the newer lm_78.c from the 2.6.13
> kernel  also, but I eventually got it to compile ok, and got a .ko
> file and  plonked it into:
>  /lib/modules/2.6.12.1-1390_FC4smp/kernel/drivers/i2c/chips/
> I ran a depmod, and rebooted....
> 
> It all appeared to load up ok, and showed up in the /proc/modules 
> listing ... but as soon as I loaded up GkRellm, my PC locked. :(
> I searched the /var/log/messages but couldnt find any errors or 
> anything... If its not too much to ask, can you give me any
> hints/tips to debug it ?

Let's try. First, can you tell us why you needed to backport lm78.c? I
don't get it. The w83627ehf driver is standalone and certainly doesn't
need lm78 is any way.

Second, please don't use gkrellm for testing, as this program is not
supported by us. Please use the files in /sys/bus/i2c/devices directly,
using "cat" and "echo". At least we will know which action precisely did
cause the problem.

Third, please enable as much i2c debugging as possible. This can be done
in the I2C menu with make menuconfig. also Add
#define DEBUG 1
at the top of the w83627ehf.c file.

This should let us gather some information.

Also, if you had to change something to the w83627ehf file when
backporting it, please tell us what exactly you did. If you could share
the exact file you are using, it will help us help you.

-- 
Jean Delvare

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Jean Delvare]

Hi Timothy,

On 2005-07-19, Timothy Findlay wrote:
> My correction sorry, it was actually lm78.h that I needed. There's an
> include directive at the top of the w83627ehf.c file.

You really mean lm75.h then. I now remember the w83627ehf driver needs
it. Should be OK though.

> usr/src/lm-sensors/tim/w83627ehf.c:525: warning: initialization from
> incompatible pointer type

I think I see what happens here. We had a recent change in the sysfs
callback function parameters. You probably need to revert them for your
older kernel. Search for callback functions with the following
parameters:

static ssize_t
show_reg_fan_##offset(struct device *dev, struct device_attribute *attr,
                      char *buf)

And drop the "struct device_attribute *attr" one, resulting in:

static ssize_t
show_reg_fan_##offset(struct device *dev, char *buf)

Do that for all warnings you had when compiling, and hopefully the driver
should then work.

And a note for next time... Never assume that warnings are OK when
porting a driver. Drivers usually compile without any warning (at least
all i2c and hardware monitoring drivers do), so new warnings are always
the sign that something else changed and the driver code needs to be
updated to match that change. That was the case here.

Oh, and please CC the sensors list on replies.

--
Jean Delvare

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Timothy Findlay]

Hi Jean,

Jean Delvare wrote:

>You really mean lm75.h then. I now remember the w83627ehf driver needs
>it. Should be OK though.
>  
>
Your correct as always, my apologies for such sloopy information, it 
seems the only time I get to sit and tinker with this is  past midnight, 
by which stage I'm half asleep. :(

>I think I see what happens here. We had a recent change in the sysfs
>callback function parameters. You probably need to revert them for your
>older kernel. Search for callback functions with the following
>parameters:
>
>static ssize_t
>show_reg_fan_##offset(struct device *dev, struct device_attribute *attr,
>                      char *buf)
>
>And drop the "struct device_attribute *attr" one, resulting in:
>
>static ssize_t
>show_reg_fan_##offset(struct device *dev, char *buf)
>
>Do that for all warnings you had when compiling, and hopefully the driver
>should then work.
>  
>
HOORAY! .. Your right-on! I tried searching my kernel source for 
definitions/prototypes for these functions, but couldnt find a thing, so 
I just hacked away at the source, removing all function parameters with 
offending struct, and then tried compiling it... no errors! :)

>And a note for next time... Never assume that warnings are OK when
>porting a driver. Drivers usually compile without any warning (at least
>all i2c and hardware monitoring drivers do), so new warnings are always
>the sign that something else changed and the driver code needs to be
>updated to match that change. That was the case here.
>  
>
Very true, alot of open source packages I build usually have warnings of 
some type, over time I get lazy and stop checking or trying to fix them. 
After the changes mentioned, the module compiled perfect. I'll attach a 
session log showing what I did, and I'll attach my butchered up module 
code (dont get mad! I tried to be careful with it!).

>Oh, and please CC the sensors list on replies.
>  
>
Certainly, as mentioned initially, I'm usually half asleep when I've 
been working on this.

My sincere thanks to you (and greg) for your help getting this working, 
I'm absolutely elated. I've fired up my fravorite gkRellm, and its 
picked up all the sensors perfectly. I did notice it didnt pick up the 
voltages (not that I'm all that interested in voltage), if I only 
understood the code a little better (and the spec provided by Winbond), 
I'd be happy to keep working on the driver to add anything else in. But 
I'm not sure I understand hex adressing that well, and I'd probably be a 
hinderance more than a help. Having said that, if theres anything I can 
do to help, just let me know. (sorry I dont have a spare P5WD2 to send 
you I'm afraid)

Again, sincere thanks,
Tim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_log2.log
Type: text/x-log
Size: 4585 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050720/f84d72ab/build_log2-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83627ehf.c
Type: text/x-csrc
Size: 23532 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050720/f84d72ab/w83627ehf-0001.bin

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Rudolf Marek]

> For the records, your chip has ID 0x8863, which matches the W83627EHF
> datasheet (it says 0x886x), but oddly enough not the ID of the only
> W83627EHF chip we saw so far (which had 0x8853). I have good hope that
> both chips will be compatible as far as hardware monitoring is
> concerned.

And my records. I just found out that G versions of all winbond chips are pb-free (lead-free)
Source:

http://www.marthel.pl/en/listing.php?sstr=%25

Regards

Rudolf

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Jean Delvare]

Hi Timothy,

> My sincere thanks to you (and greg) for your help getting this
> working, I'm absolutely elated. I've fired up my fravorite gkRellm,
> and its picked up all the sensors perfectly.

Glad to know it works :)

I'll go update our documentation to mention that the W83627EHF and
W83627EHG chips are compatible.

> I did notice it didnt pick up the  voltages (not that I'm all that
> interested in voltage),

The driver is only half coded. I did fan and temperature monitoring,
because I think that's what most people are interested in. I'd have done
more but had many other things to do and no hardware to test my code so
my progress was too slow.

> if I only understood the code a little better (and the spec provided
> by Winbond), I'd be happy to keep working on the driver to add
> anything else in. But I'm not sure I understand hex adressing that
> well, and I'd probably be a hinderance more than a help. Having said
> that, if theres anything I can do to help, just let me know. (sorry I
> dont have a spare P5WD2 to send you I'm afraid)

Well, I guess you can get in touch with Cadu, who is working on
extending this driver. If you can test his code when he is done, I guess
he will appreciate.

If someone is willing to send me a socket 939 motherboard with a
W83627EHF or W83627EHG on board, I will be happy to go on hacking the
driver myself.

-- 
Jean Delvare

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Carlos Eduardo Medaglia Dyonisio]

On Sun, 24 Jul 2005 20:20:30 +0200
Jean Delvare <khali@linux-fr.org> wrote:

Hi all!

> > I did notice it didnt pick up the  voltages (not that I'm all that
> > interested in voltage),
> 
> The driver is only half coded. I did fan and temperature monitoring,
> because I think that's what most people are interested in. I'd have done
> more but had many other things to do and no hardware to test my code so
> my progress was too slow.

Sorry. I was working on it (and it's easy to make), but in the last
weeks I was so busy... I'm so sorry.

> > if I only understood the code a little better (and the spec provided
> > by Winbond), I'd be happy to keep working on the driver to add
> > anything else in. But I'm not sure I understand hex adressing that
> > well, and I'd probably be a hinderance more than a help. Having said
> > that, if theres anything I can do to help, just let me know. (sorry I
> > dont have a spare P5WD2 to send you I'm afraid)
> 
> Well, I guess you can get in touch with Cadu, who is working on
> extending this driver. If you can test his code when he is done, I guess
> he will appreciate.
> 
> If someone is willing to send me a socket 939 motherboard with a
> W83627EHF or W83627EHG on board, I will be happy to go on hacking the
> driver myself.

In this week I will have time to work on it. I hope I will have a patch
this week with voltage support. Timothy, please stay in touch with me.
I'll be pleasure if you can help me to test the code (and maybe to hack
the code ;) )!

Thanks!
Cadu

[lm-sensors] ASUS P5WD2 Premium - Winbond 83627EHG-A

[Jean Delvare]

Hi Cadu,

> > The driver is only half coded. I did fan and temperature monitoring,
> > because I think that's what most people are interested in. I'd have
> > done more but had many other things to do and no hardware to test my
> > code so my progress was too slow.
> 
> Sorry. I was working on it (and it's easy to make), but in the last
> weeks I was so busy... I'm so sorry.

Don't be sorry, it's no problem. Take your time. If people think it's
not fast enough, then they should code it themselves.

> In this week I will have time to work on it. I hope I will have a
> patch this week with voltage support. Timothy, please stay in touch
> with me. I'll be pleasure if you can help me to test the code (and
> maybe to hack the code ;) )!

Please make sure your base your patches on something relatively recent
(2.6.13-rc3 or better), else we will face problems when merging your
code in the current driver.

Thanks,
-- 
Jean Delvare