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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
