Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753262AbdGCMXq (ORCPT ); Mon, 3 Jul 2017 08:23:46 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.161]:18666 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbdGCMXn (ORCPT ); Mon, 3 Jul 2017 08:23:43 -0400 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcecEarQROEYabkiUo6mCQKkACaUSHjxSQJPsPQ X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera From: "H. Nikolaus Schaller" In-Reply-To: <252d42bd-839c-ff60-a258-c736328a3eaf@st.com> Date: Mon, 3 Jul 2017 14:23:39 +0200 Cc: Laurent Pinchart , Sakari Ailus , Pavel Machek , Discussions about the Letux Kernel , LKML Content-Transfer-Encoding: 7bit Message-Id: References: <1498143942-12682-1-git-send-email-hugues.fruchet@st.com> <385A82AC-CC23-41BD-9F57-0232F713FED9@goldelico.com> <1E453955-0C1A-414B-BBB2-C64B6D0EF378@goldelico.com> <20170625091856.GA22791@amd> <20170626083927.GB9621@amd> <658307f3-7abe-5738-7a8a-2eff6e0902a1@st.com> <95B10899-9966-4844-9667-D2434968A492@goldelico.com> <85e62c47-e319-c801-376c-95f4d9cbf75a@st.com> <77bd3b8fe52643d68ecc821ec22bc0e6@SFHDAG5NODE1.st.com> <14B52F58-AE2B-46F7-851A-F31D4485C230@goldelico.com> <252d42bd-839c-ff60-a258-c736328a3eaf@st.com> To: Hugues FRUCHET X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3210 Lines: 85 Hi Hugues, > Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET : > > Hi Nikolaus, > > nothing really strange in trace, I wanted to check the latest S_FMT and > it is well 1280x1024 YUV: >>> [ 425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, > height=1024, pixelformat=UYVY, field=none, bytesperline=2560, > sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, > xfer_func=0 > Thanks for cross-checking. > You're right that it seems that the ISP is not seeing any data in input. > Have you double checked the polarities of sync signals ? I see > differences in devicetree: > 960 ov9655: endpoint { > 961 remote-endpoint = <¶llel_ep>; > 962 #if 0 // not used by camera driver - define &parellel_ep for isp > 963 bus-width = <8>; > 964 data-shift = <2>; /* Lines > 9:2 are used */ > 965 hsync-active = <1>; /* Active > high */ > 966 vsync-active = <1>; /* Active > high */ > 967 data-active = <1>; /* Active > high */ > 968 pclk-sample = <1>; /* Rising */ > 969 #endif > > Which has been commented out in flavour of: > > 1011 /* parallel camera interface */ > 1012 ¶llel_ep { > 1013 remote-endpoint = <&ov9655>; > 1014 ti,isp-clock-divisor = <1>; > 1015 ti,strobe-mode; > 1016 bus-width = <8>;/* Used data lines */ > 1017 data-shift = <2>; /* Lines 9:2 are used */ > 1018 hsync-active = <0>; /* Active low */ > 1019 vsync-active = <1>; /* Active high */ > 1020 data-active = <1>;/* Active high */ > 1021 pclk-sample = <1>;/* Rising */ > 1022 }; > > there is a difference regarding active level of hsync. Yes, this is from experimenting with our driver patch series to do the setup in the camera driver. Both chips can configure polarities but we now have only system defaults in the camera driver. Therefore, it is commented out for the camera DT node. The problem is that we never had all this working in DT mode so our setup here might indeed be buggy. On the other hand the polarity (HSYNC act. low and VSYNC act. high) does match the signals seen by oscilloscope. I will try asap if this makes a difference. There are only 4 combinations... My expectation is that wrong polarity would only move the active trigger point around so that I would expect an image shifted left/right or up/down. But I don't know enough details of the isp. If it is triggering sync not by edge but by state and stopping capture for the wrong state of the sync signal it might not receive enough lines or pixels as it was initialized for and therefore it may simply wait for more data instead of reporting "done with 1280x1024 pixels". > > Nevertheless seems OK if I check OMAP3 ISP register: > CCDC SYN_MODE=0x00071704 > #define ISPCCDC_SYN_MODE_VDPOL (1 << 2) > #define ISPCCDC_SYN_MODE_HDPOL (1 << 3) > > seems well that vertical is 1 and horizontal is 0. > BR and thanks, Nikolaus