* [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 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: [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: [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: [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: [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.