* [omap3isp] xclk deadlock @ 2013-07-03 1:00 Jakub Piotr Cłapa 2013-07-04 20:21 ` Jakub Piotr Cłapa 0 siblings, 1 reply; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-03 1:00 UTC (permalink / raw) To: linux-media; +Cc: Laurent Pinchart Hi everyone, Background: I was trying to get the mt9p031 sensor working on a BeagleBoard xM with a patched 3.9.8 kernel[1] or with the Laurent Pinchart's omap3isp/xclk branch[2]. I had this hardware working quite well under linux 3.2.8 and 3.2.24 with a patchset from Max Galemin but I had kernel crashes from time to time so I wanted to give a more recent kernel a try. Unfortunatelly I ran into some serious problems. I debugged them as far as I could but I cannot even begin to think of fixing this on my own so I would be really grateful if somebody could point me in the right direction. The problems: 1. I get a kernel deadlock when I run "media-ctl -p": mt9p031_power_on calls clk_prepare_enable to get it's clock running This, via isp_xclk_prepare -> omap3isp_get -> isp_enable_clocks results in another call to clk_prepare_enable which causes a deadlock because of the global prepare_lock in clk.c 2. Another thing is a lockdep warning during bootup: It warns about mixing the ordering of prepare_lock & isp->isp_mutex. The cause is that isp_probe acquires the isp_mutex first and then proceeds to enable clocks (acquiring prepare_lock in the process). Later on when the mt9p031 is intialized from v4l2_device_register_subdev it starts with getting it's clock and later locks isp_mutex via omap3isp_get (the deadlock does not happen in this case because the ISP clocks were already enabled). [1]: My patches agains vanilla 3.9.8 can be inspected here: https://github.com/LoEE/buildroot/tree/daf8276e3629f9aa8540fdd3510859c811dd2d24/board/beagleboard/xm/kernel-patches I have cherry-picked some omap3isp and mt9p031 patches from this mailing list (and reinvented at least one of them myself). Other patches (most of them) were taken from https://github.com/RobertCNelson/stable-kernel/tree/v3.9.x [2]: I made one change (to get cpu_is_omap3630 defined): diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c b/arch/arm/mach-omap2/board-omap3beagle-camera.c index bf84b48..cf5ad89e 100644 --- a/arch/arm/mach-omap2/board-omap3beagle-camera.c +++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c @@ -18,6 +18,7 @@ #include <media/omap3isp.h> #include "devices.h" +#include "soc.h" #define MT9P031_RESET_GPIO 98 -- regards, Jakub Piotr Cłapa LoEE.pl ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-03 1:00 [omap3isp] xclk deadlock Jakub Piotr Cłapa @ 2013-07-04 20:21 ` Jakub Piotr Cłapa 2013-07-04 21:11 ` Laurent Pinchart 0 siblings, 1 reply; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-04 20:21 UTC (permalink / raw) To: linux-media; +Cc: Laurent Pinchart Hi again, Sorry for the noise, but I believe the information below may be useful until everything is merged into mainline. I write to say that I managed to find a fix for the ISP clock deadlock. My branch can be found at: https://github.com/LoEE/linux/tree/omap3isp/xclk (SHA: 36286390193922d148e7a3db0676747a20f2ed66 at the time of writing) For reference: 1. This was a known problem since early January [1] (reported by Laurent). 2. Mike Turquette had submitted patches that made the clock framework (partially) reentrant. [2][3][4] 3. My code is just a rebase of the Laurent's omap3isp/xclk branch on the Mike's clk-next (so it's based on 3.10-rc3). [1]: https://lkml.org/lkml/2013/1/6/169 [2]: http://thread.gmane.org/gmane.linux.kernel/1448446/focus=1448448 [3]: http://thread.gmane.org/gmane.linux.ports.arm.kernel/182198 [4]: http://patches.linaro.org/15676/ -- regards, Jakub Piotr Cłapa LoEE.pl ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-04 20:21 ` Jakub Piotr Cłapa @ 2013-07-04 21:11 ` Laurent Pinchart 2013-07-04 22:36 ` Jakub Piotr Cłapa 0 siblings, 1 reply; 16+ messages in thread From: Laurent Pinchart @ 2013-07-04 21:11 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: linux-media Hi Jakub, On Thursday 04 July 2013 22:21:59 Jakub Piotr Cłapa wrote: > Hi again, > > Sorry for the noise, but I believe the information below may be useful > until everything is merged into mainline. > > I write to say that I managed to find a fix for the ISP clock deadlock. > My branch can be found at: > https://github.com/LoEE/linux/tree/omap3isp/xclk > (SHA: 36286390193922d148e7a3db0676747a20f2ed66 at the time of writing) > > For reference: > 1. This was a known problem since early January [1] (reported by Laurent). > 2. Mike Turquette had submitted patches that made the clock framework > (partially) reentrant. [2][3][4] > 3. My code is just a rebase of the Laurent's omap3isp/xclk branch on the > Mike's clk-next (so it's based on 3.10-rc3). The omap3isp/xclk clock branch was used only to push patches to the media tree, I should have deleted it afterwards. Mike's reentrancy patches were already merged (or scheduled for merge) in mainline at that time, and for technical reasons they were not present in the omap3isp/xclk branch. I've now deleted the branch from the public tree, sorry for the confusion. > [1]: https://lkml.org/lkml/2013/1/6/169 > [2]: http://thread.gmane.org/gmane.linux.kernel/1448446/focus=1448448 > [3]: http://thread.gmane.org/gmane.linux.ports.arm.kernel/182198 > [4]: http://patches.linaro.org/15676/ -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-04 21:11 ` Laurent Pinchart @ 2013-07-04 22:36 ` Jakub Piotr Cłapa 2013-07-05 10:48 ` Laurent Pinchart 0 siblings, 1 reply; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-04 22:36 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent, On 04.07.13 23:11, Laurent Pinchart wrote: > The omap3isp/xclk clock branch was used only to push patches to the media > tree, I should have deleted it afterwards. Mike's reentrancy patches were > already merged (or scheduled for merge) in mainline at that time, and for > technical reasons they were not present in the omap3isp/xclk branch. Thanks for the explanation. It would be great if you could update your board/beagle/mt9p031 branch and include the discussed changes. I belive your branch is the only authoritative source of magic required to get the Aptina+Beagle combination going. > I've now deleted the branch from the public tree, sorry for the confusion. Not a problem at all. The confusion was worse when I was trying to apply random patch files found via Google. ;) -- regards, Jakub Piotr Cłapa LoEE.pl ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-04 22:36 ` Jakub Piotr Cłapa @ 2013-07-05 10:48 ` Laurent Pinchart 2013-07-12 14:44 ` Jakub Piotr Cłapa 0 siblings, 1 reply; 16+ messages in thread From: Laurent Pinchart @ 2013-07-05 10:48 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: linux-media Hi Jakub, On Friday 05 July 2013 00:36:44 Jakub Piotr Cłapa wrote: > Hi Laurent, > > On 04.07.13 23:11, Laurent Pinchart wrote: > > The omap3isp/xclk clock branch was used only to push patches to the media > > tree, I should have deleted it afterwards. Mike's reentrancy patches were > > already merged (or scheduled for merge) in mainline at that time, and for > > technical reasons they were not present in the omap3isp/xclk branch. > > Thanks for the explanation. It would be great if you could update your > board/beagle/mt9p031 branch and include the discussed changes. Done. Could you please test it ? > I belive your branch is the only authoritative source of magic required to > get the Aptina+Beagle combination going. I need to add DT bindings to the OMAP3 ISP driver. Once done everything could be merged upstream. > > I've now deleted the branch from the public tree, sorry for the confusion. > > Not a problem at all. The confusion was worse when I was trying to apply > random patch files found via Google. ;) :-) -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-05 10:48 ` Laurent Pinchart @ 2013-07-12 14:44 ` Jakub Piotr Cłapa 2013-07-17 12:50 ` Laurent Pinchart 0 siblings, 1 reply; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-12 14:44 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent, On 05.07.13 12:48, Laurent Pinchart wrote: >> Thanks for the explanation. It would be great if you could update your >> board/beagle/mt9p031 branch and include the discussed changes. > > Done. Could you please test it ? Thanks for you help. There are no errors about the clocks or regulators now but the rest does not work so well (everything mentioned below works fine on my old 3.2.24 kernel): 1. The images streamed to omapdss using omap3-isp-live look like they lost "synchronization" with a black bar horizontal bar jumping on the screen and other such artifacts (it looks as if both width and height were invalid). The framerate is about a half of what it should be. Adjusting the camera iris changes the lightness of the image so the whole pipeline is working to some extent (so these artifacts are not just some random memory patterns). The Register dumps are a little different between 3.2.24 and 3.10 [4]. 2. When exiting from live the kernel hangs more often then not (sometimes it is accompanied by "Unhandled fault: external abort on non-linefetch" in "dispc_write_irqenable" in omapdss). 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"). [1]: [ 153.774017] omap3isp omap3isp: -------------CCDC Register dump------------- [ 153.781494] omap3isp omap3isp: ###CCDC PCR=0x00000000 [ 153.786773] omap3isp omap3isp: ###CCDC SYN_MODE=0x00030400 [ 153.792572] omap3isp omap3isp: ###CCDC HD_VD_WID=0x00000000 [ 153.798431] omap3isp omap3isp: ###CCDC PIX_LINES=0x00000000 [ 153.804290] omap3isp omap3isp: ###CCDC HORZ_INFO=0x0000031f [ 153.810180] omap3isp omap3isp: ###CCDC VERT_START=0x00000000 [ 153.816101] omap3isp omap3isp: ###CCDC VERT_LINES=0x00000257 [ 153.822052] omap3isp omap3isp: ###CCDC CULLING=0xffff00ff [ 153.827728] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x00000640 [ 153.833648] omap3isp omap3isp: ###CCDC SDOFST=0x00000000 [ 153.839263] omap3isp omap3isp: ###CCDC SDR_ADDR=0x00001000 [ 153.845001] omap3isp omap3isp: ###CCDC CLAMP=0x00000010 [ 153.850524] omap3isp omap3isp: ###CCDC DCSUB=0x00000000 [ 153.855987] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 153.861602] omap3isp omap3isp: ###CCDC BLKCMP=0x00000000 [ 153.867156] omap3isp omap3isp: ###CCDC FPC=0x00000000 [ 153.872497] omap3isp omap3isp: ###CCDC FPC_ADDR=0x00000000 [ 153.878265] omap3isp omap3isp: ###CCDC VDINT=0x02560190 [ 153.883789] omap3isp omap3isp: ###CCDC ALAW=0x00000004 [ 153.889221] omap3isp omap3isp: ###CCDC REC656IF=0x00000000 [ 153.894958] omap3isp omap3isp: ###CCDC CFG=0x00008000 [ 153.900299] omap3isp omap3isp: ###CCDC FMTCFG=0x0000c000 [ 153.905853] omap3isp omap3isp: ###CCDC FMT_HORZ=0x00000320 [ 153.911651] omap3isp omap3isp: ###CCDC FMT_VERT=0x00000258 [ 153.917388] omap3isp omap3isp: ###CCDC PRGEVEN0=0x00000000 [ 153.923187] omap3isp omap3isp: ###CCDC PRGEVEN1=0x00000000 [ 153.928955] omap3isp omap3isp: ###CCDC PRGODD0=0x00000000 [ 153.934661] omap3isp omap3isp: ###CCDC PRGODD1=0x00000000 [ 153.940338] omap3isp omap3isp: ###CCDC VP_OUT=0x04ae3200 [ 153.945922] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x00006600 [ 153.951873] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x00000000 [ 153.957916] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x00000000 [ 153.964233] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x00000000 [ 153.970733] omap3isp omap3isp: -------------------------------------------- [ 154.174468] omap3isp omap3isp: CCDC won't become idle! [ 154.315917] omap3isp omap3isp: CCDC won't become idle! [ 154.340118] omap3isp omap3isp: CCDC won't become idle! [ 154.364349] omap3isp omap3isp: CCDC won't become idle! [ 154.388549] omap3isp omap3isp: CCDC won't become idle! [ 154.412750] omap3isp omap3isp: CCDC won't become idle! [ 154.436950] omap3isp omap3isp: CCDC won't become idle! [ 154.461151] omap3isp omap3isp: CCDC won't become idle! [ 154.485382] omap3isp omap3isp: CCDC won't become idle! [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]' yavta -f SGRBG12 -s 800x600 -n 8 --skip 4 --capture=5 -F'frame-#.bin' $(media-ctl -e "OMAP3 ISP CCDC output") [3]: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information ------------------------ driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0xf0 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] <- "OMAP3 ISP CCP2 input":0 [] pad1: Source [SGRBG10 4096x4096] -> "OMAP3 ISP CCDC":0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source -> "OMAP3 ISP CCP2":0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] -> "OMAP3 ISP CSI2a output":0 [] -> "OMAP3 ISP CCDC":0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink <- "OMAP3 ISP CSI2a":1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [SGRBG12 864x648] <- "OMAP3 ISP CCP2":1 [] <- "OMAP3 ISP CSI2a":1 [] <- "mt9p031 2-0048":0 [ENABLED] pad1: Source [SGRBG12 864x648 (0,0)/864x648] -> "OMAP3 ISP CCDC output":0 [] -> "OMAP3 ISP resizer":0 [] pad2: Source [SGRBG10 864x647] -> "OMAP3 ISP preview":0 [ENABLED] -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink <- "OMAP3 ISP CCDC":1 [] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 864x647 (10,4)/846x639] <- "OMAP3 ISP CCDC":2 [ENABLED] <- "OMAP3 ISP preview input":0 [] pad1: Source [YUYV 846x639] -> "OMAP3 ISP preview output":0 [] -> "OMAP3 ISP resizer":0 [ENABLED] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source -> "OMAP3 ISP preview":0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Sink <- "OMAP3 ISP preview":1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Sink [YUYV 846x639 (0,0)/846x638] <- "OMAP3 ISP CCDC":1 [] <- "OMAP3 ISP preview":1 [ENABLED] <- "OMAP3 ISP resizer input":0 [] pad1: Source [YUYV 800x600] -> "OMAP3 ISP resizer output":0 [ENABLED] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Source -> "OMAP3 ISP resizer":0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Sink <- "OMAP3 ISP resizer":1 [ENABLED] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Sink <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Sink <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Sink <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] - entity 16: mt9p031 2-0048 (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8 pad0: Source [SGRBG12 864x648 (0,0)/2592x1944] -> "OMAP3 ISP CCDC":0 [ENABLED] [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 +omap3isp omap3isp: ###PRV HORZ_INFO=0x00080359 +omap3isp omap3isp: ###PRV VERT_INFO=0x00020284 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-12 14:44 ` Jakub Piotr Cłapa @ 2013-07-17 12:50 ` Laurent Pinchart 2013-07-17 22:17 ` Jakub Piotr Cłapa 2013-07-26 7:50 ` Tomi Valkeinen 0 siblings, 2 replies; 16+ messages in thread From: Laurent Pinchart @ 2013-07-17 12:50 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: linux-media, Tomi Valkeinen Hi Jakub, (CC'ing Tomi Valkeinen) On Friday 12 July 2013 16:44:44 Jakub Piotr Cłapa wrote: > Hi Laurent, > > On 05.07.13 12:48, Laurent Pinchart wrote: > >> Thanks for the explanation. It would be great if you could update your > >> board/beagle/mt9p031 branch and include the discussed changes. > > > > Done. Could you please test it ? > > Thanks for you help. There are no errors about the clocks or regulators > now but the rest does not work so well (everything mentioned below works > fine on my old 3.2.24 kernel): > > 1. The images streamed to omapdss using omap3-isp-live look like they > lost "synchronization" with a black bar horizontal bar jumping on the > screen and other such artifacts (it looks as if both width and height > were invalid). The framerate is about a half of what it should be. > Adjusting the camera iris changes the lightness of the image so the > whole pipeline is working to some extent (so these artifacts are not > just some random memory patterns). > > The Register dumps are a little different between 3.2.24 and 3.10 [4]. > > 2. When exiting from live the kernel hangs more often then not > (sometimes it is accompanied by "Unhandled fault: external abort on > non-linefetch" in "dispc_write_irqenable" in omapdss). I'll pass this one to Tomi :-) > 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. As a side note, you can use raw2rgbpnm (https://gitorious.org/raw2rgbpnm) to convert raw binary images to a more usable format. > [1]: > [ 153.774017] omap3isp omap3isp: -------------CCDC Register > dump------------- > [ 153.781494] omap3isp omap3isp: ###CCDC PCR=0x00000000 > [ 153.786773] omap3isp omap3isp: ###CCDC SYN_MODE=0x00030400 > [ 153.792572] omap3isp omap3isp: ###CCDC HD_VD_WID=0x00000000 > [ 153.798431] omap3isp omap3isp: ###CCDC PIX_LINES=0x00000000 > [ 153.804290] omap3isp omap3isp: ###CCDC HORZ_INFO=0x0000031f > [ 153.810180] omap3isp omap3isp: ###CCDC VERT_START=0x00000000 > [ 153.816101] omap3isp omap3isp: ###CCDC VERT_LINES=0x00000257 > [ 153.822052] omap3isp omap3isp: ###CCDC CULLING=0xffff00ff > [ 153.827728] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x00000640 > [ 153.833648] omap3isp omap3isp: ###CCDC SDOFST=0x00000000 > [ 153.839263] omap3isp omap3isp: ###CCDC SDR_ADDR=0x00001000 > [ 153.845001] omap3isp omap3isp: ###CCDC CLAMP=0x00000010 > [ 153.850524] omap3isp omap3isp: ###CCDC DCSUB=0x00000000 > [ 153.855987] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 > [ 153.861602] omap3isp omap3isp: ###CCDC BLKCMP=0x00000000 > [ 153.867156] omap3isp omap3isp: ###CCDC FPC=0x00000000 > [ 153.872497] omap3isp omap3isp: ###CCDC FPC_ADDR=0x00000000 > [ 153.878265] omap3isp omap3isp: ###CCDC VDINT=0x02560190 > [ 153.883789] omap3isp omap3isp: ###CCDC ALAW=0x00000004 > [ 153.889221] omap3isp omap3isp: ###CCDC REC656IF=0x00000000 > [ 153.894958] omap3isp omap3isp: ###CCDC CFG=0x00008000 > [ 153.900299] omap3isp omap3isp: ###CCDC FMTCFG=0x0000c000 > [ 153.905853] omap3isp omap3isp: ###CCDC FMT_HORZ=0x00000320 > [ 153.911651] omap3isp omap3isp: ###CCDC FMT_VERT=0x00000258 > [ 153.917388] omap3isp omap3isp: ###CCDC PRGEVEN0=0x00000000 > [ 153.923187] omap3isp omap3isp: ###CCDC PRGEVEN1=0x00000000 > [ 153.928955] omap3isp omap3isp: ###CCDC PRGODD0=0x00000000 > [ 153.934661] omap3isp omap3isp: ###CCDC PRGODD1=0x00000000 > [ 153.940338] omap3isp omap3isp: ###CCDC VP_OUT=0x04ae3200 > [ 153.945922] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x00006600 > [ 153.951873] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x00000000 > [ 153.957916] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x00000000 > [ 153.964233] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x00000000 > [ 153.970733] omap3isp omap3isp: > -------------------------------------------- > [ 154.174468] omap3isp omap3isp: CCDC won't become idle! > [ 154.315917] omap3isp omap3isp: CCDC won't become idle! > [ 154.340118] omap3isp omap3isp: CCDC won't become idle! > [ 154.364349] omap3isp omap3isp: CCDC won't become idle! > [ 154.388549] omap3isp omap3isp: CCDC won't become idle! > [ 154.412750] omap3isp omap3isp: CCDC won't become idle! > [ 154.436950] omap3isp omap3isp: CCDC won't become idle! > [ 154.461151] omap3isp omap3isp: CCDC won't become idle! > [ 154.485382] omap3isp omap3isp: CCDC won't become idle! > > > > > [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. > [3]: > Opening media device /dev/media0 > Enumerating entities > Found 16 entities > Enumerating pads and links > Media controller API version 0.0.0 > > Media device information > ------------------------ > driver omap3isp > model TI OMAP3 ISP > serial > bus info > hw revision 0xf0 > driver version 0.0.0 > > Device topology > - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev0 > pad0: Sink [SGRBG10 4096x4096] > <- "OMAP3 ISP CCP2 input":0 [] > pad1: Source [SGRBG10 4096x4096] > -> "OMAP3 ISP CCDC":0 [] > > - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) > type Node subtype V4L > device node name /dev/video0 > pad0: Source > -> "OMAP3 ISP CCP2":0 [] > > - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev1 > pad0: Sink [SGRBG10 4096x4096] > pad1: Source [SGRBG10 4096x4096] > -> "OMAP3 ISP CSI2a output":0 [] > -> "OMAP3 ISP CCDC":0 [] > > - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) > type Node subtype V4L > device node name /dev/video1 > pad0: Sink > <- "OMAP3 ISP CSI2a":1 [] > > - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev2 > pad0: Sink [SGRBG12 864x648] > <- "OMAP3 ISP CCP2":1 [] > <- "OMAP3 ISP CSI2a":1 [] > <- "mt9p031 2-0048":0 [ENABLED] > pad1: Source [SGRBG12 864x648 (0,0)/864x648] > -> "OMAP3 ISP CCDC output":0 [] > -> "OMAP3 ISP resizer":0 [] > pad2: Source [SGRBG10 864x647] > -> "OMAP3 ISP preview":0 [ENABLED] > -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] > -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] > -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] > > - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) > type Node subtype V4L > device node name /dev/video2 > pad0: Sink > <- "OMAP3 ISP CCDC":1 [] > > - entity 7: OMAP3 ISP preview (2 pads, 4 links) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev3 > pad0: Sink [SGRBG10 864x647 (10,4)/846x639] > <- "OMAP3 ISP CCDC":2 [ENABLED] > <- "OMAP3 ISP preview input":0 [] > pad1: Source [YUYV 846x639] > -> "OMAP3 ISP preview output":0 [] > -> "OMAP3 ISP resizer":0 [ENABLED] > > - entity 8: OMAP3 ISP preview input (1 pad, 1 link) > type Node subtype V4L > device node name /dev/video3 > pad0: Source > -> "OMAP3 ISP preview":0 [] > > - entity 9: OMAP3 ISP preview output (1 pad, 1 link) > type Node subtype V4L > device node name /dev/video4 > pad0: Sink > <- "OMAP3 ISP preview":1 [] > > - entity 10: OMAP3 ISP resizer (2 pads, 4 links) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev4 > pad0: Sink [YUYV 846x639 (0,0)/846x638] > <- "OMAP3 ISP CCDC":1 [] > <- "OMAP3 ISP preview":1 [ENABLED] > <- "OMAP3 ISP resizer input":0 [] > pad1: Source [YUYV 800x600] > -> "OMAP3 ISP resizer output":0 [ENABLED] > > - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) > type Node subtype V4L > device node name /dev/video5 > pad0: Source > -> "OMAP3 ISP resizer":0 [] > > - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) > type Node subtype V4L > device node name /dev/video6 > pad0: Sink > <- "OMAP3 ISP resizer":1 [ENABLED] > > - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev5 > pad0: Sink > <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] > > - entity 14: OMAP3 ISP AF (1 pad, 1 link) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev6 > pad0: Sink > <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] > > - entity 15: OMAP3 ISP histogram (1 pad, 1 link) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev7 > pad0: Sink > <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] > > - entity 16: mt9p031 2-0048 (1 pad, 1 link) > type V4L2 subdev subtype Unknown > device node name /dev/v4l-subdev8 > pad0: Source [SGRBG12 864x648 (0,0)/2592x1944] > -> "OMAP3 ISP CCDC":0 [ENABLED] > > > > > [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. > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-17 12:50 ` Laurent Pinchart @ 2013-07-17 22:17 ` Jakub Piotr Cłapa 2013-07-26 15:51 ` Laurent Pinchart 2013-07-26 7:50 ` Tomi Valkeinen 1 sibling, 1 reply; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-17 22:17 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-17 22:17 ` Jakub Piotr Cłapa @ 2013-07-26 15:51 ` Laurent Pinchart 2013-07-26 23:51 ` Jakub Piotr Cłapa 0 siblings, 1 reply; 16+ messages in thread From: Laurent Pinchart @ 2013-07-26 15:51 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-26 15:51 ` Laurent Pinchart @ 2013-07-26 23:51 ` Jakub Piotr Cłapa 0 siblings, 0 replies; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-26 23:51 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Dear Laurent, The offending commit is b2da46e52fe7871cba36e1a435844502c0eccf39 After reverting it I get good image on v3.5-rc1. Unfortunatelly trying to revert it on the board/beagle/mt9p031 branch causes conflicts and I am too tired to even try to fix them right now. The hanging unfortunatelly remains. It hangs most of the time with (ctrl-c was pressed at ≈133 seconds): [ 39.601318] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x00000000 [ 39.607299] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x00000000 [ 39.613586] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x00000000 [ 39.620056] omap3isp omap3isp: -------------------------------------------- [ 133.516906] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module. [ 133.524383] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled [ 133.531311] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module. [ 133.538543] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled [ 133.545288] omap3isp omap3isp: OMAP3 ISP histogram: user wants to disable module. [ 133.553131] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled One time I got a lucky and after 1 second elapsed I got: [ 35.250274] omap3isp omap3isp: Unable to stop OMAP3 ISP CCDC 477 images processed in 16.655242 seconds (28.639629 fps) The second line is console output from ./live. PS. In case anybody would wish to reproduce my results: For kernels 3.3 - 3.9 you have to apply: https://linuxtv.org/patch/10250/ to get omapdss to work. Until 15693b57931b19f3bb4664cb4fa3f6f966058749 (between 3.4 and 3.5-rc1) you can use for the board intergration patch: https://github.com/MaxGalemin/buildroot/blob/develop/board/beagleboard/xm/kernel-patches/linux-0003-Add-support-for-MT9P031-Aptina-image-sensor-driver.patch Later ones needs to replace the reset callback with a GPIO number and remove the COLOR/MONOCHROME parameter. The rest is wrestling with changing kernel config parameter names. (DVI->TFP410? ;) -- regards, Jakub Piotr Cłapa LoEE.pl ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omap3isp] xclk deadlock 2013-07-17 12:50 ` Laurent Pinchart 2013-07-17 22:17 ` Jakub Piotr Cłapa @ 2013-07-26 7:50 ` Tomi Valkeinen 2013-07-26 15:37 ` [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] Jakub Piotr Cłapa 1 sibling, 1 reply; 16+ messages in thread From: Tomi Valkeinen @ 2013-07-26 7:50 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: Laurent Pinchart, linux-media [-- Attachment #1: Type: text/plain, Size: 643 bytes --] On 17/07/13 15:50, Laurent Pinchart wrote: > Hi Jakub, > > (CC'ing Tomi Valkeinen) > > On Friday 12 July 2013 16:44:44 Jakub Piotr Cłapa wrote: >> 2. When exiting from live the kernel hangs more often then not >> (sometimes it is accompanied by "Unhandled fault: external abort on >> non-linefetch" in "dispc_write_irqenable" in omapdss). > > I'll pass this one to Tomi :-) Sounds like something is enabling/disabling dispc interrupts after the clocks have already been turned off. So what's the context here? What kernel? Using omapfb, or...? I hope not omap_vout, because that's rather unmaintained =). Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] 2013-07-26 7:50 ` Tomi Valkeinen @ 2013-07-26 15:37 ` Jakub Piotr Cłapa 2013-07-26 15:52 ` Laurent Pinchart 2013-07-29 6:19 ` Tomi Valkeinen 0 siblings, 2 replies; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-26 15:37 UTC (permalink / raw) To: Tomi Valkeinen; +Cc: Laurent Pinchart, linux-media Dear Tomi, Thanks for your reply. On 26.07.13 09:50, Tomi Valkeinen wrote: > Sounds like something is enabling/disabling dispc interrupts after the > clocks have already been turned off. > > So what's the context here? What kernel? This was on 3.10 from Laurent's board/beagle/mt9p031 branch. I am in the middle of doing some "bisecting" to figure out some unrelated problems with omap3isp so in a couple days I may have more data about which versions work and which do not. > Using omapfb, or...? I hope not > omap_vout, because that's rather unmaintained =). Laurent's live application is using the V4L2 API for video output (to get free YUV conversion and DMA) so I guess this unfortunatelly counts as using omap_vout. Are there any alternatives I should look into? IIUC to use omapfb I would need to manually copy RGB data into the framebuffer on each frame. -- regards, Jakub Piotr Cłapa LoEE.pl ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] 2013-07-26 15:37 ` [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] Jakub Piotr Cłapa @ 2013-07-26 15:52 ` Laurent Pinchart 2013-07-26 19:02 ` Jakub Piotr Cłapa 2013-07-29 6:19 ` Tomi Valkeinen 1 sibling, 1 reply; 16+ messages in thread From: Laurent Pinchart @ 2013-07-26 15:52 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: Tomi Valkeinen, linux-media Hi Jakub, On Friday 26 July 2013 17:37:36 Jakub Piotr Cłapa wrote: > Dear Tomi, > > Thanks for your reply. > > On 26.07.13 09:50, Tomi Valkeinen wrote: > > Sounds like something is enabling/disabling dispc interrupts after the > > clocks have already been turned off. > > > > So what's the context here? What kernel? > > This was on 3.10 from Laurent's board/beagle/mt9p031 branch. I am in the > middle of doing some "bisecting" to figure out some unrelated problems > with omap3isp so in a couple days I may have more data about which > versions work and which do not. > > > Using omapfb, or...? I hope not > > omap_vout, because that's rather unmaintained =). > > Laurent's live application is using the V4L2 API for video output (to > get free YUV conversion and DMA) so I guess this unfortunatelly counts > as using omap_vout. Are there any alternatives I should look into? IIUC > to use omapfb I would need to manually copy RGB data into the > framebuffer on each frame. It should be possible to port the live application to use DRM/KMS with omapdrm for the display side, without requiring any memory copy. That's somewhere on my TODO list, but I won't have time to work on that before way too long. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] 2013-07-26 15:52 ` Laurent Pinchart @ 2013-07-26 19:02 ` Jakub Piotr Cłapa 2013-07-26 19:13 ` Laurent Pinchart 0 siblings, 1 reply; 16+ messages in thread From: Jakub Piotr Cłapa @ 2013-07-26 19:02 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Tomi Valkeinen, linux-media On 26.07.13 17:52, Laurent Pinchart wrote: >>> Using omapfb, or...? I hope not >>> omap_vout, because that's rather unmaintained =). >> >> Laurent's live application is using the V4L2 API for video output (to >> get free YUV conversion and DMA) so I guess this unfortunatelly counts >> as using omap_vout. Are there any alternatives I should look into? IIUC >> to use omapfb I would need to manually copy RGB data into the >> framebuffer on each frame. > > It should be possible to port the live application to use DRM/KMS with omapdrm > for the display side, without requiring any memory copy. That's somewhere on > my TODO list, but I won't have time to work on that before way too long. I could look into it myself but is there any documentation on omapdrm? From what I found libdrm should probably be used but information about it's API is really scarce: https://dvdhrm.wordpress.com/2012/09/13/linux-drm-mode-setting-api/ http://dvdhrm.wordpress.com/2012/12/21/advanced-drm-mode-setting-api/ http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_ The last one seems focused on OpenGL so I don't think it applies. Are there any good sources to learn about this? Or maybe some pointers on where to start with reading source code? -- regards, Jakub Piotr Cłapa LoEE.pl ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] 2013-07-26 19:02 ` Jakub Piotr Cłapa @ 2013-07-26 19:13 ` Laurent Pinchart 0 siblings, 0 replies; 16+ messages in thread From: Laurent Pinchart @ 2013-07-26 19:13 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: Tomi Valkeinen, linux-media Hi Jakub, On Friday 26 July 2013 21:02:35 Jakub Piotr Cłapa wrote: > On 26.07.13 17:52, Laurent Pinchart wrote: > >>> Using omapfb, or...? I hope not > >>> omap_vout, because that's rather unmaintained =). > >> > >> Laurent's live application is using the V4L2 API for video output (to > >> get free YUV conversion and DMA) so I guess this unfortunatelly counts > >> as using omap_vout. Are there any alternatives I should look into? IIUC > >> to use omapfb I would need to manually copy RGB data into the > >> framebuffer on each frame. > > > > It should be possible to port the live application to use DRM/KMS with > > omapdrm for the display side, without requiring any memory copy. That's > > somewhere on my TODO list, but I won't have time to work on that before > > way too long. > I could look into it myself but is there any documentation on omapdrm? > > From what I found libdrm should probably be used but information about it's > API is really scarce: > https://dvdhrm.wordpress.com/2012/09/13/linux-drm-mode-setting-api/ > http://dvdhrm.wordpress.com/2012/12/21/advanced-drm-mode-setting-api/ > http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_ > programs_with_egl_and_ > > The last one seems focused on OpenGL so I don't think it applies. > > Are there any good sources to learn about this? Or maybe some pointers on > where to start with reading source code? http://events.linuxfoundation.org/sites/events/files/lcjpcojp13_pinchart.pdf A bit of shameless self-advertising :-) It would have been clearer with the video, but it seems the talk hasn't been recorded :-/ There's also http://www.youtube.com/watch?v=Ja8fM7rTae4 that mostly focuses on the kernel side but starts with explanations of the key KMS concepts. As far as KMS is concerned, libdrm is mostly a wrapper, so any documentation on the KMS ioctls can help too. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] 2013-07-26 15:37 ` [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] Jakub Piotr Cłapa 2013-07-26 15:52 ` Laurent Pinchart @ 2013-07-29 6:19 ` Tomi Valkeinen 1 sibling, 0 replies; 16+ messages in thread From: Tomi Valkeinen @ 2013-07-29 6:19 UTC (permalink / raw) To: Jakub Piotr Cłapa; +Cc: Laurent Pinchart, linux-media [-- Attachment #1: Type: text/plain, Size: 483 bytes --] On 26/07/13 18:37, Jakub Piotr Cłapa wrote: >> Using omapfb, or...? I hope not >> omap_vout, because that's rather unmaintained =). > > Laurent's live application is using the V4L2 API for video output (to > get free YUV conversion and DMA) so I guess this unfortunatelly counts > as using omap_vout. Are there any alternatives I should look into? IIUC Ok. Do you have a call trace for the dispc_write_irqenable crash? Maybe it's something simple to fix. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-07-29 6:19 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-03 1:00 [omap3isp] xclk deadlock Jakub Piotr Cłapa 2013-07-04 20:21 ` Jakub Piotr Cłapa 2013-07-04 21:11 ` Laurent Pinchart 2013-07-04 22:36 ` Jakub Piotr Cłapa 2013-07-05 10:48 ` Laurent Pinchart 2013-07-12 14:44 ` Jakub Piotr Cłapa 2013-07-17 12:50 ` Laurent Pinchart 2013-07-17 22:17 ` Jakub Piotr Cłapa 2013-07-26 15:51 ` Laurent Pinchart 2013-07-26 23:51 ` Jakub Piotr Cłapa 2013-07-26 7:50 ` Tomi Valkeinen 2013-07-26 15:37 ` [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock] Jakub Piotr Cłapa 2013-07-26 15:52 ` Laurent Pinchart 2013-07-26 19:02 ` Jakub Piotr Cłapa 2013-07-26 19:13 ` Laurent Pinchart 2013-07-29 6:19 ` Tomi Valkeinen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox