Hi,
I'm trying to get lm-sensors running on a 2.6.7 kernel (yes, I know that's a
couple of releases behind...) on a Compaq Evo D51C PC.
On an identical machine which is running 2.4.27, I have to use the
lm-sensors supplied "p4b_smbus" module to enable the SMBus/PCI interface
before the i2c-i801 driver will load; it would appear that this machine
hides it much like the Asus motherboards do.
In the kernel 2.6 world, that module doesn't compile; and my research leads
me to understand that similar functionality is built into the quirks.c code.
Looking at the quirks.c code, I can see functions like
"asus_hides_smbus_hostbridge" and "asus_hides_smbus_lpc", which use a lookup
table to determine whether or not to set the appropriate flag and toggle the
PCI bits to enable the SMbus. Obviously, I need to include the appropriate
checks (and associated entries in the pci_fixups struct) to get this applied
to my machine at kernel load time (I've seen some patches on the lkml
recently that seem to do exactly this - quite happy to try and add this
functionality). For example, here is an extract from a similar patch:
+ if ((dev->device == PCI_DEVICE_ID_INTEL_82865_HB) &&
+ (dev->subsystem_device == 0x12bc)) /* HP D330L */
+ asus_hides_smbus = 1;
My problem is that I don't understand how the "dev->device" and
"dev->subsystem_device" values are obtained. Where/How do I read the actual
values from my machine so that I can add them into the code tables?
Any help would be appreciated; as would "cc"ing replies directly to me (I
don't subscribe to lkml, and may miss replies when searching via MARC).
Thanks,
James Roberts-Thomson
----------
Adult: A person that has stopped growing at both ends but not in the
middle.
This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.
On Mon, 27 Sep 2004 11:06:15 +1200 Roberts-Thomson, James wrote:
| Looking at the quirks.c code, I can see functions like
| "asus_hides_smbus_hostbridge" and "asus_hides_smbus_lpc", which use a lookup
| table to determine whether or not to set the appropriate flag and toggle the
| PCI bits to enable the SMbus. Obviously, I need to include the appropriate
| checks (and associated entries in the pci_fixups struct) to get this applied
| to my machine at kernel load time (I've seen some patches on the lkml
| recently that seem to do exactly this - quite happy to try and add this
| functionality). For example, here is an extract from a similar patch:
|
| + if ((dev->device == PCI_DEVICE_ID_INTEL_82865_HB) &&
| + (dev->subsystem_device == 0x12bc)) /* HP D330L */
| + asus_hides_smbus = 1;
|
| My problem is that I don't understand how the "dev->device" and
| "dev->subsystem_device" values are obtained. Where/How do I read the actual
| values from my machine so that I can add them into the code tables?
Try "lspci -n".
| Any help would be appreciated; as would "cc"ing replies directly to me (I
| don't subscribe to lkml, and may miss replies when searching via MARC).
|
|
| This communication is confidential and may contain privileged material.
| If you are not the intended recipient you must not use, disclose, copy or retain it.
| If you have received it in error please immediately notify me by return email
| and delete the emails.
N.B.: I may have received this non-confidential email in error.
--
~Randy
Randy Dunlap wrote:
> Try "lspci -n".
OK, on the 2.4.27 machine, lspci displays an entry for the SMBus device
(once the p4b_smbus module is loaded), thus:
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 01)
which lspci -n identifies as
0000:00:1f.3 Class 0c05: 8086:24c3 (rev 01)
In pci_ids.h, 0x0c05 is "PCI_CLASS_SERIAL_SMBUS", and "24c3" is a
"PCI_DEVICE_ID_INTEL_82801DB_3". So, thanks to your help, I've found the
dev->device entry I need; but where do I get the dev->subsystem_device value
from? I'm willing to believe I have the information and that I just don't
recognise what it is - that is my problem.
Thanks for the help so far, though!
> | This communication is confidential and may contain [...etc...]
> N.B.: I may have received this non-confidential email in error.
(Deep Sigh). A standard disclaimer inserted by my workplace's email
gateway, I'm afraid. I have no control over this. Would it help if I added
the following ?
Despite any later disclaimer to the contrary, this email is not confidential
and does not contain privleged material.
Thanks,
James Roberts-Thomson
This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.
On Mon, 27 Sep 2004 11:53:00 +1200 Roberts-Thomson, James wrote:
| Randy Dunlap wrote:
|
| > Try "lspci -n".
|
| OK, on the 2.4.27 machine, lspci displays an entry for the SMBus device
| (once the p4b_smbus module is loaded), thus:
|
| 0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
| Controller (rev 01)
|
| which lspci -n identifies as
|
| 0000:00:1f.3 Class 0c05: 8086:24c3 (rev 01)
|
| In pci_ids.h, 0x0c05 is "PCI_CLASS_SERIAL_SMBUS", and "24c3" is a
| "PCI_DEVICE_ID_INTEL_82801DB_3". So, thanks to your help, I've found the
| dev->device entry I need; but where do I get the dev->subsystem_device value
| from? I'm willing to believe I have the information and that I just don't
| recognise what it is - that is my problem.
Yes, lspci will show that also.
lspci -x -d 8086:24c3 (2443 in my case, below)
0000:00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 05)
00: 86 80 43 24 01 00 80 02 05 00 05 0c 00 00 00 00
vv vv dd dd
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 ef 00 00 00 00 00 00 00 00 00 00 86 80 54 50
yy yy zz zz
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 02 00 00
Vendor ID is vvvv. Device ID is dddd.
Subsystem vendor ID is yyyy and subsystem device ID is zzzz.
All multi-byte fields are in low-high order (little endian)
(in the PCI header).
--
~Randy
Randy,
Thanks so much for your help.
> lspci -x -d 8086:24c3
OK, that (with the explanation of the values) helped a lot. I've got a
subsystem vendor of 0e11 and subsystem device of 00b8. I guess that
explains the values from "pcitweak -l", which where
PCI: 00:1f:3: chip 8086,24c3 card 0e11,00b8 rev 01 class 0c,05,00 hdr 00
As I said earlier, I'm willing to believe I had the information and didn't
recognise it; and I guess we confirmed that.
OK, now to patch and recompile the kernel, and see how we go....
If this works, I'll submit the patch for inclusion in "quirks.c" - I'll
leave it up to the appropriate maintainers to decide if they want it or
not....
Thanks again,
James Roberts-Thomson
LKML Readers: Please ignore the following disclaimer - this email is
explicitly declared to be non confidential and does not contain privileged
information.
This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.