Date: Wed, 21 Dec 2005 09:49:48 +0200 From: Ruslan Ermilov <ru@freebsd.org> To: Artemiev Igor <ai@bmc.brk.ru> Cc: freebsd-current@freebsd.org Subject: Re: New nfpm.c driver available for testing Message-ID: <20051221074948.GI84996@ip.net.ua> In-Reply-To: <20051220091227.4ce7dfa2.ai@bmc.brk.ru> References: <20051218173028.GV41326@ip.net.ua> <20051220091227.4ce7dfa2.ai@bmc.brk.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--oxV4ZoPwBLqAyY+a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2005 at 09:12:27AM +0300, Artemiev Igor wrote: > I've recompiled your nfm with CFLAGS+=3D-DDEBUG. >=20 You'd better try the next version, but it works the same for nForce's. > ai@home$sudo ./smbtest /dev/smb0 > found slave device 8 > found slave device 80 > found slave device 82 >=20 OK. > ai@home$sudo ./smbtest /dev/smb1 > found slave device 8 > found slave device 45 > found slave device 55 > found slave device 72 > found slave device 73 > found slave device 97 > found slave device 127 >=20 OK. > smbtest gives me only a garbage. >=20 What do you mean? It found "SMBus host" (device 8) and some others. > When I tried mbmon without - > DSMBUS_IOCTL, it worked with SMBus through the /dev/io and "detected" > slave address for the first smb controller as 0x5a >=20 This is the shifted address, try "mbmon -A -D", it will display both shifted and real slave device addresses, like this: # ./mbmon -S -D Probe Request: none >>> Testing Reg's at SMBus <<< SMBus slave 0xA0(0x50) found... SMBus slave 0xA2(0x51) found... SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured > Then I've run mbmon -A -d. > It didn't find any sensors, but here is the driver's debug message: > Dec 19 22:17:57 home kernel: nfpm: STS=3D0x10 > Dec 19 22:17:57 home kernel: nfpm: READB from 0x10, cmd=3D0x40, byte=3D0x= 0, >=20 Good. > Well, It's a "Device Address Not Acknowledged" error. >=20 Yes. > If I shift the > slave address for reading, it works, and status register contains 0x80. >=20 mbmon already shifts it, and our smb(4) is dumb in that it expects the address already shifted. (Linux does better here.) > Yet, for writing I still have an 0x10. >=20 In my case, I have (note that all addresses are even because they are already "<< 1" shifted by mbmon). nfsmb: READB from 0x9e, cmd=3D0x0, byte=3D0xff, error=3D0x4 nfsmb: STS=3D0x10 nfsmb: READB from 0xa0, cmd=3D0x0, byte=3D0x80, error=3D0x0 nfsmb: STS=3D0x0 nfsmb: READB from 0xa2, cmd=3D0x0, byte=3D0x80, error=3D0x0 nfsmb: STS=3D0x0 nfsmb: READB from 0xa4, cmd=3D0x0, byte=3D0xff, error=3D0x4 nfsmb: STS=3D0x10 (I only copied cmd=3D0x0.) This corresponds to shifted addresses 0xa0 and 0xa2 (devices 0x50 and 0x51). > The documentation for AMD-8111 > controller explains this by not-reset operational status before the > controller checks the address. >=20 Yes, AMD-8111 is another story. It uses EC-based access to SMBus registers, while nForce2/3/4 appear to provice I/O based SMBus register access, and that matches the following info from lm-sensors: http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-nforce2 # Notes # ----- #=20 # The SMBus adapter in the nForce2/3/4 chipset seems to be very similar to = the # SMBus 2.0 adapter in the AMD-8111 southbridge. However, I could only get = the # driver to work with direct I/O access, which is different to the EC inter= face # of the AMD-8111. # Tested on Asus A7N8X. The ACPI DSDT table of the Asus A7N8X lists two SMB= uses, # both of which are supported by this driver. > Btw, why in nfpm_wait you're polling SMB_PRTCL instead of SMB_STS?=20 >=20 Because that's what the ACPI spec says to do, see section 12.9 of the ACPI 3.0 spec. (ACPI 2.0c spec is similar.) I've solved the problem with using non-standard BARs, and will update the patch shortly. The PEC (Parity Error Checking) is not supported; we'd need to grow the support for it in smb(4) first. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --oxV4ZoPwBLqAyY+a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDqQkcqRfpzJluFF4RArYkAJwN4cASidJO6tIK+tlgRZA9zRhXdwCeOV2V GGuzQT/JB+Um1Xd6yE6uEbI= =lPCa -----END PGP SIGNATURE----- --oxV4ZoPwBLqAyY+a--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051221074948.GI84996>