On Thu, Dec 28, 2000 at 02:57:33PM -0500, Andrew Gallatin wrote:
>
> Nicolas Souchu writes:
> > Gasp! This is part of my fault. I shouldn't have left this old style
> > driver in the tree :( You should have contacted me, I would have adviced
> > you.
> >
> > Takanori is right, you should look at intpm to get info about how
> > to cleanly newbusify your driver. This is what I'm currently doing
> > for alpm ;)
> >
> > By the way, is someone working on the VIA SMBus support? Or do I start it?
> >
>
> FWIW, I've just newbus'ified the alpm driver. See
> http://people.freebsd.org/~gallatin/alpm.diff
Good. Seems ok for commit.
>
> Somebody with an x86 AMD should probably test it. This seems to
> "sorta" work on my API UP1000 (which is an alpha). Eg:
>
> FreeBSD 5.0-CURRENT #23: Thu Dec 28 11:24:33 EST 2000
> [EMAIL PROTECTED]:/.amd_mnt/muffin/export/ari_scratch2/gallatin/c
> urrent/sys/compile/UP1000
> UP1000
> API UP1000 598 MHz, 598MHz
> 8192 byte page size, 1 processor.
> CPU: major=11 minor=8
> extensions=0x307<BWX,FIX,CIX,MVI,PRECISE>
> OSF PAL rev: 0x100010002013e
> <...>
> alpm0: <AcerLabs M15x3 Power Management Unit> port 0x1040-0x105f,0x1000-0x103f at
>device 17.0 on pci0
> smbus0: <System Management Bus> on alsmb0
> smb0: <SMBus general purpose I/O> on smbus0
We should remove all these useless reports of general purpose
driver and just keep the controller detection prints.
> <...>
> # ./smb_detect
> 58 found.
> 74 found.
> 78 found.
> 90 found.
> a0 found.
> a8 found.
>
> If I beat on lm.c from
> http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/lm.c
> enough and use 0x90 as cmd.slave, I can get the CPU temp of 41 C.
> This is the same as firmware gives me, which is encouraging.
>
> As you can probably tell, I don't know enough about smb to fight my
> way out of a wet paper bag. Is there an SMB savy person out there
> who can take me by the hand and help me figure out where the fan
> speed and voltage is lurking and how to read it?
Maybe not over SMBus :( Some boards are designed such a way that
SMBus is only used for SDRAM detection not monitoring. The lm75/78
can also be controlled over both ISA... But this seems not to be the
case for you since you found many chip on the SMBus.
Grab the linux lm_sensor documentation and see if these I2C addresses
are listed and which chips they are potentially assigned to. At this
point, it is not SMBus dependent, but chip/vendor dependent.
The only problem you can have with smbus/iicbus is now timings, but
with alpm, these are handled by the controller.
By the way, there's a port (lmmon) that accesses the lm75/78 over ISA, if
you have such a monitoring chip...
Nicholas
--
[EMAIL PROTECTED]
Alcôve - Open Source Software Engineer - http://www.alcove.fr
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
