lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 19 Mar 2020 07:59:06 +0000
From:   "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Fabio Estevam <festevam@...il.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Ezequiel Garcia <ezequiel@...labora.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Magnus Damm <magnus.damm@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        NXP Linux Team <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: Re: [PATCH v3 3/4] media: i2c: ov5645: Set maximum leverage of
 external clock frequency to 24480000

Hi Laurent,

On Wed, Mar 18, 2020 at 11:19 PM Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:
>
> 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:
> > > On Fri, Mar 13, 2020 at 09:12:33PM +0000, Lad Prabhakar wrote:
> > > > 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@...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.
>
Thank you for looking into this. I'll update the patch accordingly.

Cheers,
--Prabhakar

> > > > + */
> > > > +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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ