From: jacopo mondi <jacopo@jmondi.org>
To: Hugues Fruchet <hugues.fruchet@st.com>
Cc: Steve Longerbeam <slongerbeam@gmail.com>,
Sakari Ailus <sakari.ailus@iki.fi>,
Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Maxime Ripard <maxime.ripard@bootlin.com>
Subject: Re: [PATCH] media: ov5640: fix mode change regression
Date: Tue, 28 Aug 2018 14:57:11 +0200 [thread overview]
Message-ID: <20180828125711.GE3566@w540> (raw)
In-Reply-To: <1534412813-10406-1-git-send-email-hugues.fruchet@st.com>
[-- Attachment #1: Type: text/plain, Size: 4649 bytes --]
Hi Hugues,
thanks for the patch
On Thu, Aug 16, 2018 at 11:46:53AM +0200, Hugues Fruchet wrote:
> fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame interval is unchanged").
>
> Symptom was fuzzy image because of JPEG default format
> not being changed according to new format selected, fix this.
> Init sequence initialises format to YUV422 UYVY but
> sensor->fmt initial value was set to JPEG, fix this.
>
> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
> drivers/media/i2c/ov5640.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 071f4bc..2ddd86d 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -223,6 +223,7 @@ struct ov5640_dev {
> int power_count;
>
> struct v4l2_mbus_framefmt fmt;
> + bool pending_fmt_change;
The foundamental issue here is that 'struct ov5640_mode_info' and
associated functions do not take the image format into account...
That would be the real fix, but I understand it requires changing and
re-testing a lot of stuff :(
But what if instead of adding more flags, don't we use bitfields in a single
"pending_changes" field? As when, and if, framerate will be made more
'dynamic' and we remove the static 15/30FPS configuration from
ov5640_mode_info, we will have the same problem we have today with
format with framerate too...
Something like:
struct ov5640_dev {
...
- bool pending_mode_change;
+ #define MODE_CHANGE BIT(0)
+ #define FMT_CHANGE BIT(1)
+ u8 pending;
...
}
>
> const struct ov5640_mode_info *current_mode;
> enum ov5640_frame_rate current_fr;
> @@ -255,7 +256,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
> * should be identified and removed to speed register load time
> * over i2c.
> */
> -
> +/* YUV422 UYVY VGA@30fps */
> static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
> {0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
> {0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
> @@ -1968,9 +1969,12 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
>
> if (new_mode != sensor->current_mode) {
> sensor->current_mode = new_mode;
> - sensor->fmt = *mbus_fmt;
> sensor->pending_mode_change = true;
> }
> + if (mbus_fmt->code != sensor->fmt.code) {
> + sensor->fmt = *mbus_fmt;
> + sensor->pending_fmt_change = true;
> + }
That would make this simpler
sensor->current_mode = new_mode;
sensor->fmt = *mbus_fmt;
if (new_mode != sensor->current_mode)
sensor->pending |= MODE_CHANGE;
if (mbus_fmt->code != sensor->fmt.code) {
sensor->pending |= FMT_CHANGE;
> out:
> mutex_unlock(&sensor->lock);
> return ret;
> @@ -2544,10 +2548,13 @@ static int ov5640_s_stream(struct v4l2_subdev *sd, int enable)
> ret = ov5640_set_mode(sensor, sensor->current_mode);
> if (ret)
> goto out;
> + }
>
> + if (enable && sensor->pending_fmt_change) {
> ret = ov5640_set_framefmt(sensor, &sensor->fmt);
> if (ret)
> goto out;
> + sensor->pending_fmt_change = false;
> }
>
And that would be accordingly:
if (sensor->pending & MODE_CHANGE) {
ret = ov5640_set_mode(sensor, sensor->current_mode);
....
}
if (sensor->pending & FMT_CHANGE) {
ret = ov5640_set_framefmt(sensor, &sensor->fmt);
...
}
What do you (and others) think?
Thanks
j
> if (sensor->ep.bus_type == V4L2_MBUS_CSI2)
> @@ -2642,9 +2649,14 @@ static int ov5640_probe(struct i2c_client *client,
> return -ENOMEM;
>
> sensor->i2c_client = client;
> +
> + /*
> + * default init sequence initialize sensor to
> + * YUV422 UYVY VGA@30fps
> + */
> fmt = &sensor->fmt;
> - fmt->code = ov5640_formats[0].code;
> - fmt->colorspace = ov5640_formats[0].colorspace;
> + fmt->code = MEDIA_BUS_FMT_UYVY8_2X8;
> + fmt->colorspace = V4L2_COLORSPACE_SRGB;
> fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace);
> fmt->quantization = V4L2_QUANTIZATION_FULL_RANGE;
> fmt->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(fmt->colorspace);
> @@ -2656,7 +2668,6 @@ static int ov5640_probe(struct i2c_client *client,
> sensor->current_fr = OV5640_30_FPS;
> sensor->current_mode =
> &ov5640_mode_data[OV5640_30_FPS][OV5640_MODE_VGA_640_480];
> - sensor->pending_mode_change = true;
>
> sensor->ae_target = 52;
>
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2018-08-28 16:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-16 9:46 [PATCH] media: ov5640: fix mode change regression Hugues Fruchet
2018-08-28 12:57 ` jacopo mondi [this message]
2018-08-28 12:59 ` jacopo mondi
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=20180828125711.GE3566@w540 \
--to=jacopo@jmondi.org \
--cc=benjamin.gaignard@linaro.org \
--cc=hugues.fruchet@st.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=maxime.ripard@bootlin.com \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@iki.fi \
--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 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.