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?
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.
[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 takesrows 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 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,
Jakub Piotr Cłapa
LoEE.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
