Hi Jacopo, On Wed, Mar 17, 2021 at 11:04:45AM +0100, Jacopo Mondi wrote: > On Mon, Mar 15, 2021 at 05:22:37PM +0000, Kieran Bingham wrote: > > On 15/03/2021 13:15, Jacopo Mondi wrote: > > > It has been observed through repeated testing (250 boots) that in the > > > 10% of the cases the RDACM21 initialization sequence errors out due a > > > timeout waiting for the OV490 firmware to complete its boot phase. > > > > > > Albeit being the current timeout relatively large (300-600 milliseconds), > > > doubling it reduces the sporadic error rate down to 1 over an 80 boot > > > sequences test run. > > > > > > The firmware boot delay is unfortunately not characterized in the camera > > > module manual. > > > > I wonder if we could characterize this alone by pulling this down until > > we see failures increase, with all the other fixes in place... > > > > I don't think that's required, but it might be something to check later > > if we don't get rid of that 1/80 failure. > > This is actually driving me crazy :/ > > I had another test run with a surprising 10% failures. > All the failures were due to the ov490 firmware boot I'm trying to > mitigate here. > > I went up to give it -6 seconds- and I still get failures in the same > percentage. Another run of 20 boots gave 30% failures with the delay I > have here in this patch. Just to make sure I was not going crazy I > reduced the delay to 1msec and I get an 80% failure rate. > > Still, I've seen the 1 on 80 failures (I swear! I have logs! :) > > I've checked what the BSP does, and if after some 300 attempts the > ov490 doesn't boot, they simply go an reset it. > https://github.com/renesas-rcar/linux-bsp/commit/0cf6e36f5bf49e1c2aab87139ec5b588623c56f8#diff-d770cad7d6f04923d9e89dfe7da369bb3006776d6e4fb8ef79353d5fab3cd25aR827 > (sorry, I don't seem to be able to point you to the ov490.c#827 with > an URL) It resets both the sensor and the OV490. It could be interested to try the latter selectively to see what happens. I also suspect that the OV490 has debugging features (possibly including a RAM log buffer that we could read over I2C), but we're probably getting out of scope here. > I assume we don't want anything like this in an upstream driver, but > I'm really running out of any plausible explanation :( As discussed, let's try the reset workaround, to see if it helps. I wonder if opening the camera and probing signals would be a useful option :-) > > > Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") > > > Signed-off-by: Jacopo Mondi <jacopo+renesas@xxxxxxxxxx> > > > > Reviewed-by: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> > > > > > --- > > > drivers/media/i2c/rdacm21.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c > > > index 50a9b0d8255d..07cf077d8efd 100644 > > > --- a/drivers/media/i2c/rdacm21.c > > > +++ b/drivers/media/i2c/rdacm21.c > > > @@ -53,7 +53,7 @@ > > > #define OV490_PID 0x8080300a > > > #define OV490_VER 0x8080300b > > > #define OV490_PID_TIMEOUT 20 > > > -#define OV490_OUTPUT_EN_TIMEOUT 300 > > > +#define OV490_OUTPUT_EN_TIMEOUT 600 > > > > > > #define OV490_GPIO0 BIT(0) > > > #define OV490_SPWDN0 BIT(0) -- Regards, Laurent Pinchart
