[i2c] "Using i2c-parport bus Driver"

Jean Delvare khali at linux-fr.org
Sat Oct 14 00:18:04 CEST 2006


Hi Seetaram,

I think I already asked you to start new threads on the mailing list for
new topics, didn't I? This post has nothing to do with i2c-parport as
far as I can see.

On Fri, 13 Oct 2006 15:48:52 +0530, Seetaram, Tekkalkot wrote:
> Finally I could able to install the lm-sensors package on my Linux box.
> I am also able to run the sensors command and able to see the
> temperature data.
> I'm attaching the log file created by running the following 
> 1. Sensors-detect (Script)
> 2. I2cdetect program
> 
> With reference to the log files I captured, I have the following
> questions and request you kindly clarify.
> 
> 1. Sensors-detect is a (Perl) script and it checks for different i2c
> busses/chips and loads the drivers corresponding to them (Correct me if
> I'm wrong).

This is not totally accurate. sensors-detect is about hardware
monitoring (sensors) drivers. Some of them are i2c drivers, but not all.

> In the log attached I have the following questions
> corresponding to the following entries.
> 
> Next adapter: SMBus Via Pro adapter at 0500
> Do you want to scan it? (YES/no/selectively):
> Client found at address 0x31
> Client found at address 0x4c
> Handled by driver `lm90' (already loaded), chip type `adm1032'
> Client found at address 0x51
> Probing for `Analog Devices ADM1033'...                     No
> Probing for `Analog Devices ADM1034'...                     No
> Probing for `SPD EEPROM'...                                 Success!
>     (confidence 8, driver `eeprom')
> Client found at address 0x69
> 
> 
> 1. The log says Client found at address 0x4c and 0x31 handled by driver
> lm90.

No, it says that the client at 0x4c is handled by driver lm90. It
doesn't say anything about the client at 0x31, and you can safely
ignore it.

> But if I run the i2cdetect and verify the output (refer log attached),
> there is no entry corresponding to client address 0x4c. Why is it so?

There is an entry, it is marked UU for "used" or "busy" (as opposed to
XX for unused I2C addresses.) I admit the manual page lacks an
explanation of this, I'll add it tomorrow. i2cdetect doesn't probe
addresses which are already in use because it could confuse the
driver. Same for sensors-detect, BTW.

> 2. How these client addresses are assigned and accessed from the user
> space? Are these fixed addresses? 

In the simple case, the address is hard-coded in the chip itself. Some
chips can select between different fixed addresses depending on the
wiring of dedicated pinsn with the benefit that you can then connect
several similar chips on the same bus. Lastly, the SMBus 2.0
specification includes an address resolution protocol which makes it
possible to dynamically assign addresses to compliant chips - but the
Linux kernel doesn't support this feature yet.

As for how the chips are accessed, well, the address is a mandatory
parameter for any transaction on the bus. In the general case, each
chip only answers to transactions corresponding to its own address.

> 3. The log says 
> 
> Probing for `SPD EEPROM'...                                 Success!
>     (confidence 8, driver `eeprom')
> Client found at address 0x69
> 
> a. What is the meaning of confidence 8? 

Some chips are hard to identify, so sensors-detect may find that a given
chip matches several "signatures". We attribute a level of confidence
or trust to every possible match, and select the highest one in the end,
which hopefully is the right one. Regular users can ignore this
altogether and jump to the final summary. We could even hide the details
from the sensors-detect output by default in the future.

> b. I didn't find any SPD EEPROM on the motherboard on I2C bus, and also
> no chip driver is loaded for SPD EEPROM, then what is the meaning of
> above lines.

The SPD EEPROM is not on your motherboard itself but on the memory
module. This EEPROM contrains information such as the type, amount and
speed of the memory. To read this information, load the eeprom driver
(as suggested by the output of sensors-detect) then run the script
decode-dimms.pl. Note that this script is only included in lm_sensors
for historical reasons, as these EEPROMs have nothing to do with
sensors.

-- 
Jean Delvare



More information about the i2c mailing list