On Mon, 30 Mar 2009, Sascha Hauer wrote: > On Mon, Mar 30, 2009 at 11:26:31AM +0200, Guennadi Liakhovetski wrote: > > > > Well, I have been able to get your driver to at least pass the > > initialisation with mt9t031 (other parts are missing yet for a complete > > test). For that I used this silly patch: > > > > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c > > index 3296380..46e1033 100644 > > --- a/drivers/i2c/busses/i2c-imx.c > > +++ b/drivers/i2c/busses/i2c-imx.c > > @@ -371,6 +371,8 @@ static int i2c_imx_xfer(struct i2c_adapter *adapter, > > if (result) > > goto fail0; > > > > + msleep(2); > > + > > /* Start I2C transfer */ > > i2c_imx_start(i2c_imx); > > > > As you understand, this cannot be the final fix. We have to understand why > > a delay is needed there and how long it actually has to be... > > > > Have you checked the value of disable_delay in Darius' driver or tried to > increase it? Why? That variable is addreccing a problem on a completely different hardware: /* * There dummy delay is calculated. * It should be about one I2C clock period long. * This delay is used in I2C bus disable function * to fix chip hardware bug. */ and is used on a different path - during controller disable. > BTW I just realized that the handling of disable_delay in Darius' driver > is wrong. This should be a per device variable. Indeed. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
