[lm-sensors] Adding ICH6 support to the i2c-i801 module,

[csyllac@gmail.com (Craig Sylla)]

Thank you for your reply -

On 7/15/05, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Craig,
> 
> > I have a system with an ICH6M chipset (915GM) which has to run kernel
> > 2.6.5.  There are a couple devices on the SMBus which I would like to
> > get to, an LM63 and a TC655 (fan controller).
> 
> Not to disappoint you, but LM63 supports was added much later, in
> 2.6.10. And I don't think there is a driver for the TC655.
> 

Yes - 2.6.10 is right.  I've backported that driver as well.  It
loads, but the bus locks up too fast to tell if it works or not.  I
did the backport by comparing the LM83 from 2.6.5 to 2.6.10, and
applying equivalent changes.
If I can get everything working, I'm hoping to write the TC655 driver
as part of this.  It's a pretty simple device, so basic support
doesn't seem to be an incredibly difficult task.  I've done SMBus
stuff for DIMM SPD's before.

> > The i2c-i801 module supports this in 2.6.7, so I back-ported the
> > changes (basically the PCI Id) and sensors-detect now finds the bus.
> > Here is the output of i2cdetect:
> >
> >   Installed I2C busses:
> >     i2c-1       unknown         SMBus I801 adapter at 0400
> >  Algorithm unavailable
> >     i2c-0       dummy           ISA main adapter
> >  ISA bus algorithm
> >
> > I have 2 questions/issues -
> >
> > First, is the 'unknown' and 'Algorithm unavailable' normal, or did I
> > miss something in my backport?
> 
> It's normal, the 2.6 kernel exports less information than the 2.4 kernel
> did, so user-space utilities can't report the missing information. I
> plan to modify the user-space utilities to stop displaying the
> information (or lack thereof), so as to not confuse the user.
> 

Ok that makes sense - thanks.

> > Second, if I try to access any of the devices on the SMBus, I will
> > quickly get a collision/buslock.  I did not change the i2c_delay()
> > code to match the msleep() in the backport, could this be affecting
> > it?  The bus does scan, and I see devices where I'd expect them, so
> > it's -really- close to working...
> 
> Most probably unrelated.
> 
> Asus board?
> 
> If some device on the bus misbehaves, there's not much you can do,
> unfortunately, unless you can get control over this device. This would
> require a full knowledge of the bus topology, which manufacturers
> usually don't disclose easily.
> 
> --
> Jean Delvare
> 

Ok - I'll need to track down more info.  The board is a specialized
industrial module, so I can probably get details on the bus layout. 
There are a half-dozen or so devices on the bus I'll have to track
down as well to see who's causing the trouble.

Thanks again for your help.

Craig