All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tfiga@chromium.org>
To: Dongchun Zhu <dongchun.zhu@mediatek.com>
Cc: mark.rutland@arm.com, drinkcat@chromium.org,
	andriy.shevchenko@linux.intel.com, srv_heupstream@mediatek.com,
	devicetree@vger.kernel.org, linus.walleij@linaro.org,
	shengnan.wang@mediatek.com, louis.kuo@mediatek.com,
	bgolaszewski@baylibre.com, sj.huang@mediatek.com,
	robh+dt@kernel.org, linux-mediatek@lists.infradead.org,
	sakari.ailus@linux.intel.com, matthias.bgg@gmail.com,
	bingbu.cao@intel.com, mchehab@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [V9, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
Date: Wed, 10 Jun 2020 19:44:55 +0000	[thread overview]
Message-ID: <20200610194455.GK201868@chromium.org> (raw)
In-Reply-To: <20200523084103.31276-3-dongchun.zhu@mediatek.com>

Hi Dongchun,

On Sat, May 23, 2020 at 04:41:03PM +0800, Dongchun Zhu wrote:
> Add a V4L2 sub-device driver for OV02A10 image sensor.
> 
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
>  MAINTAINERS                 |    1 +
>  drivers/media/i2c/Kconfig   |   13 +
>  drivers/media/i2c/Makefile  |    1 +
>  drivers/media/i2c/ov02a10.c | 1025 +++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 1040 insertions(+)
>  create mode 100644 drivers/media/i2c/ov02a10.c
> 

Thank you for the patch. Please see my comments inline.

[snip]
> diff --git a/drivers/media/i2c/ov02a10.c b/drivers/media/i2c/ov02a10.c
> new file mode 100644
> index 0000000..160a0b5
> --- /dev/null
> +++ b/drivers/media/i2c/ov02a10.c
[snip]
> +static const char * const ov02a10_test_pattern_menu[] = {
> +	"Disabled",
> +	"Color Bar",

nit: We should normalize this to one of the standard names. What is the
pattern on this sensor? Is it perhaps "Eight Vertical Colour Bars"?

> +};
[snip]
> +static int ov02a10_set_fmt(struct v4l2_subdev *sd,
> +			   struct v4l2_subdev_pad_config *cfg,
> +			   struct v4l2_subdev_format *fmt)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +	struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> +	mutex_lock(&ov02a10->mutex);
> +


Don't we need to handle the case when fmt->which is V4L2_SUBDEV_FORMAT_TRY,
which is used for trying the format, but not applying it to the hardware?

> +	if (ov02a10->streaming) {
> +		mutex_unlock(&ov02a10->mutex);
> +		return -EBUSY;
> +	}
> +
> +	/* Only one sensor mode supported */
> +	mbus_fmt->code = ov02a10->fmt.code;
> +	ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> +	ov02a10->fmt = fmt->format;
> +
> +	mutex_unlock(&ov02a10->mutex);
> +
> +	return 0;
> +}
> +
> +static int ov02a10_get_fmt(struct v4l2_subdev *sd,
> +			   struct v4l2_subdev_pad_config *cfg,
> +			   struct v4l2_subdev_format *fmt)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +	struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> +	mutex_lock(&ov02a10->mutex);
> +
> +	fmt->format = ov02a10->fmt;

Ditto.

> +	mbus_fmt->code = ov02a10->fmt.code;
> +	ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> +
> +	mutex_unlock(&ov02a10->mutex);
> +
> +	return 0;
> +}
> +
> +static int ov02a10_enum_mbus_code(struct v4l2_subdev *sd,
> +				  struct v4l2_subdev_pad_config *cfg,
> +				  struct v4l2_subdev_mbus_code_enum *code)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +
> +	if (code->index >= ARRAY_SIZE(supported_modes))
> +		return -EINVAL;

Hmm, supported_modes[] doesn't seem to hold the information about mbus
codes. Should this just perhaps be "!= 0"?

> +
> +	code->code = ov02a10->fmt.code;
> +
> +	return 0;
> +}
[snip]
> +static int ov02a10_entity_init_cfg(struct v4l2_subdev *sd,
> +				   struct v4l2_subdev_pad_config *cfg)
> +{
> +	struct v4l2_subdev_format fmt = {
> +		.which = cfg ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE,
> +		.format = {
> +			.width = 1600,
> +			.height = 1200,
> +		}
> +	};
> +
> +	ov02a10_set_fmt(sd, cfg, &fmt);
> +
> +	return 0;
> +}
> +

I'm not familiar with this init_cfg operation and the documentation is very
sparse about it. Sakari, is this a correct implementation?

[snip]
> +static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, int pattern)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> +	int ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_TEST_PATTERN,
> +					pattern);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
> +					REG_ENABLE);
> +	if (ret < 0)
> +		return ret;
> +
> +	return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
> +					 SC_CTRL_MODE_STREAMING);

Why is this needed? Does writing the test pattern register stop streaming?

[snip]
> +static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> +	const struct ov02a10_mode *mode;
> +	struct v4l2_ctrl_handler *handler;
> +	struct v4l2_ctrl *ctrl;
> +	u64 exposure_max;
> +	u32 pixel_rate;
> +	int ret;
> +
> +	handler = &ov02a10->ctrl_handler;
> +	mode = ov02a10->cur_mode;
> +	ret = v4l2_ctrl_handler_init(handler, 7);
> +	if (ret)
> +		return ret;
> +
> +	handler->lock = &ov02a10->mutex;
> +
> +	ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ, 0, 0,
> +				      link_freq_menu_items);
> +	if (ctrl)
> +		ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	pixel_rate = to_pixel_rate(0);
> +	v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, pixel_rate, 1,
> +			  pixel_rate);
> +
> +	exposure_max = mode->vts_def - 4;
> +	ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> +					      V4L2_CID_EXPOSURE,
> +					      OV02A10_EXPOSURE_MIN,
> +					      exposure_max,
> +					      OV02A10_EXPOSURE_STEP,
> +					      mode->exp_def);
> +
> +	v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> +			  V4L2_CID_ANALOGUE_GAIN,
> +			  OV02A10_GAIN_MIN,
> +			  OV02A10_GAIN_MAX,
> +			  OV02A10_GAIN_STEP,
> +			  OV02A10_GAIN_DEFAULT);
> +
> +	v4l2_ctrl_new_std_menu_items(handler, &ov02a10_ctrl_ops,
> +				     V4L2_CID_TEST_PATTERN,
> +				     ARRAY_SIZE(ov02a10_test_pattern_menu) - 1,
> +				     0, 0, ov02a10_test_pattern_menu);
> +

I can see that we're missing some controls here now, VBLANK and HBLANK if I
remember correctly. Even though read-only, some userspace need those to
get information about how the sensor operates.

> +	if (handler->error) {
> +		ret = handler->error;
> +		dev_err(&client->dev, "failed to init controls(%d)\n", ret);
> +		goto err_free_handler;
> +	}
> +
> +	ov02a10->subdev.ctrl_handler = handler;
> +
> +	return 0;
> +
> +err_free_handler:
> +	v4l2_ctrl_handler_free(handler);
> +
> +	return ret;
> +}
[snip]
> +	pm_runtime_enable(dev);
> +	if (!pm_runtime_enabled(dev)) {
> +		ret = ov02a10_power_on(dev);
> +		if (ret < 0) {
> +			dev_err(dev, "failed to power on: %d\n", ret);
> +			goto err_free_handler;
> +		}
> +	}
> +
> +	ret = v4l2_async_register_subdev(&ov02a10->subdev);
> +	if (ret) {
> +		dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> +		if (!pm_runtime_enabled(dev))
> +			ov02a10_power_off(dev);

Please don't mix inline and error-path error handling, as it makes it
difficult to tell if it's correct. Please move this below the appropriate
err label instead.

> +		goto err_clean_entity;
> +	}
> +
> +	return 0;
> +
> +err_clean_entity:

If one calls pm_runtime_enable() in the probe path, one needs to call
pm_runtime_disable() on the error and remove paths.

> +	media_entity_cleanup(&ov02a10->subdev.entity);
> +err_free_handler:
> +	v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
> +err_destroy_mutex:
> +	mutex_destroy(&ov02a10->mutex);
> +
> +	return ret;
> +}
> +

Best regards,
Tomasz

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tfiga@chromium.org>
To: Dongchun Zhu <dongchun.zhu@mediatek.com>
Cc: mark.rutland@arm.com, drinkcat@chromium.org,
	andriy.shevchenko@linux.intel.com, srv_heupstream@mediatek.com,
	devicetree@vger.kernel.org, linus.walleij@linaro.org,
	shengnan.wang@mediatek.com, louis.kuo@mediatek.com,
	bgolaszewski@baylibre.com, sj.huang@mediatek.com,
	robh+dt@kernel.org, linux-mediatek@lists.infradead.org,
	sakari.ailus@linux.intel.com, matthias.bgg@gmail.com,
	bingbu.cao@intel.com, mchehab@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [V9, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
Date: Wed, 10 Jun 2020 19:44:55 +0000	[thread overview]
Message-ID: <20200610194455.GK201868@chromium.org> (raw)
In-Reply-To: <20200523084103.31276-3-dongchun.zhu@mediatek.com>

Hi Dongchun,

On Sat, May 23, 2020 at 04:41:03PM +0800, Dongchun Zhu wrote:
> Add a V4L2 sub-device driver for OV02A10 image sensor.
> 
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
>  MAINTAINERS                 |    1 +
>  drivers/media/i2c/Kconfig   |   13 +
>  drivers/media/i2c/Makefile  |    1 +
>  drivers/media/i2c/ov02a10.c | 1025 +++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 1040 insertions(+)
>  create mode 100644 drivers/media/i2c/ov02a10.c
> 

Thank you for the patch. Please see my comments inline.

[snip]
> diff --git a/drivers/media/i2c/ov02a10.c b/drivers/media/i2c/ov02a10.c
> new file mode 100644
> index 0000000..160a0b5
> --- /dev/null
> +++ b/drivers/media/i2c/ov02a10.c
[snip]
> +static const char * const ov02a10_test_pattern_menu[] = {
> +	"Disabled",
> +	"Color Bar",

nit: We should normalize this to one of the standard names. What is the
pattern on this sensor? Is it perhaps "Eight Vertical Colour Bars"?

> +};
[snip]
> +static int ov02a10_set_fmt(struct v4l2_subdev *sd,
> +			   struct v4l2_subdev_pad_config *cfg,
> +			   struct v4l2_subdev_format *fmt)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +	struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> +	mutex_lock(&ov02a10->mutex);
> +


Don't we need to handle the case when fmt->which is V4L2_SUBDEV_FORMAT_TRY,
which is used for trying the format, but not applying it to the hardware?

> +	if (ov02a10->streaming) {
> +		mutex_unlock(&ov02a10->mutex);
> +		return -EBUSY;
> +	}
> +
> +	/* Only one sensor mode supported */
> +	mbus_fmt->code = ov02a10->fmt.code;
> +	ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> +	ov02a10->fmt = fmt->format;
> +
> +	mutex_unlock(&ov02a10->mutex);
> +
> +	return 0;
> +}
> +
> +static int ov02a10_get_fmt(struct v4l2_subdev *sd,
> +			   struct v4l2_subdev_pad_config *cfg,
> +			   struct v4l2_subdev_format *fmt)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +	struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> +	mutex_lock(&ov02a10->mutex);
> +
> +	fmt->format = ov02a10->fmt;

Ditto.

> +	mbus_fmt->code = ov02a10->fmt.code;
> +	ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> +
> +	mutex_unlock(&ov02a10->mutex);
> +
> +	return 0;
> +}
> +
> +static int ov02a10_enum_mbus_code(struct v4l2_subdev *sd,
> +				  struct v4l2_subdev_pad_config *cfg,
> +				  struct v4l2_subdev_mbus_code_enum *code)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +
> +	if (code->index >= ARRAY_SIZE(supported_modes))
> +		return -EINVAL;

Hmm, supported_modes[] doesn't seem to hold the information about mbus
codes. Should this just perhaps be "!= 0"?

> +
> +	code->code = ov02a10->fmt.code;
> +
> +	return 0;
> +}
[snip]
> +static int ov02a10_entity_init_cfg(struct v4l2_subdev *sd,
> +				   struct v4l2_subdev_pad_config *cfg)
> +{
> +	struct v4l2_subdev_format fmt = {
> +		.which = cfg ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE,
> +		.format = {
> +			.width = 1600,
> +			.height = 1200,
> +		}
> +	};
> +
> +	ov02a10_set_fmt(sd, cfg, &fmt);
> +
> +	return 0;
> +}
> +

I'm not familiar with this init_cfg operation and the documentation is very
sparse about it. Sakari, is this a correct implementation?

[snip]
> +static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, int pattern)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> +	int ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_TEST_PATTERN,
> +					pattern);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
> +					REG_ENABLE);
> +	if (ret < 0)
> +		return ret;
> +
> +	return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
> +					 SC_CTRL_MODE_STREAMING);

Why is this needed? Does writing the test pattern register stop streaming?

[snip]
> +static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> +	const struct ov02a10_mode *mode;
> +	struct v4l2_ctrl_handler *handler;
> +	struct v4l2_ctrl *ctrl;
> +	u64 exposure_max;
> +	u32 pixel_rate;
> +	int ret;
> +
> +	handler = &ov02a10->ctrl_handler;
> +	mode = ov02a10->cur_mode;
> +	ret = v4l2_ctrl_handler_init(handler, 7);
> +	if (ret)
> +		return ret;
> +
> +	handler->lock = &ov02a10->mutex;
> +
> +	ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ, 0, 0,
> +				      link_freq_menu_items);
> +	if (ctrl)
> +		ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	pixel_rate = to_pixel_rate(0);
> +	v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, pixel_rate, 1,
> +			  pixel_rate);
> +
> +	exposure_max = mode->vts_def - 4;
> +	ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> +					      V4L2_CID_EXPOSURE,
> +					      OV02A10_EXPOSURE_MIN,
> +					      exposure_max,
> +					      OV02A10_EXPOSURE_STEP,
> +					      mode->exp_def);
> +
> +	v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> +			  V4L2_CID_ANALOGUE_GAIN,
> +			  OV02A10_GAIN_MIN,
> +			  OV02A10_GAIN_MAX,
> +			  OV02A10_GAIN_STEP,
> +			  OV02A10_GAIN_DEFAULT);
> +
> +	v4l2_ctrl_new_std_menu_items(handler, &ov02a10_ctrl_ops,
> +				     V4L2_CID_TEST_PATTERN,
> +				     ARRAY_SIZE(ov02a10_test_pattern_menu) - 1,
> +				     0, 0, ov02a10_test_pattern_menu);
> +

I can see that we're missing some controls here now, VBLANK and HBLANK if I
remember correctly. Even though read-only, some userspace need those to
get information about how the sensor operates.

> +	if (handler->error) {
> +		ret = handler->error;
> +		dev_err(&client->dev, "failed to init controls(%d)\n", ret);
> +		goto err_free_handler;
> +	}
> +
> +	ov02a10->subdev.ctrl_handler = handler;
> +
> +	return 0;
> +
> +err_free_handler:
> +	v4l2_ctrl_handler_free(handler);
> +
> +	return ret;
> +}
[snip]
> +	pm_runtime_enable(dev);
> +	if (!pm_runtime_enabled(dev)) {
> +		ret = ov02a10_power_on(dev);
> +		if (ret < 0) {
> +			dev_err(dev, "failed to power on: %d\n", ret);
> +			goto err_free_handler;
> +		}
> +	}
> +
> +	ret = v4l2_async_register_subdev(&ov02a10->subdev);
> +	if (ret) {
> +		dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> +		if (!pm_runtime_enabled(dev))
> +			ov02a10_power_off(dev);

Please don't mix inline and error-path error handling, as it makes it
difficult to tell if it's correct. Please move this below the appropriate
err label instead.

> +		goto err_clean_entity;
> +	}
> +
> +	return 0;
> +
> +err_clean_entity:

If one calls pm_runtime_enable() in the probe path, one needs to call
pm_runtime_disable() on the error and remove paths.

> +	media_entity_cleanup(&ov02a10->subdev.entity);
> +err_free_handler:
> +	v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
> +err_destroy_mutex:
> +	mutex_destroy(&ov02a10->mutex);
> +
> +	return ret;
> +}
> +

Best regards,
Tomasz

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tfiga@chromium.org>
To: Dongchun Zhu <dongchun.zhu@mediatek.com>
Cc: linus.walleij@linaro.org, bgolaszewski@baylibre.com,
	mchehab@kernel.org, andriy.shevchenko@linux.intel.com,
	robh+dt@kernel.org, mark.rutland@arm.com,
	sakari.ailus@linux.intel.com, drinkcat@chromium.org,
	matthias.bgg@gmail.com, bingbu.cao@intel.com,
	srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, sj.huang@mediatek.com,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	louis.kuo@mediatek.com, shengnan.wang@mediatek.com
Subject: Re: [V9, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
Date: Wed, 10 Jun 2020 19:44:55 +0000	[thread overview]
Message-ID: <20200610194455.GK201868@chromium.org> (raw)
In-Reply-To: <20200523084103.31276-3-dongchun.zhu@mediatek.com>

Hi Dongchun,

On Sat, May 23, 2020 at 04:41:03PM +0800, Dongchun Zhu wrote:
> Add a V4L2 sub-device driver for OV02A10 image sensor.
> 
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
>  MAINTAINERS                 |    1 +
>  drivers/media/i2c/Kconfig   |   13 +
>  drivers/media/i2c/Makefile  |    1 +
>  drivers/media/i2c/ov02a10.c | 1025 +++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 1040 insertions(+)
>  create mode 100644 drivers/media/i2c/ov02a10.c
> 

Thank you for the patch. Please see my comments inline.

[snip]
> diff --git a/drivers/media/i2c/ov02a10.c b/drivers/media/i2c/ov02a10.c
> new file mode 100644
> index 0000000..160a0b5
> --- /dev/null
> +++ b/drivers/media/i2c/ov02a10.c
[snip]
> +static const char * const ov02a10_test_pattern_menu[] = {
> +	"Disabled",
> +	"Color Bar",

nit: We should normalize this to one of the standard names. What is the
pattern on this sensor? Is it perhaps "Eight Vertical Colour Bars"?

> +};
[snip]
> +static int ov02a10_set_fmt(struct v4l2_subdev *sd,
> +			   struct v4l2_subdev_pad_config *cfg,
> +			   struct v4l2_subdev_format *fmt)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +	struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> +	mutex_lock(&ov02a10->mutex);
> +


Don't we need to handle the case when fmt->which is V4L2_SUBDEV_FORMAT_TRY,
which is used for trying the format, but not applying it to the hardware?

> +	if (ov02a10->streaming) {
> +		mutex_unlock(&ov02a10->mutex);
> +		return -EBUSY;
> +	}
> +
> +	/* Only one sensor mode supported */
> +	mbus_fmt->code = ov02a10->fmt.code;
> +	ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> +	ov02a10->fmt = fmt->format;
> +
> +	mutex_unlock(&ov02a10->mutex);
> +
> +	return 0;
> +}
> +
> +static int ov02a10_get_fmt(struct v4l2_subdev *sd,
> +			   struct v4l2_subdev_pad_config *cfg,
> +			   struct v4l2_subdev_format *fmt)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +	struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> +	mutex_lock(&ov02a10->mutex);
> +
> +	fmt->format = ov02a10->fmt;

Ditto.

> +	mbus_fmt->code = ov02a10->fmt.code;
> +	ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> +
> +	mutex_unlock(&ov02a10->mutex);
> +
> +	return 0;
> +}
> +
> +static int ov02a10_enum_mbus_code(struct v4l2_subdev *sd,
> +				  struct v4l2_subdev_pad_config *cfg,
> +				  struct v4l2_subdev_mbus_code_enum *code)
> +{
> +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +
> +	if (code->index >= ARRAY_SIZE(supported_modes))
> +		return -EINVAL;

Hmm, supported_modes[] doesn't seem to hold the information about mbus
codes. Should this just perhaps be "!= 0"?

> +
> +	code->code = ov02a10->fmt.code;
> +
> +	return 0;
> +}
[snip]
> +static int ov02a10_entity_init_cfg(struct v4l2_subdev *sd,
> +				   struct v4l2_subdev_pad_config *cfg)
> +{
> +	struct v4l2_subdev_format fmt = {
> +		.which = cfg ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE,
> +		.format = {
> +			.width = 1600,
> +			.height = 1200,
> +		}
> +	};
> +
> +	ov02a10_set_fmt(sd, cfg, &fmt);
> +
> +	return 0;
> +}
> +

I'm not familiar with this init_cfg operation and the documentation is very
sparse about it. Sakari, is this a correct implementation?

[snip]
> +static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, int pattern)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> +	int ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_TEST_PATTERN,
> +					pattern);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
> +					REG_ENABLE);
> +	if (ret < 0)
> +		return ret;
> +
> +	return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
> +					 SC_CTRL_MODE_STREAMING);

Why is this needed? Does writing the test pattern register stop streaming?

[snip]
> +static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> +	const struct ov02a10_mode *mode;
> +	struct v4l2_ctrl_handler *handler;
> +	struct v4l2_ctrl *ctrl;
> +	u64 exposure_max;
> +	u32 pixel_rate;
> +	int ret;
> +
> +	handler = &ov02a10->ctrl_handler;
> +	mode = ov02a10->cur_mode;
> +	ret = v4l2_ctrl_handler_init(handler, 7);
> +	if (ret)
> +		return ret;
> +
> +	handler->lock = &ov02a10->mutex;
> +
> +	ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ, 0, 0,
> +				      link_freq_menu_items);
> +	if (ctrl)
> +		ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	pixel_rate = to_pixel_rate(0);
> +	v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, pixel_rate, 1,
> +			  pixel_rate);
> +
> +	exposure_max = mode->vts_def - 4;
> +	ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> +					      V4L2_CID_EXPOSURE,
> +					      OV02A10_EXPOSURE_MIN,
> +					      exposure_max,
> +					      OV02A10_EXPOSURE_STEP,
> +					      mode->exp_def);
> +
> +	v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> +			  V4L2_CID_ANALOGUE_GAIN,
> +			  OV02A10_GAIN_MIN,
> +			  OV02A10_GAIN_MAX,
> +			  OV02A10_GAIN_STEP,
> +			  OV02A10_GAIN_DEFAULT);
> +
> +	v4l2_ctrl_new_std_menu_items(handler, &ov02a10_ctrl_ops,
> +				     V4L2_CID_TEST_PATTERN,
> +				     ARRAY_SIZE(ov02a10_test_pattern_menu) - 1,
> +				     0, 0, ov02a10_test_pattern_menu);
> +

I can see that we're missing some controls here now, VBLANK and HBLANK if I
remember correctly. Even though read-only, some userspace need those to
get information about how the sensor operates.

> +	if (handler->error) {
> +		ret = handler->error;
> +		dev_err(&client->dev, "failed to init controls(%d)\n", ret);
> +		goto err_free_handler;
> +	}
> +
> +	ov02a10->subdev.ctrl_handler = handler;
> +
> +	return 0;
> +
> +err_free_handler:
> +	v4l2_ctrl_handler_free(handler);
> +
> +	return ret;
> +}
[snip]
> +	pm_runtime_enable(dev);
> +	if (!pm_runtime_enabled(dev)) {
> +		ret = ov02a10_power_on(dev);
> +		if (ret < 0) {
> +			dev_err(dev, "failed to power on: %d\n", ret);
> +			goto err_free_handler;
> +		}
> +	}
> +
> +	ret = v4l2_async_register_subdev(&ov02a10->subdev);
> +	if (ret) {
> +		dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> +		if (!pm_runtime_enabled(dev))
> +			ov02a10_power_off(dev);

Please don't mix inline and error-path error handling, as it makes it
difficult to tell if it's correct. Please move this below the appropriate
err label instead.

> +		goto err_clean_entity;
> +	}
> +
> +	return 0;
> +
> +err_clean_entity:

If one calls pm_runtime_enable() in the probe path, one needs to call
pm_runtime_disable() on the error and remove paths.

> +	media_entity_cleanup(&ov02a10->subdev.entity);
> +err_free_handler:
> +	v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
> +err_destroy_mutex:
> +	mutex_destroy(&ov02a10->mutex);
> +
> +	return ret;
> +}
> +

Best regards,
Tomasz

  parent reply	other threads:[~2020-06-10 19:45 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-23  8:41 [V9, 0/2] media: i2c: Add support for OV02A10 sensor Dongchun Zhu
2020-05-23  8:41 ` Dongchun Zhu
2020-05-23  8:41 ` Dongchun Zhu
2020-05-23  8:41 ` [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings Dongchun Zhu
2020-05-23  8:41   ` Dongchun Zhu
2020-05-23  8:41   ` Dongchun Zhu
2020-05-26 18:28   ` Rob Herring
2020-05-26 18:28     ` Rob Herring
2020-05-26 18:28     ` Rob Herring
2020-05-27  8:49     ` Dongchun Zhu
2020-05-27  8:49       ` Dongchun Zhu
2020-05-27  8:49       ` Dongchun Zhu
2020-05-27 15:27       ` Rob Herring
2020-05-27 15:27         ` Rob Herring
2020-05-27 15:27         ` Rob Herring
2020-05-27 21:16         ` Sakari Ailus
2020-05-27 21:16           ` Sakari Ailus
2020-05-27 21:16           ` Sakari Ailus
2020-05-28  3:34           ` Dongchun Zhu
2020-05-28  3:34             ` Dongchun Zhu
2020-05-28  3:34             ` Dongchun Zhu
2020-05-28  7:23             ` Sakari Ailus
2020-05-28  7:23               ` Sakari Ailus
2020-05-28  7:23               ` Sakari Ailus
2020-05-28  8:04               ` Dongchun Zhu
2020-05-28  8:04                 ` Dongchun Zhu
2020-05-28  8:04                 ` Dongchun Zhu
2020-05-29 13:43                 ` Tomasz Figa
2020-05-29 13:43                   ` Tomasz Figa
2020-05-29 13:43                   ` Tomasz Figa
2020-06-01  2:33                   ` Dongchun Zhu
2020-06-01  2:33                     ` Dongchun Zhu
2020-06-01  2:33                     ` Dongchun Zhu
2020-06-01 18:18                     ` Tomasz Figa
2020-06-01 18:18                       ` Tomasz Figa
2020-06-01 18:18                       ` Tomasz Figa
2020-06-02  6:15                       ` Dongchun Zhu
2020-06-02  6:15                         ` Dongchun Zhu
2020-06-02  6:15                         ` Dongchun Zhu
2020-06-02  9:56                         ` Sakari Ailus
2020-06-02  9:56                           ` Sakari Ailus
2020-06-02  9:56                           ` Sakari Ailus
2020-06-04  2:20                           ` Dongchun Zhu
2020-06-04  2:20                             ` Dongchun Zhu
2020-06-04  2:20                             ` Dongchun Zhu
2020-06-02  9:53                   ` Sakari Ailus
2020-06-02  9:53                     ` Sakari Ailus
2020-06-02  9:53                     ` Sakari Ailus
2020-05-28  5:53         ` Dongchun Zhu
2020-05-28  5:53           ` Dongchun Zhu
2020-05-28  5:53           ` Dongchun Zhu
2020-05-23  8:41 ` [V9, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver Dongchun Zhu
2020-05-23  8:41   ` Dongchun Zhu
2020-05-23  8:41   ` Dongchun Zhu
2020-06-04  2:14   ` Dongchun Zhu
2020-06-04  2:14     ` Dongchun Zhu
2020-06-04  2:14     ` Dongchun Zhu
2020-06-04  9:26     ` Sakari Ailus
2020-06-04  9:26       ` Sakari Ailus
2020-06-04  9:26       ` Sakari Ailus
2020-06-04 18:05       ` Tomasz Figa
2020-06-04 18:05         ` Tomasz Figa
2020-06-04 18:05         ` Tomasz Figa
2020-06-05  3:19       ` Dongchun Zhu
2020-06-05  3:19         ` Dongchun Zhu
2020-06-05  3:19         ` Dongchun Zhu
2020-06-10 19:44   ` Tomasz Figa [this message]
2020-06-10 19:44     ` Tomasz Figa
2020-06-10 19:44     ` Tomasz Figa
2020-06-11  9:53     ` Sakari Ailus
2020-06-11  9:53       ` Sakari Ailus
2020-06-11  9:53       ` Sakari Ailus
2020-06-11  9:57       ` Tomasz Figa
2020-06-11  9:57         ` Tomasz Figa
2020-06-11  9:57         ` Tomasz Figa
2020-06-11 10:03         ` Sakari Ailus
2020-06-11 10:03           ` Sakari Ailus
2020-06-11 10:03           ` Sakari Ailus
2020-06-12 11:01           ` Dongchun Zhu
2020-06-12 11:01             ` Dongchun Zhu
2020-06-12 11:01             ` Dongchun Zhu
2020-06-12 10:46     ` Dongchun Zhu
2020-06-12 10:46       ` Dongchun Zhu
2020-06-12 10:46       ` Dongchun Zhu
2020-06-12 18:39       ` Tomasz Figa
2020-06-12 18:39         ` Tomasz Figa
2020-06-12 18:39         ` Tomasz Figa
2020-06-15  5:54         ` Dongchun Zhu
2020-06-15  5:54           ` Dongchun Zhu
2020-06-15  5:54           ` Dongchun Zhu
2020-06-15 12:44           ` Tomasz Figa
2020-06-15 12:44             ` Tomasz Figa
2020-06-15 12:44             ` Tomasz Figa

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=20200610194455.GK201868@chromium.org \
    --to=tfiga@chromium.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=bingbu.cao@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dongchun.zhu@mediatek.com \
    --cc=drinkcat@chromium.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=louis.kuo@mediatek.com \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=shengnan.wang@mediatek.com \
    --cc=sj.huang@mediatek.com \
    --cc=srv_heupstream@mediatek.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.