From patchwork Sun Apr 16 17:35:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Frank Schaefer X-Patchwork-Id: 40868 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czo60-0005Ns-Gb; Sun, 16 Apr 2017 17:36:20 +0000 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.84_2/mailfrontend-7) with esmtp id 1czo5y-0004qS-0q; Sun, 16 Apr 2017 19:36:20 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756550AbdDPRgI (ORCPT + 1 other); Sun, 16 Apr 2017 13:36:08 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36368 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756532AbdDPRgE (ORCPT ); Sun, 16 Apr 2017 13:36:04 -0400 Received: by mail-wm0-f67.google.com with SMTP id q125so5870655wmd.3; Sun, 16 Apr 2017 10:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=p0k5XjUWzTvjhQJgiaRMA2D2FTrifUeFZ5hk3pqPIzE=; b=MbsdQ1t8z9rUlHYkB5dE7BFZt4brzhjosNegsFlI6ZglVE5HV9R4SwVVZCi7dyVBqW lcxGNET6nhb085SO6JfeHxhBSIIs8dX2E2WXIQ8+3TamTu1Y/ANE9rNd6GxZL2zCMT3a XRJwZKrynkxW+oOiv8B91TYTvzalOXZLA/W/OklFUcv5+4sp+Wi6p5IfW97OC2QnEhtf c5vGrmwf40A+4TcKRZHUg5tnlQEbmfbwIO86vIvgYy0jtPRFCkH313hEvJ9hXa66wrz2 26sy4G5hiUWL3ZMgkGVGYGpal+OXt/2E6A9e3fr90gvBD+MKSDTCezJ3EtZtcfzwSieq KSGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=p0k5XjUWzTvjhQJgiaRMA2D2FTrifUeFZ5hk3pqPIzE=; b=fiIg3LzTy6p/lIKXFVwmmIHbVmlCfDdSl8OHhcNmWIgAJmeZ7d6ByC101p/75o7381 Wc3uuCVu/zlMQw7yKwWibYgE7MMWBqC5rmN3/WfHNTA7pczlNE2kiUU1y1L6HUZQLubP 4wcZYPCG8YbFEUi0fhwmHeO4wm2Bf18CYBwfQSnOMArLpkjb7Zvi3kiY6LfH7xqc0w5k +DV/FnQIytXWEc5LU6bbA3zdhf8rahNos49FNsYaoB+0G8tRoMp03kp+98wueyQwgblQ ws8fr3bqgmb3YV3Gcl7dWsnYat4wnaxjpOPqPNKnJ0v8fqQ/ZK9fwbiWflNWymKTO8H8 444w== X-Gm-Message-State: AN3rC/5nfON21SPQCH7FrDTcY5cN92R4bXCIDLx/hf1DGw7jPzwaR4DQ CBPMgf3ijsG7jA== X-Received: by 10.28.212.148 with SMTP id l142mr1278913wmg.110.1492364163227; Sun, 16 Apr 2017 10:36:03 -0700 (PDT) Received: from Athlon64X2-5000.lan (ip-109-90-213-36.hsi11.unitymediagroup.de. [109.90.213.36]) by smtp.googlemail.com with ESMTPSA id l36sm8491642wrl.59.2017.04.16.10.36.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 16 Apr 2017 10:36:02 -0700 (PDT) From: =?UTF-8?q?Frank=20Sch=C3=A4fer?= To: linux-media@vger.kernel.org Cc: guennadi.liakhovetski@intel.com, hans.verkuil@cisco.com, =?UTF-8?q?Frank=20Sch=C3=A4fer?= , stable Subject: [PATCH 6/7] ov2640: fix vflip control Date: Sun, 16 Apr 2017 19:35:45 +0200 Message-Id: <20170416173546.4317-7-fschaefer.oss@googlemail.com> X-Mailer: git-send-email 2.12.2 In-Reply-To: <20170416173546.4317-1-fschaefer.oss@googlemail.com> References: <20170416173546.4317-1-fschaefer.oss@googlemail.com> MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.4.16.173016 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1800_1899 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CT_TEXT_PLAIN_UTF8_CAPS 0, DKIM_SIGNATURE 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_DOMAIN_IN_ANY_CC2 0, __FROM_DOMAIN_IN_RCPT 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_LIST_ID 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __YOUTUBE_RCVD 0' 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 Cc: stable --- 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);