All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.