Hi Prabhakar,

On Fri, Mar 13, 2020 at 09:31:25PM +0000, Prabhakar Mahadev Lad wrote:

On 13 March 2020 21:24, Laurent Pinchart wrote:

quoted

On Fri, Mar 13, 2020 at 09:12:33PM +0000, Lad Prabhakar wrote:

quoted

While testing on Renesas RZ/G2E platform, noticed the clock frequency
to be 24242424 as a result the probe failed. However increasing the
maximum leverage of external clock frequency to 24480000 fixes this
issue. Since this difference is small enough and is insignificant set
the same in the driver.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 drivers/media/i2c/ov5645.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
index 4fbabf3..b49359b 100644
--- a/drivers/media/i2c/ov5645.c
+++ b/drivers/media/i2c/ov5645.c

@@ -1107,8 +1107,10 @@ static int ov5645_probe(struct i2c_client *client)
 }

 xclk_freq = clk_get_rate(ov5645->xclk);
-/* external clock must be 24MHz, allow 1% tolerance */
-if (xclk_freq < 23760000 || xclk_freq > 24240000) {
+/* external clock must be 24MHz, allow a minimum 1% and a maximum of 2%
+ * tolerance

So where do these numbers come from ? I understand that 2% is what you
need to make your clock fit in the range, but why -1%/+2% instead of -
2%/+2% ? And why not 2.5 or 3% ? The sensor datasheet documents the
range of supported xvclk frequencies to be 6MHz to 54MHz. I understand
that PLL parameters depend on the clock frequency, but could they be
calculated instead of hardcoded, to avoid requiring an exact 24MHz input
frequency ?

To be honest I don't have the datasheet for ov5645, the flyer says 6-54Mhz but the
logs/comment says 24Mhz.

The OV5645 clock topology is fairly complex, with two PLLs and different
set of output dividers. It however shouldn't be impossible to calculate
the PLL configuration in the driver, but would require some dedication,
and is probably not worth it.

I've discussed the matter with Sakari, and we concluded that this is
just a sanity check. We advise increasing the tolerance by a bigger
amount to avoid patching this for every new board (completely
arbitrarily, +/- 5%), and turning the fatal error into a dev_warn,
dropping the return -EINVAL statement.

quoted

quoted

+ */
+if (xclk_freq < 23760000 || xclk_freq > 24480000) {
 dev_err(dev, "external clock frequency %u is not supported\n",
 xclk_freq);
 return -EINVAL;

-- 
Regards,

Laurent Pinchart

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel