OMAP3 ISP DQBUF hangs using yavta and media-ctl tool
Hello,
I try to get an image with my ov3640 camera sensor and I configured the
pipeline as follows:
root@overo2:~/media_test/bin# sudo ./media-ctl -v -r -l 'ov3640
3-003c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC
output:0[1]'
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Resetting all links to inactive
Setting up link 16:0 - 5:0 [1]
Setting up link 5:1 - 6:0 [1]
root@overo2:~/media_test/bin# sudo ./media-ctl -v -V 'ov3640 3-003c:0
[SBGGR10 640x480 (32,20)/640x480], OMAP3 ISP CCDC:1 [SBGGR10 640x480]'
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Setting up selection target 0 rectangle (32,20)/640x480 on pad ov3640 3-003c/0
Selection rectangle set: (32,20)/640x480
Setting up format SBGGR10 640x480 on pad ov3640 3-003c/0
Format set: SBGGR10 640x480
Setting up format SBGGR10 640x480 on pad OMAP3 ISP CCDC/0
Format set: SBGGR10 640x480
Setting up format SBGGR10 640x480 on pad OMAP3 ISP CCDC/1
Format set: SBGGR10 640x480
Then I wanted to take an image with yavta, but it hangs on DQBUF:
root@overo2:~/media_test/bin# cd
root@overo2:~# cd yavta-HEAD-d9b7cfc/
root@overo2:~/yavta-HEAD-d9b7cfc# sudo strace ./yavta -n 1 -f SBGGR10 -s
640x480 --capture=1 --file=/home/root/image /dev/video2
execve(./yavta, [./yavta, -n, 1, -f, SBGGR10, -s, 640x480,
--capture=1, --file=/home/root/image, /dev/video2], [/* 13 vars */]) = 0
brk(0) = 0x413000
uname({sys=Linux, node=overo2, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6f27000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/var/run/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=63134, ...}) = 0
mmap2(NULL, 63134, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6ef4000
close(3)= 0
open(/lib/librt.so.1, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\240\26\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=26572, ...}) = 0
mmap2(NULL, 57876, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb6ee5000
mprotect(0xb6eeb000, 28672, PROT_NONE) = 0
mmap2(0xb6ef2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb6ef2000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\fR\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1168720, ...}) = 0
mmap2(NULL, 1204784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb6dbe000
mprotect(0xb6ed7000, 32768, PROT_NONE) = 0
mmap2(0xb6edf000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x119) = 0xb6edf000
mmap2(0xb6ee2000, 8752, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6ee2000
close(3)= 0
open(/lib/libpthread.so.0, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\300B\0\0004\0\0\0..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=84340, ...}) = 0
mmap2(NULL, 123396, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb6d9f000
mprotect(0xb6db3000, 28672, PROT_NONE) = 0
mmap2(0xb6dba000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xb6dba000
mmap2(0xb6dbc000, 4612, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6dbc000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6f26000
set_tls(0xb6f26820, 0xb6f26820, 0x684, 0xb6f26ef8, 0xb6f29050) = 0
mprotect(0xb6dba000, 4096, PROT_READ) = 0
mprotect(0xb6edf000, 8192, PROT_READ) = 0
mprotect(0xb6ef2000, 4096, PROT_READ) = 0
mprotect(0xb6f28000, 4096, PROT_READ) = 0
munmap(0xb6ef4000, 63134) = 0
set_tid_address(0xb6f263c8) = 1381
set_robust_list(0xb6f263d0, 0xc)= 0
futex(0xbee03cd4, FUTEX_WAKE_PRIVATE, 1) = 0
rt_sigaction(SIGRTMIN, {0xb6da31c8, [], SA_SIGINFO|0x400}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb6da2d44, [], SA_RESTART|SA_SIGINFO|0x400},
NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
open(/dev/video2, O_RDWR) = 3
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6f25000
write(1, Device /dev/video2 opened.\n, 27Device /dev/video2 opened.
) = 27
ioctl(3, VIDIOC_QUERYCAP or VT_OPENQRY, 0xbee039c0) = 0
write(1, Device `OMAP3 ISP CCDC output' o..., 69Device `OMAP3 ISP CCDC
output' on `media' is a video capture device.
) = 69
ioctl(3, VIDIOC_S_FMT or VT_RELDISP, 0xbee03868) = 0
write(1, Video format set: SBGGR10 (30314..., 78Video format set: SBGGR10
(30314742) 640x480 (stride 1280) buffer size 614400
) = 78
ioctl(3, VIDIOC_G_FMT or
Re: OMAP3 ISP DQBUF hangs
Su Jiaquan jiaquan.lnx at gmail.com writes: Hello, Hi Tom Well, for our practice, we QBUF before STREAMON (not on omap3 isp). You can try that and see what happens. As I check the omap3 code, you sequence maybe OK. Coz there is a restart mechanism in the code to restart CCDC hardware after buffer underrun. But for you sequence, if the interrupt comes before you QBUF, then the hardware is running in underrun state ever from the STREAMON. Not sure the restart mechanism works in this scenario. Let's wait for answers from the professional Jiaquan Thanks for your reply. The hang is solved. You were right. Now I do QBUF - STREAMON - DQBUF - STREAMOFF. My new Problem is that I receive a black image, but I think I do a new post with the appropriate subject. Best Regrads, Tom -- 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: OMAP3 ISP DQBUF hangs
Su Jiaquan jiaquan.lnx at gmail.com writes:
Hello,
Hi Tom,
On Thu, Aug 15, 2013 at 10:15 PM, Tom Bassai_Dai at gmx.net wrote:
Hello,
I'm working with an OMAP3 DM3730 processor module with a ov3640 camera
module attached on parallel interface. I'm using Linux 3.5 and an
application which builds the pipeline and grabs an image like the
media-ctl and the yavta tools.
I configured the pipeline to:
sensor-ccdc-memory
When I call ioctl with DQBUF the calling functions are:
isp_video_dqbuf - omap3isp_video_queue_dqbuf - isp_video_buffer_wait -
wait_event_interruptible
The last function waits until the state of the buffer will be reseted
somehow. Can someone tell my which function sets the state of the buffer? Am
I missing an interrupt?
Best Regards, Tom
I'm not familar with omap3isp, but from the code, the wait queue is
released by function ccdc_isr_buffer-omap3isp_video_buffer_next.
You are either missing a interrupt, or running out of buffer, or found
a buffer under run.
Jiaquan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
you are right. it seems that the list of the ccdc has no buffer left,
because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in
my log. But I don't understand what I need to do to solve the problem.
What I do is:
- configure the pipeline
- open the video device
- do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type =
V4L2_BUF_TYPE_VIDEO_CAPTURE)
- do ioctl VIDIOC_QUERYBUF
- do ioctl VIDIOC_STREAMON
- do ioctl VIDIOC_QBUF
without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem.
Does anyone have an idea what I need to do to solve this problem?
static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
{
printk(TOM ccdc_isr_buffer ##\n);
struct isp_pipeline *pipe = to_isp_pipeline(ccdc-subdev.entity);
struct isp_device *isp = to_isp_device(ccdc);
struct isp_buffer *buffer;
int restart = 0;
/* The CCDC generates VD0 interrupts even when disabled (the datasheet
* doesn't explicitly state if that's supposed to happen or not, so it
* can be considered as a hardware bug or as a feature, but we have to
* deal with it anyway). Disabling the CCDC when no buffer is available
* would thus not be enough, we need to handle the situation explicitly.
*/
printk(TOM ccdc_isr_buffer 1 ##\n);
if (list_empty(ccdc-video_out.dmaqueue))
{
printk(TOM ccdc_isr_buffer ERROR 1 ##\n);
goto done;
}
/* We're in continuous mode, and memory writes were disabled due to a
* buffer underrun. Reenable them now that we have a buffer. The buffer
* address has been set in ccdc_video_queue.
*/
printk(TOM ccdc_isr_buffer 2 ##\n);
if (ccdc-state == ISP_PIPELINE_STREAM_CONTINUOUS ccdc-underrun) {
restart = 1;
ccdc-underrun = 0;
printk(TOM ccdc_isr_buffer ERROR 2 ##\n);
goto done;
}
printk(TOM ccdc_isr_buffer 3 ##\n);
if (ccdc_sbl_wait_idle(ccdc, 1000)) {
printk(TOM ccdc_isr_buffer ERROR 3 ##\n);
dev_info(isp-dev, CCDC won't become idle!\n);
goto done;
}
printk(TOM ccdc_isr_buffer 4 ##\n);
buffer = omap3isp_video_buffer_next(ccdc-video_out);
if (buffer != NULL) {
ccdc_set_outaddr(ccdc, buffer-isp_addr);
restart = 1;
}
printk(TOM ccdc_isr_buffer 5 ##\n);
pipe-state |= ISP_PIPELINE_IDLE_OUTPUT;
if (ccdc-state == ISP_PIPELINE_STREAM_SINGLESHOT
isp_pipeline_ready(pipe))
omap3isp_pipeline_set_stream(pipe,
ISP_PIPELINE_STREAM_SINGLESHOT);
printk(TOM ccdc_isr_buffer DONE ##\n);
done:
return restart;
}
Regards, Tom
--
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: OMAP3 ISP DQBUF hangs
On Mon, Aug 19, 2013 at 4:53 PM, Tom bassai_...@gmx.net wrote: you are right. it seems that the list of the ccdc has no buffer left, because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in my log. But I don't understand what I need to do to solve the problem. What I do is: - configure the pipeline - open the video device - do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type = V4L2_BUF_TYPE_VIDEO_CAPTURE) - do ioctl VIDIOC_QUERYBUF - do ioctl VIDIOC_STREAMON - do ioctl VIDIOC_QBUF without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem. Does anyone have an idea what I need to do to solve this problem? Even if you are sure your application works, try with media-ctl + yavta first so you can send logs that everybody understand. Did you check you have interrupts during capture? (cat /proc/interrupts before and after yavta, look for omap3isp or something like that). Enrico -- 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: OMAP3 ISP DQBUF hangs
Hi Tom you are right. it seems that the list of the ccdc has no buffer left, because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in my log. But I don't understand what I need to do to solve the problem. What I do is: - configure the pipeline - open the video device - do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type = V4L2_BUF_TYPE_VIDEO_CAPTURE) - do ioctl VIDIOC_QUERYBUF - do ioctl VIDIOC_STREAMON - do ioctl VIDIOC_QBUF without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem. Does anyone have an idea what I need to do to solve this problem? Well, for our practice, we QBUF before STREAMON (not on omap3 isp). You can try that and see what happens. As I check the omap3 code, you sequence maybe OK. Coz there is a restart mechanism in the code to restart CCDC hardware after buffer underrun. But for you sequence, if the interrupt comes before you QBUF, then the hardware is running in underrun state ever from the STREAMON. Not sure the restart mechanism works in this scenario. Let's wait for answers from the professional :-) Jiaquan -- 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: OMAP3 ISP DQBUF hangs
Hi Tom, On Thu, Aug 15, 2013 at 10:15 PM, Tom bassai_...@gmx.net wrote: Hello, I'm working with an OMAP3 DM3730 processor module with a ov3640 camera module attached on parallel interface. I'm using Linux 3.5 and an application which builds the pipeline and grabs an image like the media-ctl and the yavta tools. I configured the pipeline to: sensor-ccdc-memory When I call ioctl with DQBUF the calling functions are: isp_video_dqbuf - omap3isp_video_queue_dqbuf - isp_video_buffer_wait - wait_event_interruptible The last function waits until the state of the buffer will be reseted somehow. Can someone tell my which function sets the state of the buffer? Am I missing an interrupt? Best Regards, Tom I'm not familar with omap3isp, but from the code, the wait queue is released by function ccdc_isr_buffer-omap3isp_video_buffer_next. You are either missing a interrupt, or running out of buffer, or found a buffer under run. Jiaquan -- 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 -- 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
OMAP3 ISP DQBUF hangs
Hello, I'm working with an OMAP3 DM3730 processor module with a ov3640 camera module attached on parallel interface. I'm using Linux 3.5 and an application which builds the pipeline and grabs an image like the media-ctl and the yavta tools. I configured the pipeline to: sensor-ccdc-memory When I call ioctl with DQBUF the calling functions are: isp_video_dqbuf - omap3isp_video_queue_dqbuf - isp_video_buffer_wait - wait_event_interruptible The last function waits until the state of the buffer will be reseted somehow. Can someone tell my which function sets the state of the buffer? Am I missing an interrupt? Best Regards, Tom -- 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
