Re: [omap3isp] xclk deadlock

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Jakub,

On Thursday 18 July 2013 00:17:19 Jakub Piotr Cłapa wrote:
> On 17.07.13 14:50, Laurent Pinchart wrote:
> > Hi Jakub,
> > 
> >> 3. After setting up a simple pipeline using media-ctl[2] I get "CCDC
> >> won't become idle errors". If I do this after running "live" I also get
> >> (unless it hangs) the CCDC Register dump [1]. Otherwise I only get the
> >> stream of kernel log messages without anything else from omap3isp.
> >> 
> >> 4. I recreated the "live" pipeline (judging by the lack of differences
> >> in media-ctl -p output [3]) and used yavta. I get the same hangs but
> >> when I don't I can check the UYVY frames one by one. They look bad at
> >> any stride (I dropped the UV components and tried to get some meaningful
> >> output in the GIMP raw image data import dialog by adjustung the
> >> "width").
> > 
> > Would you be able to bisect the problems ? Please also see below for more
> > comments.
> 
> I think the clock & voltage regulator framework changes in omap3beagle.c
> would require reverting for earlier versions? Are there any other things I
> should watch out for?

Not that I can think of, no.

> > As a side note, you can use raw2rgbpnm (https://gitorious.org/raw2rgbpnm)
> > to convert raw binary images to a more usable format.
> 
> Thanks. The nice thing about the GIMP import tool is interactiveness, which
> is good when (I suspect) I don't know the proper image dimensions.
> 
> >> [2]:
> >> media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> >> CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> >> media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 800x600 (96,72)/2400x1800],
> >> "OMAP3 ISP CCDC":1 [SGRBG8 800x600]'
> > 
> > You're trying to configure the sensor output to 800x600, but the closest
> > resolution the sensor can deliver is 864x648. The sensor driver will thus
> > return that resolution, and media-ctl will automatically configure the
> > connected pad (CCDC sink pad 0) with the same resolution. Similarly, you
> > try to configure the CCDC output to 800x600, but the CCDC driver will
> > automatically set its output resolution (on source pad 1) to 864x648.
> > media- ctl won't complain, and your pipeline will be correctly
> > configured, but not in the resolution you expect.
> > 
> >> yavta -f SGRBG12 -s 800x600 -n 8 --skip 4 --capture=5 -F'frame-#.bin'
> >> $(media-ctl -e "OMAP3 ISP CCDC output")
> > 
> > Can you run this without error ? You're trying to capture in 800x600 at
> > the CCDC output but the pipeline has been configured with a different
> > resolution. The OMAP3 ISP driver should return an error when you start
> > the video stream. If it doesn't, that's a driver bug.
> 
> I think you missed my ingenious sensor crop. ;) The sensor should be
> capable of scaling to 800x600 if it crops to (96,72)/2400x1800 first
> (this just requires 3x binning). I tried this on 3.2.24 and it worked.

You're right, my bad.

> >> [4]:
> >> 
> >> @@ -21,9 +21,9 @@
> >> 
> >>    omap3isp omap3isp: ###RSZ YENH=0x00000000
> >>    omap3isp omap3isp: --------------------------------------------
> >>    omap3isp omap3isp: -------------Preview Register dump----------
> >> 
> >> -omap3isp omap3isp: ###PRV PCR=0x180e0609
> >> -omap3isp omap3isp: ###PRV HORZ_INFO=0x0006035b
> >> -omap3isp omap3isp: ###PRV VERT_INFO=0x00000286
> >> +omap3isp omap3isp: ###PRV PCR=0x180e0600
> > 
> > Bits 0 and 3 are the ENABLE and ONESHOT bits respectively. The registers
> > dump might have been displayed at a different time in v3.2.24 (although I
> > haven't checked);
> > 
> >> +omap3isp omap3isp: ###PRV HORZ_INFO=0x00080359
> >> +omap3isp omap3isp: ###PRV VERT_INFO=0x00020284
> > 
> > Those two registers contain the input crop rectangle coordinates (left/top
> > in bits 31-16, right/bottom in bits 15-0). Note that this is the internal
> > crop rectangle, which takes rows and columns required for internal
> > processing into account. It will thus not match the user-visible crop
> > rectangle at the sink pad.
> > 
> > The crop rectangle has changed from (6,0)/860x647 to (8,2)/850x643. The
> > preview engine internally crops 4 rows and 4 columns (2 on each side) when
> > converting from Bayer to YUV, so the (8,2)/850x643 crop rectangle becomes
> > (10,4)/846x639 after manual and internal cropping, which matches the value
> > reported by media-ctl -p.
> 
> But why does those cropping differences (between 3.2.24 and 3.10) happen at
> all? I run the same live code on 3.2.24 and 3.10, with the same sensor and
> output resolution. I think I got the same `media-ctl -p` output after
> running `live` on both kernels but will check this tomorrow.

If media-ctl -p reports the exact same pipeline configuration on both kernel 
versions then there's an issue.

> If these internal cropping rectangles on 3.10 were wrong it would probably
> explain the "bad synchronization" problem.
>
> >>    omap3isp omap3isp: ###PRV RSDR_ADDR=0x00000000
> >>    omap3isp omap3isp: ###PRV RADR_OFFSET=0x00000000
> >>    omap3isp omap3isp: ###PRV DSDR_ADDR=0x00000000
> >> 
> >> @@ -52,7 +52,7 @@
> >> 
> >>    omap3isp omap3isp: ###PRV CNT_BRT=0x00001000
> >>    omap3isp omap3isp: ###PRV CSUP=0x00000000
> >>    omap3isp omap3isp: ###PRV SETUP_YC=0xff00ff00
> >> 
> >> -omap3isp omap3isp: ###PRV SET_TBL_ADDR=0x00000800
> >> +omap3isp omap3isp: ###PRV SET_TBL_ADDR=0x00001700
> >> 
> >>    omap3isp omap3isp: ###PRV CDC_THR0=0x0000000e
> >>    omap3isp omap3isp: ###PRV CDC_THR1=0x0000000e
> >>    omap3isp omap3isp: ###PRV CDC_THR2=0x0000000e

-- 
Regards,

Laurent Pinchart