On Fri, Jan 10, 2014 at 10:02 AM, Julien BERAUD <julien.ber...@parrot.com> wrote: > > Le 09/01/2014 19:14, Enrico a écrit : > >> On Wed, Jan 8, 2014 at 12:55 PM, Julien BERAUD <julien.ber...@parrot.com> >> wrote: >>> >>> Le 07/01/2014 11:12, Enrico a écrit : >>> >>>> On Mon, Jan 6, 2014 at 11:11 AM, Julien BERAUD >>>> <julien.ber...@parrot.com> >>>> wrote: >>>>> >>>>> Le 03/01/2014 12:30, Enrico a écrit : >>>>>> >>>>>> On Wed, Dec 18, 2013 at 11:09 AM, Enrico <ebut...@users.berlios.de> >>>>>> wrote: >>>>>>> >>>>>>> On Tue, Dec 17, 2013 at 2:11 PM, Florian Vaussard >>>>>>> <florian.vauss...@epfl.ch> 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]: >>>>>> a 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 >> >> It seems i can't set cropping at the CCDC input (sink), but i can on >> output (source): >> >> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) >> type V4L2 subdev subtype Unknown flags 0 >> device node name /dev/v4l-subdev2 >> pad0: Sink >> [fmt:UYVY2X8/720x625] >> <- "OMAP3 ISP CCP2":1 [] >> <- "OMAP3 ISP CSI2a":1 [] >> <- "tvp5150 1-005c":0 [ENABLED] >> pad1: Source >> [fmt:UYVY2X8/720x576 >> crop.bounds:(0,0)/720x624 >> crop:(0,48)/720x576] >> -> "OMAP3 ISP CCDC output":0 [ENABLED] >> -> "OMAP3 ISP resizer":0 [] >> pad2: Source >> [fmt:unknown/720x624] >> -> "OMAP3 ISP preview":0 [] >> -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] >> -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] >> -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] >> >> The strange thing is that with these settings the situation is even >> worse, i don't get any frames in yavta (while i see interrupts on >> omap3isp) even with the "cat /dev/zero" trick. >> >> So you are right, playing with cropping can make it work or not, are >> you sure you could set cropping at the ccdc input? >> >> Enrico > > Enrico, > > Sorry it didn't work. I just wanted to give a hint of what could be going > wrong. I am sorry I don't have time to investigate, I am sure I could set > the cropping at the input of ccdc, and that the result was to write register > ISPCCDC_VERT_START in order to skip the vertical blanking period correctly. > The branch I was on was a bit different though. If you want to investigate > this issue, you will at least need to see what is written in the registers > of the ISP. > > Regards, > Julien
I think i nailed down the problem, the fix is really simple but a better solution should be implemented: i noticed that when the system is idle i was getting no frames with yavta because FLDSTAT was always 0 and ccdc_isr_buffer was never called. In bt656 mode the VD0 interrupt is setup with (format->height/2 - 2), probably when the system is idle it doesn't "react" and process the interrupt soon enough so it will always get the FLDSTAT of the same field (top or bottom). Using (format->height/2 - 3) fix the problem (FLDSTAT toggles) BUT now you have tons of "CCDC won't become idle.." because the default ccdc_sbl_wait_idle(ccdc, 1000) is not enough to get the end of field. Increasing it to 2ms helps but since we are in interrupt context i suppose i'm delaying ALL the system so this is really ugly. I think the real solution should be to use VD0 and VD1 interrupts, one to get the current FLDSTAT and the other for ccdc_sbl_wait_idle..... What do you think? Enrico -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
