Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock]
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 signature.asc Description: OpenPGP digital signature
Re: [omap3isp] xclk deadlock
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 signature.asc Description: OpenPGP digital signature
[omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock]
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 -- 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
Re: [omap3isp] xclk deadlock
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=0x omap3isp omap3isp: omap3isp omap3isp: -Preview Register dump-- -omap3isp omap3isp: ###PRV PCR=0x180e0609 -omap3isp omap3isp: ###PRV HORZ_INFO=0x0006035b -omap3isp omap3isp: ###PRV VERT_INFO=0x0286 +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=0x omap3isp omap3isp: ###PRV RADR_OFFSET=0x omap3isp omap3isp: ###PRV DSDR_ADDR=0x @@ -52,7 +52,7 @@ omap3isp omap3isp: ###PRV CNT_BRT=0x1000 omap3isp omap3isp: ###PRV CSUP=0x omap3isp omap3isp: ###PRV SETUP_YC=0xff00ff00 -omap3isp omap3isp:
Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock]
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 -- 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
Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock]
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 -- 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
Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock]
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 -- 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
Re: [omap3isp] xclk deadlock
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=0x [ 39.607299] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 39.613586] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 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 -- 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
Re: [omap3isp] xclk deadlock
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=0x [ 153.786773] omap3isp omap3isp: ###CCDC SYN_MODE=0x00030400 [ 153.792572] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 153.798431] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 153.804290] omap3isp omap3isp: ###CCDC HORZ_INFO=0x031f [ 153.810180] omap3isp omap3isp: ###CCDC VERT_START=0x [ 153.816101] omap3isp omap3isp: ###CCDC VERT_LINES=0x0257 [ 153.822052] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 153.827728] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x0640 [ 153.833648] omap3isp omap3isp: ###CCDC SDOFST=0x [ 153.839263] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 153.845001] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 153.850524] omap3isp omap3isp: ###CCDC DCSUB=0x [ 153.855987] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 153.861602] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 153.867156] omap3isp omap3isp: ###CCDC FPC=0x [ 153.872497] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 153.878265] omap3isp omap3isp: ###CCDC VDINT=0x02560190 [ 153.883789] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 153.889221] omap3isp omap3isp: ###CCDC REC656IF=0x [ 153.894958] omap3isp omap3isp: ###CCDC CFG=0x8000 [ 153.900299] omap3isp omap3isp: ###CCDC FMTCFG=0xc000 [ 153.905853] omap3isp omap3isp: ###CCDC FMT_HORZ=0x0320 [ 153.911651] omap3isp omap3isp: ###CCDC FMT_VERT=0x0258 [ 153.917388] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 153.923187] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 153.928955] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 153.934661] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 153.940338] omap3isp omap3isp: ###CCDC VP_OUT=0x04ae3200 [ 153.945922] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 153.951873] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 153.957916] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 153.964233] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 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]'
Re: [omap3isp] xclk deadlock
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=0x omap3isp omap3isp: omap3isp omap3isp: -Preview Register dump-- -omap3isp omap3isp: ###PRV PCR=0x180e0609 -omap3isp omap3isp: ###PRV HORZ_INFO=0x0006035b -omap3isp omap3isp: ###PRV VERT_INFO=0x0286 +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=0x omap3isp omap3isp: ###PRV RADR_OFFSET=0x omap3isp omap3isp: ###PRV DSDR_ADDR=0x @@ -52,7 +52,7 @@ omap3isp omap3isp: ###PRV CNT_BRT=0x1000 omap3isp omap3isp: ###PRV CSUP=0x omap3isp omap3isp: ###PRV SETUP_YC=0xff00ff00 -omap3isp omap3isp: ###PRV SET_TBL_ADDR=0x0800 +omap3isp omap3isp: ###PRV SET_TBL_ADDR=0x1700 omap3isp omap3isp: ###PRV CDC_THR0=0x000e omap3isp omap3isp: ###PRV CDC_THR1=0x000e omap3isp omap3isp: ###PRV CDC_THR2=0x000e -- 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
Re: [omap3isp] xclk deadlock
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=0x [ 153.786773] omap3isp omap3isp: ###CCDC SYN_MODE=0x00030400 [ 153.792572] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 153.798431] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 153.804290] omap3isp omap3isp: ###CCDC HORZ_INFO=0x031f [ 153.810180] omap3isp omap3isp: ###CCDC VERT_START=0x [ 153.816101] omap3isp omap3isp: ###CCDC VERT_LINES=0x0257 [ 153.822052] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 153.827728] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x0640 [ 153.833648] omap3isp omap3isp: ###CCDC SDOFST=0x [ 153.839263] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 153.845001] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 153.850524] omap3isp omap3isp: ###CCDC DCSUB=0x [ 153.855987] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 153.861602] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 153.867156] omap3isp omap3isp: ###CCDC FPC=0x [ 153.872497] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 153.878265] omap3isp omap3isp: ###CCDC VDINT=0x02560190 [ 153.883789] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 153.889221] omap3isp omap3isp: ###CCDC REC656IF=0x [ 153.894958] omap3isp omap3isp: ###CCDC CFG=0x8000 [ 153.900299] omap3isp omap3isp: ###CCDC FMTCFG=0xc000 [ 153.905853] omap3isp omap3isp: ###CCDC FMT_HORZ=0x0320 [ 153.911651] omap3isp omap3isp: ###CCDC FMT_VERT=0x0258 [ 153.917388] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 153.923187] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 153.928955] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 153.934661] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 153.940338] omap3isp omap3isp: ###CCDC VP_OUT=0x04ae3200 [ 153.945922] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 153.951873] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 153.957916] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 153.964233] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 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
Re: [omap3isp] xclk deadlock
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 -- 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
Re: [omap3isp] xclk deadlock
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 -- 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
Re: [omap3isp] xclk deadlock
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 -- 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
Re: [omap3isp] xclk deadlock
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 -- 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
[omap3isp] xclk deadlock
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 -- 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
