Re: [PATCH 2/2] [media] ds3000: properly report firmware loading issues

["Rémi Cardona" <remi.cardona@smartjog.com>]

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