From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.aswsp.com ([193.34.35.150]:13914 "EHLO mail.aswsp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755546AbaAHL4s (ORCPT ); Wed, 8 Jan 2014 06:56:48 -0500 Message-ID: <52CD3CA6.3080704@parrot.com> Date: Wed, 8 Jan 2014 12:55:18 +0100 From: Julien BERAUD MIME-Version: 1.0 To: Enrico CC: , "linux-media@vger.kernel.org" , Laurent Pinchart Subject: Re: omap3isp device tree support References: <52A1A76A.6070301@epfl.ch> <52B04D70.8060201@epfl.ch> <52CA8137.8080307@parrot.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org List-ID: Le 07/01/2014 11:12, Enrico a écrit : > On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD wrote: >> Le 03/01/2014 12:30, Enrico a écrit : >>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico wrote: >>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >>>> wrote: >>>>> So I converted the iommu to DT (patches just sent), used pdata quirks >>>>> for the isp / mtv9032 data, added a few patches from other people >>>>> (mainly clk to fix a crash when deferring the omap3isp probe), and a few >>>>> small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) >>>>> to boot on DT with a working MT9V032 camera. The missing part is the DT >>>>> binding for the omap3isp, but I guess that we will have to wait a bit >>>>> more for this. >>>>> >>>>> If you want to test, I have a development tree here [1]. Any feedback is >>>>> welcome. >>>>> >>>>> Cheers, >>>>> >>>>> Florian >>>>> >>>>> [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt >>>> Thanks Florian, >>>> >>>> i will report what i get with my setup. >>> And here i am. >>> >>> I can confirm it works, video source is tvp5150 (with platform data in >>> pdata-quirks.c) in bt656 mode. >>> >>> Laurent, i used the two bt656 patches from your omap3isp/bt656 tree so >>> if you want to push it you can add a Tested-by me. >>> >>> There is only one problem, but it's unrelated to your DT work. >>> >>> It's an old problem (see for example [1] and [2]), seen by other >>> people too and it seems it's still there. >>> Basically if i capture with yavta while the system is idle then it >>> just waits without getting any frame. >>> If i add some cpu load (usually i do a "cat /dev/zero" in a ssh >>> terminal) it starts capturing correctly. >>> >>> The strange thing is that i do get isp interrupts in the idle case, so >>> i don't know why they don't "propagate" to yavta. >>> >>> Any hints on how to debug this? >>> >>> Enrico >>> >>> [1]: https://linuxtv.org/patch/7836/ >>> [2]: >>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg44923.html >> I have had what looked a lot like these problems before and it was due to a >> wrong configuration of the ccdc cropping regarding to the blanking. Could >> you send me the configuration of the pipeline that you apply with media-ctl, >> just in case this is the same problem. > i'm using: > > media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP > CCDC":1->"OMAP3 ISP CCDC output":0[1]' > media-ctl --set-format '"tvp5150 2-005c":0 [UYVY 720x625]' > > And then capture with yavta -s 720x625 (or 720x576, can't remember right now). > > Thanks, > > Enrico I don't think this is sufficient, though I am no expert about omap3 isp, you should configure the format of the ccdc input and of the ccdc output too. When I had this problem, it was solved by adding cropping at the input of the CCDC, corresponding to the blanking period, which was : - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x576 (0,49/720x576)]' or - media-ctl -v -f '"OMAP3 ISP CCDC":0 [UYVY2X8 720x480 (0,45/720x480)]' respectively. I don't know if this can be of any help. Regards, Julien BERAUD