| Message ID | 20240506144947.85253-1-jacopo.mondi@ideasonboard.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: i2c: max9271: Ignore read error in s_stream | expand |
Hi Jacopo, Thank you for the patch. On Mon, May 06, 2024 at 04:49:46PM +0200, Jacopo Mondi wrote: > In order to start streaming, the serializer's SEREN bit has to > be asserted and the video link enabled. In order for the video > link to be enabled correctly a valid pixel clock has to be > detected between the serializer and the connected image sensor. > > The pixel clock detection is performed by reading register 0x15 but the > first attempt to read the register value sporadically fails resulting in > a error in the stream start procedure. > > As the error is not fatal, and the pixel detection procedure will abort > anyway after 10 msec if no valid pixel clock is detected, continue > instead of failing immediately if the register read fails. > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> > > --- > When running 4 cameras at a time, the first register read on the first started > camera fails pretty often. I here decided to ignore the error and go for another > read attempt, but issuing a simple "i2c_smbus_read_reg()" (as we do in the wakup > function) before the actual register read resolves the issue in the same way. > > I've not been able to find in the datasheet any mention of a "ping to wakeup" > requirement before enabling the video channel, but this change make capturing > from 4 RDACM20 camera pretty reliable. I'm OK with that. In parallel, it would be nice to try and ask the vendor (assuming they would still provide support for GMSL). Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > --- > > drivers/media/i2c/max9271.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/i2c/max9271.c b/drivers/media/i2c/max9271.c > index ff86c8c4ea61..e339dff3986d 100644 > --- a/drivers/media/i2c/max9271.c > +++ b/drivers/media/i2c/max9271.c > @@ -66,8 +66,10 @@ static int max9271_pclk_detect(struct max9271_device *dev) > > for (i = 0; i < 100; i++) { > ret = max9271_read(dev, 0x15); > - if (ret < 0) > - return ret; > + if (ret < 0) { > + usleep_range(50, 100); > + continue; > + } > > if (ret & MAX9271_PCLKDET) > return 0;
diff --git a/drivers/media/i2c/max9271.c b/drivers/media/i2c/max9271.c index ff86c8c4ea61..e339dff3986d 100644 --- a/drivers/media/i2c/max9271.c +++ b/drivers/media/i2c/max9271.c @@ -66,8 +66,10 @@ static int max9271_pclk_detect(struct max9271_device *dev) for (i = 0; i < 100; i++) { ret = max9271_read(dev, 0x15); - if (ret < 0) - return ret; + if (ret < 0) { + usleep_range(50, 100); + continue; + } if (ret & MAX9271_PCLKDET) return 0;
In order to start streaming, the serializer's SEREN bit has to be asserted and the video link enabled. In order for the video link to be enabled correctly a valid pixel clock has to be detected between the serializer and the connected image sensor. The pixel clock detection is performed by reading register 0x15 but the first attempt to read the register value sporadically fails resulting in a error in the stream start procedure. As the error is not fatal, and the pixel detection procedure will abort anyway after 10 msec if no valid pixel clock is detected, continue instead of failing immediately if the register read fails. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> --- When running 4 cameras at a time, the first register read on the first started camera fails pretty often. I here decided to ignore the error and go for another read attempt, but issuing a simple "i2c_smbus_read_reg()" (as we do in the wakup function) before the actual register read resolves the issue in the same way. I've not been able to find in the datasheet any mention of a "ping to wakeup" requirement before enabling the video channel, but this change make capturing from 4 RDACM20 camera pretty reliable. --- drivers/media/i2c/max9271.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.44.0