Devicetree
 help / color / mirror / Atom feed
From: Tommaso Merciai <tommaso.merciai@amarulasolutions.com>
To: Mikhail Rudenko <mike.rudenko@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Jacopo Mondi <jacopo@jmondi.org>, Shawn Tu <shawnx.tu@intel.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Daniel Scally <djrscally@gmail.com>,
	Christian Hemp <c.hemp@phytec.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Marek Vasut <marex@denx.de>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] media: i2c: add support for ov4689
Date: Mon, 19 Sep 2022 09:08:13 +0200	[thread overview]
Message-ID: <20220919070813.GA3958@tom-ThinkPad-T14s-Gen-2i> (raw)
In-Reply-To: <87r10bo1k5.fsf@gmail.com>

Hi Mikhail,

On Fri, Sep 16, 2022 at 04:44:31PM +0300, Mikhail Rudenko wrote:
> 
> On 2022-09-16 at 15:34 +02, Tommaso Merciai <tommaso.merciai@amarulasolutions.com> wrote:
> > Hi Mikhail,
> >
> > On Thu, Sep 15, 2022 at 11:50:23PM +0300, Mikhail Rudenko wrote:
> >>
> >> Hi Tommaso,
> >>
> >> On 2022-09-14 at 17:51 +02, Tommaso Merciai <tommaso.merciai@amarulasolutions.com> wrote:
> >> > Hi Mikhail,
> >> > I do a first round on reviewing your driver :)
> >> >
> >> > On Sun, Sep 11, 2022 at 11:01:35PM +0300, Mikhail Rudenko wrote:
> 
> <snip>
> 
> >> >> +
> >> >> +	ov4689->xvclk = devm_clk_get(dev, "xvclk");
> >> >> +	if (IS_ERR(ov4689->xvclk)) {
> >> >> +		dev_err(dev, "Failed to get xvclk\n");
> >> >> +		return -EINVAL;
> >> >> +	}
> >> >
> >> > ^ I think is better to use devm_clk_get_optional instead of clck_get.
> >> > clck_get can fail in CPU's that use ACPI
> >> >
> >> >> +
> >> >> +	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",
> >
> > [1] https://patchwork.linuxtv.org/project/linux-media/patch/20220627150453.220292-5-tommaso.merciai@amarulasolutions.com/
> >
> > Let me know if you need more details.
> 
> Thanks for the pointer! I'll try to implement something along the lines
> of your ov5693 series.
> 
> But I'm not sure that will be enough to support ACPI systems
> correctly. What about lanes number and link frequency checks? Should
> they be made conditional on CONFIG_OF? Anything else I don't know?

In my opinion, lanes number and link frequency checks are ok :)
We don't need conditional CONFIG_OF.

fwnode* function support both ACPI and dts.

Thanks,
Tommaso

> 
> >
> > Regards,
> > Tommaso
> >
> --
> Best regards,
> Mikhail Rudenko

-- 
Tommaso Merciai
Embedded Linux Engineer
tommaso.merciai@amarulasolutions.com
__________________________________

Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
info@amarulasolutions.com
www.amarulasolutions.com

  reply	other threads:[~2022-09-19  7:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-11 20:01 [PATCH v2 0/2] Add Omnivision OV4689 image sensor driver Mikhail Rudenko
2022-09-11 20:01 ` [PATCH v2 1/2] media: dt-bindings: media: i2c: document OV4689 DT bindings Mikhail Rudenko
2022-09-12 10:55   ` Krzysztof Kozlowski
2022-09-15 12:16     ` Mikhail Rudenko
2022-09-16  9:42       ` Krzysztof Kozlowski
2022-09-13 14:05   ` Tommaso Merciai
2022-09-15 20:11     ` Mikhail Rudenko
2022-09-16 13:15       ` Tommaso Merciai
2022-09-16 13:42         ` Mikhail Rudenko
2022-09-19 13:16           ` Laurent Pinchart
2022-09-11 20:01 ` [PATCH v2 2/2] media: i2c: add support for ov4689 Mikhail Rudenko
2022-09-11 22:52   ` kernel test robot
2022-09-12 10:56   ` Krzysztof Kozlowski
2022-09-15 20:40     ` Mikhail Rudenko
2022-09-16  9:43       ` Krzysztof Kozlowski
2022-09-16 21:51         ` Sakari Ailus
2022-09-14 15:51   ` Tommaso Merciai
2022-09-15 20:50     ` Mikhail Rudenko
2022-09-16 13:34       ` Tommaso Merciai
2022-09-16 13:44         ` Mikhail Rudenko
2022-09-19  7:08           ` Tommaso Merciai [this message]
2022-09-19  6:33         ` Sakari Ailus
2022-09-19  7:11           ` Tommaso Merciai
2022-09-22  9:53   ` Sakari Ailus
2022-09-22 15:23     ` Mikhail Rudenko
2022-09-22 20:39       ` Sakari Ailus
2022-09-22 10:54   ` Dave Stevenson
2022-09-22 14:56     ` Mikhail Rudenko
2022-09-14  9:58 ` [PATCH v2 0/2] Add Omnivision OV4689 image sensor driver Dave Stevenson
2022-09-15 21:27   ` Mikhail Rudenko
2022-09-19  6:40     ` Sakari Ailus
2022-09-19  7:01       ` Mikhail Rudenko
2022-09-19 10:31         ` Sakari Ailus
2022-09-19 13:49           ` Laurent Pinchart
2022-09-20 15:55             ` Mikhail Rudenko
2022-09-20 20:31             ` Mikhail Rudenko
2022-09-21 13:16               ` Sakari Ailus
2022-09-22  9:53 ` Sakari Ailus
2022-09-22 10:43   ` Dave Stevenson
2022-09-22 15:13     ` Mikhail Rudenko
2022-09-26 10:47     ` Mikhail Rudenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220919070813.GA3958@tom-ThinkPad-T14s-Gen-2i \
    --to=tommaso.merciai@amarulasolutions.com \
    --cc=c.hemp@phytec.de \
    --cc=devicetree@vger.kernel.org \
    --cc=djrscally@gmail.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jacopo@jmondi.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=mchehab@kernel.org \
    --cc=mike.rudenko@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=shawnx.tu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox