linux-kernel - Re: [PATCH v1 0/6] Add support of OV9655 camera

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 8 Jul 2017 23:55:52 +0300
From:   Sakari Ailus <sakari.ailus@....fi>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Hugues FRUCHET <hugues.fruchet@...com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Pavel Machek <pavel@....cz>,
        LKML <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus,

On Wed, Jul 05, 2017 at 04:02:04PM +0200, H. Nikolaus Schaller wrote:
> Hi Sakari,
> 
> > Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> > 
> > Hi Hugues,
> > 
> >> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET <hugues.fruchet@...com>:
> >> 
> >> 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 = <&parallel_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 &parallel_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.
> >> 
> 
> I found your old e-mail with a similar issue (CCDC stop timeout):
> 
> https://www.spinics.net/lists/linux-media/msg60096.html
> 
> It looks as if our media-ctl commands are almost the same as in
> the example given by Adriano and it confirms that /dev/video2
> is the right channel.
> 
> In your answer you recommended to check /proc/interrupts which
> did help Adriano.
> 
> Yes, we see the "OMAP3 ISP" entry go up roughly with 15-20
> interrupts per second. This means VSYNC seems to arrive at ~15 fps.
> 
> But we still have the timeouts and no image in mplayer.
> 
> Can we easily check if HSYNC is also arriving at the CCDC or has
> wrong polarity?

What you can try to switch the polarity in CCDC configuration. The CCDC
processes a pre-determined number of lines and if the hsync polarity
configuration is wrong, it will likely end up missing one. This should be
especially easy to misconfigure with serial busses but this isn't the
problem here as you have a parallel bus. You could try switching the vsync
polarity, too.

There are probably better informed people around, I've never used the
parallel interface (except with the CCP2 / CSI-2 receivers).

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@....fi	XMPP: sailus@...iisi.org.uk