lkml.org 
[lkml]   [2022]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/2] media: i2c: add support for ov4689
Hi Tommaso,

On Fri, Sep 16, 2022 at 03:34:01PM +0200, Tommaso Merciai wrote:
> > >> + ret = clk_set_rate(ov4689->xvclk, OV4689_XVCLK_FREQ);
> > >> + if (ret < 0) {
> > >> + dev_err(dev, "Failed to set xvclk rate (24MHz)\n");
> > >> + return ret;
> > >> + }
> > >> + if (clk_get_rate(ov4689->xvclk) != OV4689_XVCLK_FREQ)
> > >> + dev_warn(dev, "xvclk mismatched, modes are based on 24MHz\n");
> > >
> > >
> > > What do you think about?
> > > Thanks.
> >
> > Unfortunately, I have no experience with ACPI-based devices. :(
> >
> > Do you mean that in the case of an ACPI device and devm_clk_get_optional
> > returning NULL we should assume that the clock is already enabled and
> > will stay enabled during sensor operation? How should we distinguish it
> > from the case of an OF-based system and clock just missing from device
> > tree?
>
> Not exaclty :)
>
> I copy comment from [1]
>
> if you use ov5693->xvclk to identify the ACPI vs OF use case shouldn't
> you use the get_optionl() version ? Otherwise in the ACPI case you will have
> -ENOENT if there's not 'xvclk' property and bail out.
>
> Unless my understanding is wrong on ACPI we have "clock-frequency" and
> on OF "xvclk" with an "assigned-clock-rates",

Generally yes. It's also possible to have a clock in ACPI based system
although those clocks do not come from ACPI. See e.g.
drivers/platform/x86/intel/int3472/clk_and_regulator.c .

--
Sakari Ailus

\
 
 \ /
  Last update: 2022-09-19 08:33    [W:0.078 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site