From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 07:54:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B8B516A41F for ; Wed, 21 Dec 2005 07:54:47 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71DED43D53 for ; Wed, 21 Dec 2005 07:54:46 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBL7sLhR004255; Wed, 21 Dec 2005 09:54:21 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 64174-03-2; Wed, 21 Dec 2005 09:54:19 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBL7ndxt004138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 09:49:39 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBL7nmRM055118; Wed, 21 Dec 2005 09:49:48 +0200 (EET) (envelope-from ru) Date: Wed, 21 Dec 2005 09:49:48 +0200 From: Ruslan Ermilov To: Artemiev Igor Message-ID: <20051221074948.GI84996@ip.net.ua> References: <20051218173028.GV41326@ip.net.ua> <20051220091227.4ce7dfa2.ai@bmc.brk.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oxV4ZoPwBLqAyY+a" Content-Disposition: inline In-Reply-To: <20051220091227.4ce7dfa2.ai@bmc.brk.ru> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-current@freebsd.org Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 07:54:47 -0000 --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--