Re: SMBus quick command problem

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

Salut Fabien,

On Thu, 8 Jan 2009 10:01:01 +0100, Fabien Marteau wrote:
> I'm writing a driver for i2c controller. To do it, I'm following the
> SMBus protocol description in linux/Documentation/i2c/SMBus-
> protocol. This documentation say that we can write a single bit with
> «SMBus Quick Command». This command is used in i2cdetect program to
> find slave on the bus.
> 
> I used this command to write bit 0 and that work whell with my slaves,
> but if I try to write bit 1 the slaves addressed are blocking the bus
> (maintain SDA to 0). I tried it with two slaves components :
> LIS3LV02DL (accelerometer) and DS28CZ04 (EEPROM).
> 
> Is it a known problem ?

The SMBus specification describes a number of standardized
transactions. Each chip on the bus can support each given transaction
type or not. In practice, each slave chip only supports a subset of the
SMBus specification. I can't remember working on a chip saying it was
supporting the SMBus quick command. The Linux i2c subsystem abuses this
transaction type for device detection purposes, because it is known to
give good results in practice, but ideally it shouldn't do that.

There have been some devices known to lock up the SMBus on Quick
command with data bit = 1 (as you are experiencing.) In most cases
these were write-only devices, which didn't expect a transaction
starting like a read (the SMBus specification says that a Quick command
with data bit = 1 is writing 1 bit to the slave, but the I2C
specification says this is a _read_ transaction of length 0.)

This SMBus Quick command thing keeps causing trouble and confusing
people. Not much we can do though. If your slaves don't like the quick
command, just don't send that command to them.

> [Erreur de décodage BASE64]

Gni?

-- 
Jean Delvare