From: Mikhail Rudenko <mike.rudenko@gmail.com>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: arec.kao@intel.com, c.hemp@phytec.de,
dave.stevenson@raspberrypi.com, devicetree@vger.kernel.org,
hverkuil@xs4all.nl, jimmy.su@intel.com,
krzysztof.kozlowski+dt@linaro.org,
laurent.pinchart+renesas@ideasonboard.com,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
marex@denx.de, mchehab@kernel.org, rdunlap@infradead.org,
robh+dt@kernel.org, sakari.ailus@linux.intel.com,
shawnx.tu@intel.com, tommaso.merciai@amarulasolutions.com
Subject: Re: [PATCH v3 2/2] media: i2c: add support for OV4689
Date: Thu, 20 Oct 2022 03:22:59 +0300 [thread overview]
Message-ID: <87fsfjz67r.fsf@gmail.com> (raw)
In-Reply-To: <15ebc256-1855-7720-05e1-6673b1da7d93@wanadoo.fr>
Hi Christophe,
Thanks for the review! See my comments below.
On 2022-10-18 at 20:55 +02, Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
> Le 28/09/2022 à 00:21, Mikhail Rudenko a écrit :
>> Add a V4L2 sub-device driver for OmniVision OV4689 image sensor. This
>> is a 4 Mpx image sensor using the I2C bus for control and the CSI-2
>> bus for data.
>> This driver supports following features:
>> - manual exposure and analog gain control support
>> - test pattern support
>> - media controller support
>> - runtime PM support
>> - support following resolutions:
>> + 2688x1520 at 30 fps
>> The driver provides all mandatory V4L2 controls for compatibility
>> with
>> libcamera. The sensor supports 1/2/4-lane CSI-2 modes, but the driver
>> implements 4 lane mode only at this moment.
>
> Hi,
>
> a few nitpick below.
>
> CJ
>
>> Signed-off-by: Mikhail Rudenko
>> <mike.rudenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>
> [...]
>
>> +static int ov4689_check_sensor_id(struct ov4689 *ov4689,
>> + struct i2c_client *client)
>> +{
>> + struct device *dev = &ov4689->client->dev;
>> + u32 id = 0;
>> + int ret;
>> +
>> + ret = ov4689_read_reg(client, OV4689_REG_CHIP_ID,
>> + OV4689_REG_VALUE_16BIT, &id);
>> + if (id != CHIP_ID) {
>> + dev_err(dev, "Unexpected sensor id(%06x), ret(%d)\n", id, ret);
>> + return -ENODEV;
>
> return ret?
> (otherwise what is the point of -EINVAL and -EIO in ov4689_read_reg()?)
>
Maybe we should reserve -ENODEV for the case when
ret==0 && id != CHIP_ID and return ret otherwise?
What do you think about it?
>> + }
>> +
>> + dev_info(dev, "Detected OV%06x sensor\n", CHIP_ID);
>> +
>> + return 0;
>> +}
>
> [...]
>
>> +static int ov4689_probe(struct i2c_client *client)
>> +{
>> + struct device *dev = &client->dev;
>> + struct v4l2_subdev *sd;
>> + struct ov4689 *ov4689;
>> + int ret;
>> +
>> + ret = ov4689_check_hwcfg(dev);
>> + if (ret)
>> + return ret;
>> +
>> + ov4689 = devm_kzalloc(dev, sizeof(*ov4689), GFP_KERNEL);
>> + if (!ov4689)
>> + return -ENOMEM;
>> +
>> + ov4689->client = client;
>> + ov4689->cur_mode = &supported_modes[OV4689_MODE_2688_1520];
>> +
>> + ov4689->xvclk = devm_clk_get_optional(dev, NULL);
>> + if (IS_ERR(ov4689->xvclk)) {
>> + return dev_err_probe(dev, PTR_ERR(ov4689->xvclk),
>> + "Failed to get external clock\n");
>> + }
>> +
>> + if (!ov4689->xvclk) {
>> + dev_dbg(dev,
>> + "No clock provided, using clock-frequency property\n");
>> + device_property_read_u32(dev, "clock-frequency", &ov4689->clock_rate);
>> + } else {
>> + ov4689->clock_rate = clk_get_rate(ov4689->xvclk);
>> + }
>> +
>> + if (ov4689->clock_rate != OV4689_XVCLK_FREQ) {
>> + dev_err(dev,
>> + "External clock rate mismatch: got %d Hz, expected %d Hz\n",
>> + ov4689->clock_rate, OV4689_XVCLK_FREQ);
>> + return -EINVAL;
>> + }
>> +
>> + ov4689->reset_gpio = devm_gpiod_get_optional(dev, "reset",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(ov4689->reset_gpio)) {
>> + dev_err(dev, "Failed to get reset-gpios\n");
>> + return PTR_ERR(ov4689->reset_gpio);
>> + }
>> +
>> + ov4689->pwdn_gpio = devm_gpiod_get_optional(dev, "pwdn", GPIOD_OUT_LOW);
>> + if (IS_ERR(ov4689->pwdn_gpio)) {
>> + dev_err(dev, "Failed to get pwdn-gpios\n");
>> + return PTR_ERR(ov4689->pwdn_gpio);
>> + }
>> +
>> + ret = ov4689_configure_regulators(ov4689);
>> + if (ret) {
>> + dev_err(dev, "Failed to get power regulators\n");
>
> dev_err_probe()?
> I think that devm_regulator_bulk_get() can return -EPROBE_DEFER)
>
Nice catch, will fix in v4.
>> + return ret;
>> + }
>> +
>> + mutex_init(&ov4689->mutex);
>> +
>> + sd = &ov4689->subdev;
>> + v4l2_i2c_subdev_init(sd, client, &ov4689_subdev_ops);
>> + ret = ov4689_initialize_controls(ov4689);
>> + if (ret)
>> + goto err_destroy_mutex;
>> +
>> + ret = ov4689_power_on(dev);
>> + if (ret)
>> + goto err_free_handler;
>> +
>> + ret = ov4689_check_sensor_id(ov4689, client);
>> + if (ret)
>> + goto err_power_off;
>> +
>> +#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
>> + sd->internal_ops = &ov4689_internal_ops;
>> + sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>> +#endif
>> +#if defined(CONFIG_MEDIA_CONTROLLER)
>> + ov4689->pad.flags = MEDIA_PAD_FL_SOURCE;
>> + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
>> + ret = media_entity_pads_init(&sd->entity, 1, &ov4689->pad);
>> + if (ret < 0)
>> + goto err_power_off;
>> +#endif
>> +
>> + ret = v4l2_async_register_subdev_sensor(sd);
>> + if (ret) {
>> + dev_err(dev, "v4l2 async register subdev failed\n");
>> + goto err_clean_entity;
>> + }
>> +
>> + pm_runtime_set_active(dev);
>> + pm_runtime_enable(dev);
>> + pm_runtime_idle(dev);
>> +
>> + return 0;
>> +
>> +err_clean_entity:
>> + media_entity_cleanup(&sd->entity);
>> +err_power_off:
>> + ov4689_power_off(dev);
>> +err_free_handler:
>> + v4l2_ctrl_handler_free(&ov4689->ctrl_handler);
>> +err_destroy_mutex:
>> + mutex_destroy(&ov4689->mutex);
>> +
>> + return ret;
>> +}
>
> [...]
--
Best regards,
Mikhail Rudenko
next prev parent reply other threads:[~2022-10-20 0:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 22:21 [PATCH v3 0/2] Add Omnivision OV4689 image sensor driver Mikhail Rudenko
2022-09-27 22:21 ` [PATCH v3 1/2] media: dt-bindings: i2c: document OV4689 Mikhail Rudenko
2022-09-28 8:08 ` Krzysztof Kozlowski
2022-09-27 22:21 ` [PATCH v3 2/2] media: i2c: add support for OV4689 Mikhail Rudenko
2022-10-18 17:58 ` Jacopo Mondi
2022-10-19 23:34 ` Mikhail Rudenko
2022-10-18 18:55 ` Christophe JAILLET
2022-10-20 0:22 ` Mikhail Rudenko [this message]
2022-10-19 8:23 ` Sakari Ailus
2022-10-19 23:13 ` Mikhail Rudenko
2022-10-17 13:05 ` [PATCH v3 0/2] Add Omnivision OV4689 image sensor driver 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=87fsfjz67r.fsf@gmail.com \
--to=mike.rudenko@gmail.com \
--cc=arec.kao@intel.com \
--cc=c.hemp@phytec.de \
--cc=christophe.jaillet@wanadoo.fr \
--cc=dave.stevenson@raspberrypi.com \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil@xs4all.nl \
--cc=jimmy.su@intel.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=marex@denx.de \
--cc=mchehab@kernel.org \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=shawnx.tu@intel.com \
--cc=tommaso.merciai@amarulasolutions.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.