linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jacopo mondi <jacopo@jmondi.org>
To: Sam Bobrowicz <sam@elite-embedded.com>
Cc: linux-media@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Hugues Fruchet <hugues.fruchet@st.com>,
	loic.poulain@linaro.org, slongerbeam@gmail.com,
	daniel@zonque.org, maxime.ripard@bootlin.com
Subject: Re: [PATCH 1/4] media: ov5640: fix resolution update
Date: Wed, 10 Oct 2018 12:58:04 +0200	[thread overview]
Message-ID: <20181010105804.GD7677@w540> (raw)
In-Reply-To: <1539067682-60604-2-git-send-email-sam@elite-embedded.com>

[-- Attachment #1: Type: text/plain, Size: 4223 bytes --]

Hi Sam,
   thanks for the patch, I see the same issue you reported, but I
think this patch can be improved.

(expanding the Cc list to all people involved in recent ov5640
developemts, not just for this patch, but for the whole series to look
at. Copying names from another series cover letter, hope it is
complete.)

On Mon, Oct 08, 2018 at 11:47:59PM -0700, Sam Bobrowicz wrote:
> set_fmt was not properly triggering a mode change when
> a new mode was set that happened to have the same format
> as the previous mode (for example, when only changing the
> frame dimensions). Fix this.
>
> Signed-off-by: Sam Bobrowicz <sam@elite-embedded.com>
> ---
>  drivers/media/i2c/ov5640.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index eaefdb5..5031aab 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -2045,12 +2045,12 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
>  		goto out;
>  	}
>
> -	if (new_mode != sensor->current_mode) {
> +
> +	if (new_mode != sensor->current_mode ||
> +	    mbus_fmt->code != sensor->fmt.code) {
> +		sensor->fmt = *mbus_fmt;
>  		sensor->current_mode = new_mode;
>  		sensor->pending_mode_change = true;
> -	}
> -	if (mbus_fmt->code != sensor->fmt.code) {
> -		sensor->fmt = *mbus_fmt;
>  		sensor->pending_fmt_change = true;
>  	}

How I did reproduce the issue:

# Set 1024x768 on ov5640 without changing the image format
# (default image size at startup is 640x480)
$ media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/1024x768 field:none]"
  sensor->pending_mode_change = true; //verified this flag gets set

# Start streaming, after having configured the whole pipeline to work
# with 1024x768
$  yavta -c10 -n4 -f UYVY -s 1024x768 /dev/video4
   Unable to start streaming: Broken pipe (32).

# Inspect which part of pipeline validation went wrong
# Turns out the sensor->fmt field is not updated, and when get_fmt()
# is called, the old one is returned.
$ media-ctl -e "ov5640 2-003c" -p
  ...
  [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
                 ^^^ ^^^

So yes, sensor->fmt is not udapted as it should be when only image
resolution is changed.

Although I still see value in having two separate flags for the
'mode_change' (which in ov5640 lingo is resolution) and 'fmt_change' (which
in ov5640 lingo is the image format), and write their configuration to
registers only when they get actually changed.

For this reasons I would like to propse the following patch which I
have tested by:
1) changing resolution only
2) changing format only
3) change both

What do you and others think?

Thanks
  j

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index eaefdb5..e392b9d 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2020,6 +2020,7 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
        struct ov5640_dev *sensor = to_ov5640_dev(sd);
        const struct ov5640_mode_info *new_mode;
        struct v4l2_mbus_framefmt *mbus_fmt = &format->format;
+       struct v4l2_mbus_framefmt *fmt;
        int ret;

        if (format->pad != 0)
@@ -2037,22 +2038,19 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
        if (ret)
                goto out;

-       if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
-               struct v4l2_mbus_framefmt *fmt =
-                       v4l2_subdev_get_try_format(sd, cfg, 0);
+       if (format->which == V4L2_SUBDEV_FORMAT_TRY)
+               fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
+       else
+               fmt = &sensor->fmt;

-               *fmt = *mbus_fmt;
-               goto out;
-       }
+       *fmt = *mbus_fmt;

        if (new_mode != sensor->current_mode) {
                sensor->current_mode = new_mode;
                sensor->pending_mode_change = true;
        }
-       if (mbus_fmt->code != sensor->fmt.code) {
-               sensor->fmt = *mbus_fmt;
+       if (mbus_fmt->code != sensor->fmt.code)
                sensor->pending_fmt_change = true;
-       }
 out:
        mutex_unlock(&sensor->lock);
        return ret;

>  out:
> --
> 2.7.4
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2018-10-10 18:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09  6:47 [PATCH 0/4] ov5640: small fixes for compatibility Sam Bobrowicz
2018-10-09  6:47 ` [PATCH 1/4] media: ov5640: fix resolution update Sam Bobrowicz
2018-10-10 10:58   ` jacopo mondi [this message]
2018-10-10 12:41     ` Laurent Pinchart
2018-10-15 15:13       ` Hugues FRUCHET
2018-10-15 15:24         ` jacopo mondi
2018-10-16  8:49           ` Hugues FRUCHET
2018-10-16 12:15         ` Laurent Pinchart
2018-10-16 18:14           ` Samuel Bobrowicz
2018-10-09  6:48 ` [PATCH 2/4] media: ov5640: fix get_light_freq on auto Sam Bobrowicz
2018-10-10  8:49   ` jacopo mondi
2018-10-09  6:48 ` [PATCH 3/4] media: ov5640: Don't access ctrl regs when off Sam Bobrowicz
2018-10-10  8:48   ` jacopo mondi
2018-10-09  6:48 ` [PATCH 4/4] media: ov5640: Add additional media bus formats Sam Bobrowicz
2018-11-16 13:18   ` Sakari Ailus

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=20181010105804.GD7677@w540 \
    --to=jacopo@jmondi.org \
    --cc=daniel@zonque.org \
    --cc=hugues.fruchet@st.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=sam@elite-embedded.com \
    --cc=slongerbeam@gmail.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;
as well as URLs for NNTP newsgroup(s).