On 08/30/2012 06:00 PM, Antti Palosaari wrote: > hmm, looks like ds3000_readreg() logic is still a little bit broken. It > checks count of sent messages and compares it to 2. But if I2C-adapter > sends only 1 message or 3 (which should not be possible) function return > that count instead of -EREMOTEIO. OK, quite rare situation, but one > point more to fail if I2C-adapter has also bug. You're absolutely right. The logic is completely awkward. I'm currently working on a new patch series that will clean up all the register reading/writing functions to properly check i2c_transfer()'s return code. > But that happens for return value 0 too. Could it be the issue? > I2C-adapter returns 0 for some reason? Bug in I2C-adapter with bug in > ds3000_readreg() implementation? [...] > You basically see two different kind of errors, 1) bus communication > fails, eg. usb timeouts. 2) chips returns error status. Later cases the > error could come from the this could come from the firmware if chip uses > firmware or from the silicon. It could be from the I2C-adapter firmware. Right now, I just have no idea. Right now, the overwhelming majority of the cards we tested with a recent kernel (about 60 units) are working just fine with the code as-is. My main (if not sole) objective for now is to make it easier for us (but hopefully for others too) to find defective cards/chips. > Add sleep after the each operation. Good place to add sleep is > I2C-adapter. I2C-adapters usually supports two different operations, > write and read + write using repeated START condition. Former us used > typically for register write and later for register read. > > 500us is good choice. If it is only that one register read which causes > problems, how about repeating it? I'll first see how our units are behaving with the upcoming patches but I'll definitely keep this in mind as a next step. Thanks again, Rémi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
