| Message ID | 20220823165723.276156-1-marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: mt9p031: Increase post-reset delay | expand |
Hi Marek, On Tue, Aug 23, 2022 at 06:57:23PM +0200, Marek Vasut wrote: > The MT9P006 sensor driver sporadically fails to probe because the sensor > responds with a NACK condition to I2C address on the bus during an attempt > to read the sensor MT9P031_CHIP_VERSION register in mt9p031_registered(). > > Neither the MT9P006 nor MT9P031 datasheets are clear on reset signal timing. > Older MT9M034 [1] datasheet provides those timing figures in Appendix-A and > indicates it is necessary to wait 850000 EXTCLK cycles before starting any > I2C communication. > > Add such a delay, which does make the sporadic I2C NACK go away, so it is > likely similar constraint applies to this sensor. > > [1] https://www.onsemi.com/pdf/datasheet/mt9m034-d.pdf > > Signed-off-by: Marek Vasut <marex@denx.de> > --- > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> > Cc: Sakari Ailus <sakari.ailus@linux.intel.com> > Cc: Stefan Riedmueller <s.riedmueller@phytec.de> > --- > drivers/media/i2c/mt9p031.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c > index 45f7b5e52bc39..7c83be5b9ec9d 100644 > --- a/drivers/media/i2c/mt9p031.c > +++ b/drivers/media/i2c/mt9p031.c > @@ -307,6 +307,7 @@ static inline int mt9p031_pll_disable(struct mt9p031 *mt9p031) > > static int mt9p031_power_on(struct mt9p031 *mt9p031) > { > + unsigned long delay; > int ret; > > /* Ensure RESET_BAR is active */ > @@ -334,7 +335,9 @@ static int mt9p031_power_on(struct mt9p031 *mt9p031) > /* Now RESET_BAR must be high */ > if (mt9p031->reset) { > gpiod_set_value(mt9p031->reset, 0); > - usleep_range(1000, 2000); > + /* Wait 850000 EXTCLK cycles before de-asserting reset. */ > + delay = DIV_ROUND_UP(850000 * 1000, clk_get_rate(mt9p031->clk)); clk_get_rate() will return 0 if there's no clock. I guess that doesn't happen commonly but it'd be nice to guard against that. > + msleep(delay); > } > > return 0;
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c index 45f7b5e52bc39..7c83be5b9ec9d 100644 --- a/drivers/media/i2c/mt9p031.c +++ b/drivers/media/i2c/mt9p031.c @@ -307,6 +307,7 @@ static inline int mt9p031_pll_disable(struct mt9p031 *mt9p031) static int mt9p031_power_on(struct mt9p031 *mt9p031) { + unsigned long delay; int ret; /* Ensure RESET_BAR is active */ @@ -334,7 +335,9 @@ static int mt9p031_power_on(struct mt9p031 *mt9p031) /* Now RESET_BAR must be high */ if (mt9p031->reset) { gpiod_set_value(mt9p031->reset, 0); - usleep_range(1000, 2000); + /* Wait 850000 EXTCLK cycles before de-asserting reset. */ + delay = DIV_ROUND_UP(850000 * 1000, clk_get_rate(mt9p031->clk)); + msleep(delay); } return 0;
The MT9P006 sensor driver sporadically fails to probe because the sensor responds with a NACK condition to I2C address on the bus during an attempt to read the sensor MT9P031_CHIP_VERSION register in mt9p031_registered(). Neither the MT9P006 nor MT9P031 datasheets are clear on reset signal timing. Older MT9M034 [1] datasheet provides those timing figures in Appendix-A and indicates it is necessary to wait 850000 EXTCLK cycles before starting any I2C communication. Add such a delay, which does make the sporadic I2C NACK go away, so it is likely similar constraint applies to this sensor. [1] https://www.onsemi.com/pdf/datasheet/mt9m034-d.pdf Signed-off-by: Marek Vasut <marex@denx.de> --- Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Stefan Riedmueller <s.riedmueller@phytec.de> --- drivers/media/i2c/mt9p031.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)