* [PATCH v2] media: mt9p031: Increase post-reset delay
@ 2022-08-23 22:22 Marek Vasut
2022-11-20 13:55 ` Marek Vasut
2022-11-20 19:27 ` Laurent Pinchart
0 siblings, 2 replies; 4+ messages in thread
From: Marek Vasut @ 2022-08-23 22:22 UTC (permalink / raw)
To: linux-media
Cc: Marek Vasut, Laurent Pinchart, Mauro Carvalho Chehab,
Sakari Ailus, Stefan Riedmueller
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>
---
V2: - In case clk_get_rate() returns 0, use slowest supported clock
to avoid division by zero
---
drivers/media/i2c/mt9p031.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 45f7b5e52bc39..5f5caafe56887 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 rate, delay;
int ret;
/* Ensure RESET_BAR is active */
@@ -334,7 +335,12 @@ 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. */
+ rate = clk_get_rate(mt9p031->clk);
+ if (!rate)
+ rate = 6000000; /* Slowest supported clock, 6 MHz */
+ delay = DIV_ROUND_UP(850000 * 1000, rate);
+ msleep(delay);
}
return 0;
--
2.35.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] media: mt9p031: Increase post-reset delay
2022-08-23 22:22 [PATCH v2] media: mt9p031: Increase post-reset delay Marek Vasut
@ 2022-11-20 13:55 ` Marek Vasut
2022-11-21 16:19 ` Sakari Ailus
2022-11-20 19:27 ` Laurent Pinchart
1 sibling, 1 reply; 4+ messages in thread
From: Marek Vasut @ 2022-11-20 13:55 UTC (permalink / raw)
To: linux-media
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Sakari Ailus,
Stefan Riedmueller
On 8/24/22 00:22, 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>
> ---
> V2: - In case clk_get_rate() returns 0, use slowest supported clock
> to avoid division by zero
Any news on this patch ?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] media: mt9p031: Increase post-reset delay
2022-08-23 22:22 [PATCH v2] media: mt9p031: Increase post-reset delay Marek Vasut
2022-11-20 13:55 ` Marek Vasut
@ 2022-11-20 19:27 ` Laurent Pinchart
1 sibling, 0 replies; 4+ messages in thread
From: Laurent Pinchart @ 2022-11-20 19:27 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-media, Mauro Carvalho Chehab, Sakari Ailus, Stefan Riedmueller
Hi Marek,
Thank you for the patch.
On Wed, Aug 24, 2022 at 12:22:16AM +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>
Given the lack of information regarding the MT9P006 reset timings, this
seems to be the best we can do.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> 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>
> ---
> V2: - In case clk_get_rate() returns 0, use slowest supported clock
> to avoid division by zero
> ---
> drivers/media/i2c/mt9p031.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
> index 45f7b5e52bc39..5f5caafe56887 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 rate, delay;
> int ret;
>
> /* Ensure RESET_BAR is active */
> @@ -334,7 +335,12 @@ 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. */
> + rate = clk_get_rate(mt9p031->clk);
> + if (!rate)
> + rate = 6000000; /* Slowest supported clock, 6 MHz */
> + delay = DIV_ROUND_UP(850000 * 1000, rate);
> + msleep(delay);
> }
>
> return 0;
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] media: mt9p031: Increase post-reset delay
2022-11-20 13:55 ` Marek Vasut
@ 2022-11-21 16:19 ` Sakari Ailus
0 siblings, 0 replies; 4+ messages in thread
From: Sakari Ailus @ 2022-11-21 16:19 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-media, Laurent Pinchart, Mauro Carvalho Chehab, Stefan Riedmueller
Hi Marek,
On Sun, Nov 20, 2022 at 02:55:22PM +0100, Marek Vasut wrote:
> On 8/24/22 00:22, 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>
> > ---
> > V2: - In case clk_get_rate() returns 0, use slowest supported clock
> > to avoid division by zero
>
> Any news on this patch ?
Thanks for the ping. It's in my tree now.
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-11-21 16:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-23 22:22 [PATCH v2] media: mt9p031: Increase post-reset delay Marek Vasut
2022-11-20 13:55 ` Marek Vasut
2022-11-21 16:19 ` Sakari Ailus
2022-11-20 19:27 ` Laurent Pinchart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).