This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM355+MT9P031,app blocked when calling VIDIOC_DQBUF

    i have modified the mt9t001.c ccdc_dm355.c dm355_vpfe.c files and other related files to support MT9P031

but when calling VIDIOC_DQBUF the App block at schedule() ,however VIDIOC_QBUF is OK and the device is

opend as O_NONBLOCK.

 if(!init_flag){
  CLEAR(buf);
  buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
  buf.memory = V4L2_MEMORY_MMAP;
  init_flag = 1;
 }else {
  /* requeue the buffer */
  if (-1 == ioctl(fdCapture, VIDIOC_QBUF, &buf)) {
   perror("StartCameraCaputre:ioctl:VIDIOC_QBUF");
  }
 }
 /*determine ready buffer */
 if (-1 == ioctl(fdCapture, VIDIOC_DQBUF, &buf)) {                   //  blocked here
  if (EAGAIN == errno)
   return ;
  perror("StartCameraCaputre:ioctl:VIDIOC_DQBUF");
  exit_s();
 }

 

if ((fdCapture =
      open(CAPTURE_DEVICE, O_RDWR | O_NONBLOCK, 0)) <= -1) {   // Open NONBLOCK method

  perror("InitDevice:open::");
  exit_s();
 } else
  printf("\nOpen Done\n");

 

somebody tell me please !!!   Why it blocked .  code resources are all form leopard 

the app source:  https://www.leopardimaging.com/uploads/DM355_ipipe_example_DVSDK_1.30_v1.32.tgz

the kernel source:https://www.leopardimaging.com/uploads/patches.tgz

 

  • I think the non-blocked mode was not supported in old versions of the driver. Could you check if dm355_vpfe.c has the following code in DQBUF handler?

    I have quoted the code from a recent version of the driver found at

     

    http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=blob;f=drivers/media/video/davinci/vpfe_capture.c;h=033cedaef41fc3e791a96f6e883f2442063f3c9d;hb=9284892b4819955947e1aaf08d52f240b04cc705

     

    static int vpfe_dqbuf(struct file *file, void *priv,

    2015                       struct v4l2_buffer *buf)

    2016 {

    2017         struct vpfe_device *vpfe_dev = video_drvdata(file);

    2018

    2019         v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_dqbuf\n");

    2020

    2021         if (V4L2_BUF_TYPE_VIDEO_CAPTURE != buf->type) {

    2022                 v4l2_err(&vpfe_dev->v4l2_dev, "Invalid buf type\n");

    2023                 return -EINVAL;

    2024         }

    2025         return videobuf_dqbuf(&vpfe_dev->buffer_queue,

    2026                                       buf, file->f_flags & O_NONBLOCK);

    2027 }

     

  • thank you for your help

    i have checked dm355_vpfe.c  there is no vpfe_dqbuf() in it  but it has another routine which has the same function

    the code you quoted  is for dm365 ,maybe there is some deference  .

    Maybe i didn't  make my  point  clear

    i am wondering why it blocked when calling dqbuf

    according to v4l2 manual the dqbuf blocked when all queued buffers are waitting for filling , no one is filled or displayed so the buffer status didn't change

    that's to say the ccdc regesters did not config correctly or there is something wrong with my MT9P031 device . connection configuration etc...

    so my question is which routine fills the capture buffers ,vint0_isr or vint1_isr or else

     

     

  • tthr tthr,

    Buffer is filled by H/W, and not by isr() routines. Once buffer is filled by H/W, it triggers the interrupt which will result in isr() call in the driver. In isr() call, state of the buffer is updated. In your case, I believe its either of 2 situations,

    1. Capture is not happening from the H/W end(no input?), hence no interrupt,  hence no isr() call, so, no buffer state update is happening.

    2. Application should have at least 2 buffers for the streaming to happen, if its only one buffer driver might not DQ the buffer. Pl check how many buffers for queued.


    Hope this helps.
    Regards,

    Nag

  • Nagabhushana ,i realy appreciate your help.the first case you proposed is the one i concerned most .

    since the app can run well in another version dm355 evm board .

    . i'm planning to check the entire device all over again .hope i can find the bug

  • Hello, I am trying to change the ipipe source code to support the MT9P031 sensor, can you briefly explain me what files need to be changed and the required documentation?

    I am at the moment reviewing all the sources and trying to identifying parameters that need to be changed for this particular sensor.

     

    I would really appreciate some info.

     

    many thanks

  • leave your email address i‘ll send those files to you

    or you can download the patch files from leopard,which i’ve list in the first post

  • msanchez at eeng.nuim.ie

    Many thanks for your help! I will post my findings once I have it working!

     

  • hello, i have came the same questions.

    when i use vidioc_dqbuf, the capture would block.

    and when i open with nonblock, error ouput "VIDIOC_DQBUF : Try again   omap3isp omap3isp: CCDC stop timeout ! "

    Best Regards !