Re: cvs commit: src/sys/pci amdpm.c

On Thu, Dec 15, 2005 at 01:06:57PM -0500, John Baldwin wrote:
> On Thursday 15 December 2005 01:36 am, Artemiev Igor wrote:
> > > No go on Asus SK8N:
> > >
> > > amdpm0: <nForce2/3/4 MCP SMBus Controller> port
> > > 0x5000-0x503f,0x5040-0x507f,0x5000-0x501f at device 1.1 on pci0
> > > amdpm0: could not map i/o space device_attach: amdpm0 attach returned
> > > 6
> > >
> > > ... with amdpm.ko loaded from the loader or from multiuser,
> > > does not matter.
> > >
> > > amdpm0_at_pci0:1:1:        class=0x0c0500 card=0x80c51043
> > > chip=0x00d410de rev=0xa4 hdr=0x00 vendor   = 'NVIDIA Corporation'
> > >     device   = 'nForce MCP3? SMBus Controller'
> > >     class    = serial bus
> > >     subclass = SMBus
> > >
> > > Has this been ported from Linux, or do you have specs available
> > > for these parts?  (I never succeeded in finding them.)
> >
> > I do not have a full documentation on this chipset, I used an
> > lm_sensors' sources when writing driver. Because their algorithms were
> > very close, and in lm_sensors support for nForce3/ nForce4 was
> > declared, I've added them too, but didn't test it. Soon I'll get myself
> > a motherboard with nForce3, then I will be able to check those
> > problems. Right now, I think that it may be something with ACPI.
> > Probably, chipsets revisions are different. I'll investigate it further.
> > Also, there is a chance something is wrong with a size of a bus
> > resource block, allocated at PCI bus for the device. I was  thinking
> > that the memory size will be similar to AMD-8111, and it was so for
> > nForce2. Yet, for the new versions the assumption is probably false.
> > Try this patch:
> > http://stalker.bmc.brk.ru/~ai/patches/amdpm.nforce34.diff
> 
OK, I looked some more, and I doubt the usefullness of the nForce-2/3/4
support in its current shape.  Perhaps I'm mistaken and you can shed a
light on this.  :-)

The amdpm(4) driver originally supported AMD-756's PMC SMBus 1.0.
Later, AMD-8111 support was added.  All of these AMDs seem to support
both SMBus 2.0 and SMBus 1.0 interfaces, and the driver uses the SMBus
1.0 interface (offset 0xe0).   The nForce seems to also support SMBus
1.0 interface (offset 0).  At least, the following lm_sensors pages
amd AMD-8111 datasheet confirm this:

	http://www.lm-sensors.org/supported.html
	http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd756
	http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd8111

Now, the same supported.html page and googling says that nForce2/3/4 MCPs
all use SMBus 2.0 interface similar to AMD-8111 SMBus 2.0 interface.  But
we don't support SMBus 2.0 interface in amdpm(4)!  (lm_sensors, OTOH, does
implement SMBus 2.0.).

Now about xmbmon...  The SMBus support in xmbmon is exclusively for
FreeBSD, and AMD-8111/nForce2 support through SMBus was added at the
same time:

ChangeLog: * The AMD8111 and NVidia nForce2 SMBus access is supported
             (by information from Alex van Kaam).

Obviously, nForce2 couldn't have been tested with an unpatched amdpm.c,
so I don't know what magic Alex van Kaam used to test nForce2 SMBus.

I don't know about nForce2, perhaps it implements SMBus 1.0 similar to
nForce (I can't find information anywhere), but it doesn't match
lm_sensors sources which uses SMBus 2.0 on nForce2/3/4, and uses
different drivers for AMD-8111(SMBus 1.0)/nForce and nForce2/3/4.

Igor, can you show me the output of "mbmon -S -c10 1" on your nForce2
based machine?  Because, like I said, I get the nonsense with nForce3
Pro150, after solving the "could not map i/o space" problem, and I
think this may be due to accessing SMBus 2.0 as SMBus 1.0.


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer