[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YyzIFGo6SYhVP6sj@paasikivi.fi.intel.com>
Date: Thu, 22 Sep 2022 20:39:48 +0000
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: Mikhail Rudenko <mike.rudenko@...il.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Jacopo Mondi <jacopo@...ndi.org>,
Shawn Tu <shawnx.tu@...el.com>,
Randy Dunlap <rdunlap@...radead.org>,
Daniel Scally <djrscally@...il.com>,
Christian Hemp <c.hemp@...tec.de>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Marek Vasut <marex@...x.de>, linux-media@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] media: i2c: add support for ov4689
Hi Mikhail,
On Thu, Sep 22, 2022 at 06:23:05PM +0300, Mikhail Rudenko wrote:
>
> Hi Sakari,
>
> and thanks for reviewing this!
You're welcome!
>
> Please see my comments below:
>
> On 2022-09-22 at 09:53 GMT, Sakari Ailus <sakari.ailus@...ux.intel.com> wrote:
...
> >> +static inline u32 ov4689_cal_delay(u32 cycles)
> >> +{
> >> + return DIV_ROUND_UP(cycles, OV4689_XVCLK_FREQ / 1000 / 1000);
> >
> > Please use the actual rate instead.
> >
>
> Do you mean clk_get_rate(ov4689->xvclk), right? What if we have an ACPI
Yes.
> system and xvclk is NULL here? Please explain.
There are a few ways this could work on ACPI based systems but generally
you'd have "clock-frequency" property to indicate the frequency even if
clocks themselves wouldn't be available (when controlled via ACPI)).
--
Kind regards,
Sakari Ailus
Powered by blists - more mailing lists