Re: New nfpm.c driver available for testing

On Tue, Dec 20, 2005 at 09:12:27AM +0300, Artemiev Igor wrote:
> I've recompiled your  nfm with CFLAGS+=-DDEBUG.
> 
You'd better try the next version, but it works the same for
nForce's.

> ai_at_home$sudo ./smbtest /dev/smb0
> found slave device 8
> found slave device 80
> found slave device 82
> 
OK.

> ai_at_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
> 
OK.

> smbtest gives me only a garbage.
> 
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
> 
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=0x10
> Dec 19 22:17:57 home kernel: nfpm: READB from 0x10, cmd=0x40, byte=0x0,
> 
Good.

> Well, It's a  "Device Address Not Acknowledged" error.
> 
Yes.

> If I shift the
> slave address for reading, it works, and status register contains 0x80.
> 
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.
> 
In my case, I have (note that all addresses are even because
they are already "<< 1" shifted by mbmon).

nfsmb: READB from 0x9e, cmd=0x0, byte=0xff, error=0x4
nfsmb: STS=0x10
nfsmb: READB from 0xa0, cmd=0x0, byte=0x80, error=0x0
nfsmb: STS=0x0
nfsmb: READB from 0xa2, cmd=0x0, byte=0x80, error=0x0
nfsmb: STS=0x0
nfsmb: READB from 0xa4, cmd=0x0, byte=0xff, error=0x4
nfsmb: STS=0x10

(I only copied cmd=0x0.)  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.
> 
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
# -----
# 
# 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 interface
# of the AMD-8111.
# Tested on Asus A7N8X. The ACPI DSDT table of the Asus A7N8X lists two SMBuses,
# both of which are supported by this driver.

> Btw, why in nfpm_wait you're polling SMB_PRTCL instead of SMB_STS? 
> 
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,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer