From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: linux-media@vger.kernel.org
Cc: guennadi.liakhovetski@intel.com, hans.verkuil@cisco.com,
"Frank Schäfer" <fschaefer.oss@googlemail.com>,
stable <stable@vger.kernel.org>
Subject: [PATCH 6/7] ov2640: fix vflip control
Date: Sun, 16 Apr 2017 19:35:45 +0200 [thread overview]
Message-ID: <20170416173546.4317-7-fschaefer.oss@googlemail.com> (raw)
In-Reply-To: <20170416173546.4317-1-fschaefer.oss@googlemail.com>
Enabling vflip currently causes wrong colors.
It seems that (at least with the current sensor setup) REG04_VFLIP_IMG only
changes the vertical readout direction.
Because pixels are arranged RGRG... in odd lines and GBGB... in even lines,
either a one line shift or even/odd line swap is required, too, but
apparently this doesn't happen.
I finally figured out that this can be done manually by setting
REG04_VREF_EN.
Looking at hflip, it turns out that bit REG04_HREF_EN is set there
permanetly, but according to my tests has no effect on the pixel readout
order.
So my conclusion is that the current documentation of sensor register 0x04
is wrong (has changed after preliminary datasheet version 2.2).
I'm pretty sure that automatic vertical line shift/switch can be enabled,
too, but until anyone finds ot how this works, we have to stick with manual
switching.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Cc: stable <stable@vger.kernel.org>
---
drivers/media/i2c/ov2640.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 123767c58e83..6aba0ffe486d 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -716,8 +716,10 @@ static int ov2640_s_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_VFLIP:
- val = ctrl->val ? REG04_VFLIP_IMG : 0x00;
- return ov2640_mask_set(client, REG04, REG04_VFLIP_IMG, val);
+ val = ctrl->val ? REG04_VFLIP_IMG | REG04_VREF_EN : 0x00;
+ return ov2640_mask_set(client, REG04,
+ REG04_VFLIP_IMG | REG04_VREF_EN, val);
+ /* NOTE: REG04_VREF_EN: 1 line shift / even/odd line swap */
case V4L2_CID_HFLIP:
val = ctrl->val ? REG04_HFLIP_IMG : 0x00;
return ov2640_mask_set(client, REG04, REG04_HFLIP_IMG, val);
--
2.12.2
parent reply other threads:[~2017-04-16 17:36 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20170416173546.4317-1-fschaefer.oss@googlemail.com>]
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=20170416173546.4317-7-fschaefer.oss@googlemail.com \
--to=fschaefer.oss@googlemail.com \
--cc=guennadi.liakhovetski@intel.com \
--cc=hans.verkuil@cisco.com \
--cc=linux-media@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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).