Date: Mon, 19 Dec 2005 11:12:47 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Artemiev Igor <ai@bmc.brk.ru> Subject: Re: cvs commit: src/sys/pci amdpm.c Message-ID: <200512191112.48905.jhb@freebsd.org> In-Reply-To: <20051218082002.GR41326@ip.net.ua> References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051217084836.71eb86e6.ai@bmc.brk.ru> <20051218082002.GR41326@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 18 December 2005 03:20 am, Ruslan Ermilov wrote: > On Sat, Dec 17, 2005 at 08:48:36AM +0300, Artemiev Igor wrote: > > > i2c-amd8111.c and i2c-nforce2.c are indeed very similar, because they > > > both use SMBus 2.0 API. :-) > > > > ... > > > > > See how the offset 0x2 register means completely different things. > > > > Yep. Sorry for this little diversion :-(( > > I wrote new driver, nfpm, which completely based on linux`s i2c- > > nforce2 driver. Can you review it? > > http://stalker.bmc.brk.ru/~ai/patches/nfpm.c > > You took lm_sensors sources too literally, without accounting for > FreeBSD details. In FreeBSD (dumb, but it's too late to change > that now), the slave 6-bit addresses are expected by smbus(4) > methods already shifted, (addr << 1). My incomplete (but enough > for xmbmon to work) version is attached and appears to work, > according to the debugging output from the driver, but I eihter > don't have any recognizable sensors on either of SMBusses I have > available for testing, or something is very odd about it. It also > supports AMD-8111 SMBus 2.0 controller. > > Note that I don't call bus_set_resource() in my driver. In my > case (nVidia nForce3 Pro150 and AMD-8111 SMBus 2.0), the I/O port > resources have already been allocated, > > nfpm0 pnpinfo vendor=0x10de device=0x00d4 subvendor=0x1043 subdevice=0x80c5 > class=0x0c0500 at slot=1 function=1 handle=\_SB_.PCI0.SMBS I/O ports: > 0x5000-0x503f > 0x5040-0x507f > > so bus_set_resource() were effectively trying to add 0x5000-... > and 0x5040-... ranges again, and that causes problems for > bus_alloc_resource_any() later. Yes, that one part uses PCIR_BAR(1) (please use that rather than 0x14 for the rid) and that already works. The bus_set_resource() hacks need to go away I think, either that or the pci bus should implement bus-set_resourc() by treating the RID as a congig register offset of an extra BAR whcih would simplify amdpm -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512191112.48905.jhb>