cvs commit: src/sys/pci amdpm.c

[John Baldwin]

On Friday 16 December 2005 10:03 am, Ruslan Ermilov wrote:
> ru          2005-12-16 15:03:16 UTC
>
>   FreeBSD src repository
>
>   Modified files:
>     sys/pci              amdpm.c
>   Log:
>   Fix PCI ID of the AMD-8111 System Management controller so it matches
>   SMBus 1.0 and not SMBus 2.0.
>
>   AMD-8111 hub (datasheet is publically available) implements both SMBus
>   2.0 (a separate PCI device) and SMBus 1.0 (a subfunction of the System
>   Management Controller device with the base I/O address is accessible
>   through the CSR 0x58).  This driver only supports AMD-756 SMBus 1.0
>   compatible devices.
>
>   With the patched sysutils/xmbmon port (to also fix PCI ID and to enable
>   smb(4) support), I now get:
>
>   pciconf:
>   none0 at pci0:7:2: class=0x0c0500 card=0x746a1022 chip=0x746a1022 rev=0x02
> hdr=0x00 vendor   = 'Advanced Micro Devices (AMD)'
>       device   = 'AMD-8111 SMBus 2.0 Controller'
>       class    = serial bus
>       subclass = SMBus
>   amdpm0 at pci0:7:3:        class=0x068000 card=0x746b1022 chip=0x746b1022
> rev=0x05 hdr=0x00 vendor   = 'Advanced Micro Devices (AMD)'
>       device   = 'AMD-8111 ACPI System Management Controller'
>       class    = bridge
>
>   dmesg:
>   amdpm0: <AMD 756/766/768/8111 Power Management Controller> port
> 0x10e0-0x10ff at device 7.3 on pci0 smbus0: <System Management Bus> on
> amdpm0
>
>   # mbmon -A -d
>   Summary of Detection:
>    * SMB monitor(s)[ioctl:AMD8111]:
>     ** Winbond Chip W83627HF/THF/THF-A found at slave address: 0x50.
>     ** Analog Dev. Chip ADM1027 found at slave address: 0x5C.
>    * ISA monitor(s):
>     ** Winbond Chip W83627HF/THF/THF-A found.
>
>   I think the confusion comes from the fact that nobody really tried
>   SMBus with xmbmon :-), since sysutils/xmbmon port doesn't come with
>   SMBus support enabled, neither in FreeBSD 4, nor in later versions,
>   so mbmon(1) was just showing the values from the Winbond sensors
>   accessible through the ISA I/O method (mbmon -I), for me anyway.
>
>   On my test machine, the amdpm(4) didn't even attach due to I/O port
>   allocation failure (who knows what the hell it read from CSR 0x58
>   of the SMBus 2.0 device :-), which isn't in the CSR space).
>
>   I've also checked that lm_sensors.org uses correct PCI ID for SMBus
>   1.0 of AMD-8111:
>
>   i2c-amd756.c:   {PCI_VENDOR_ID_AMD, 0x746B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> AMD8111 },
>
>   This driver is analogous to our amdpm.c which supports SMBus 1.0
>   AMD-756 and compatible devices, including SMBus 1.0 on AMD-8111.
>
>   i2c-amd8111.c:  { 0x1022, 0x746a, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
>
>   This driver is analogous to nForce-2/3/4, i2c-nforce2.c, which
>   supports SMBus 2.0, and which our amdpm.c does NOT support
>   (SMBus 2.0 uses a different, ACPI-unified, API to talk to SMBus).
>   At least I know for sure it doesn't work with my nForce3.  :-)
>
>   (The xmbmon port will be fixed to correct the PCI ID too and to
>   enable the smb(4) support.)

So should the other stuff I just committed be axed then until the ACPI SMBUS 
stuff is added?

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org