mlo wrote: > Hi, > > I stumbled upon an exchange of messages on this list concerning sensors > on a Compaq evo W6000 (dating back 15-May-2006) where Rudolf Marek gave > a procedure to activate a possibly existing but hidden SMBUS where > sensors could be attached. I have an evo W6000 and could run the > proposed procedure and here are the results. Good. >> Quick howto: >> 1) lspci -n will tell you the IDs, you will need: pci Id of 0000:00:1f.0 >> >> first part is 8086: which is intel, second part is the requested ID >> >> 2) quick hack the quirks.c >> >> change this: >> static int __initdata asus_hides_smbus = 0; >> to >> static int __initdata asus_hides_smbus = 1; >> >> Then recompile and run. you should now see the smbus. If not then take the pci >> ID from step 1 and change following line: >> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0, >> asus_hides_smbus_lpc ); >> >> into >> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0xNNNN, asus_hides_smbus_lpc ); >> >> where NNNN is you ID number. > > > For the evo, NNNN is 0x2440 and is already in the quirk.c as PCI_DEVICE_ID_INTEL_82801BA_0 > Therefore, the only thing to change in quirk.c was to set asus_hides_smbus=1 ... > and it worked, lspci now reports the SMBUS: > > 00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 04) > Subsystem: Compaq Computer Corporation Evo W6000 > Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- > Interrupt: pin B routed to IRQ 5 > Region 4: I/O ports at fc00 [size=16] Good2 > and sensors-detect can configure 2 chips so that "sensors" report something like: > > max1617-i2c-0-18 > Adapter: SMBus I801 adapter at fc00 > > Board: +53??C (low = -55??C, high = +127??C) > CPU: +61??C (low = -55??C, high = +64??C) > > adm1023-i2c-0-4c > Adapter: SMBus I801 adapter at fc00 > > Board: +35??C (low = -55??C, high = +127??C) > CPU: +37??C (low = -55??C, high = +62??C) > > >> If you are able to see the smbus device run sensors-detect and please report if >> you found some useful devices. If so, proper quirk needs to be developed. You >> should provide: >> lspci >> lspci -n >> lspci -v -v -v >> lspci -v -v -v -n > > > Then, I tried to adapt the quirk.c in the same way that it is done for the other > systems that suffer from the hidden SMBUS issue and understood that the operation is done in 2 steps: > 1 - identify if the computer model suffers from the problem by comparing the hostbridge > subsystem_vendor and subsystem_device with those known to be problematic. > > 2 - if first test succeeds, then write some magic value in pci register when processing the > LPC device. > > Having understood this, the change should be easy to do but ... the hostbridge of the evo W6000 > does not report a subsystem vendor and device: > > # lspci -v -v -v -n > 00:00.0 Class 0600: 8086:2531 (rev 04) > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+ > Latency: 0 > Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M] > Capabilities: [a0] AGP version 2.0 > Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 > Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- Rate=x4 > ... > > # lspci -v -v -v > 00:00.0 Host bridge: Intel Corporation 82860 860 (Wombat) Chipset Host Bridge (MCH) (rev 04) > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR+ > Latency: 0 > Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M] > Capabilities: [a0] AGP version 2.0 > Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 > Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- Rate=x4 > > And the LPC does not have subsystem ID either. > > # lspci -v -v -v > 00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 04) > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR- > > > Also there are no PCI device processed before the LPC that have subsystem info (otherwise they could be used instead of the HB) > > After the LPC device, there are devices with subsystem information such as the IDE interface: > > 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 04) (prog-if 80 [Master]) > Subsystem: Compaq Computer Corporation Unknown device 0077 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- > Latency: 0 > Region 4: I/O ports at 2040 [size=16] > > I wonder how this problem can be worked around: > I thought about several solutions but I wonder if they may work: > > idea 1 - do the PCI magic when stumbling upon the IDE interface (it is the first device that reports subsystem IDs that probably correspond indirectly to the mainboard: 0077 ) > => could it work (playing with PCI after having configured the LPC and also what is the risk that 0077 is used in another system than evo W6000) ? Well only compaq people knows it... > > Idea 2 - detect the type of mainboard thanks to something else than the subsystem ID of the HB. > => I'm not certain where this info could be obtained reliably nor how (BIOS ?) DMI is the answer > > Idea 3 - replace the first step of the detection by a boot parameter > (one would set "asus_hides_smbus=1" in the boot parameters if he has a hardware with hidden SMBUS that cannot be quirk'ed because it's HB does not report subsystem IDs such as evo W6000) Hmm this will work only for the listed IDs > > > If someone could shed some light on the possible side effects of such solutions or give other tracks, it would be great. > If nothing safe can be found (that does not risk to make quirk.c bring problem on some systems that work today), I guess that people will have to modify the quirk.c to activate the SMBUS on such hardware. Well I think we do not want to activate the SMBUs on notebooks because it may interfere with the ACPI or SMBIOS code. - Two diffrent "drivers" talking to same device is no-good. So I would suggest to leave it as it is unless there are strong reasons why the SMBus has to be un-hidden. Regards Rudolf
