• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 3819 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

VIDIOC_DQBUF call hangs infinitely

Jerry Zuo
Prodigy 170 points

Hello all:

   I am currently working on DM368 for 1280x720 video encoding with linux-2.6.32.17. The image pattern continuously comes from a FPGA board without a physical image sensor. I have modified mt9p031 by bypassing all the i2c-related operations between sensors. So far the modified driver works successfully on all the ioctl calls except for the DQBUF. The program blocks at this call. If non-blocking is used, the program behaves of infinitely returning EAGAIN.

    I've checked previous related discussion and got to know that this hang results from the reason that the driver waits for an empty and available dequeued buffer.  In my application, the operations of REQBUF, QBUF and STREAMON have been sequentially called before calling the first DQBUF. In addition, By calling QUERYBUF, I've got that  the flags field of v4l2_buffer has been set to 0x03 before calling DQBUF. The program hangs and the flags field is never set to 0x04 (V4L2_BUF_FLAG_DONE).

    One strange outcome I have detected is that the bytesused field of v4l2_buffer is set to a number that is equal to that in the length field, after the QBUF is called. Does it mean that the driver considers that the buffers are not empty when start processing DQBUF? However, the buffer contains all zeros although the bytesused field is set by the driver. Since the image pattern is continuously coming from the FPGA board, is it possible that the bytesused field is always set upon the QBUF is called? Is that reason that the DQBUF is then blocked?

     Another thing I have detected is that the VDINT0 isr is never generated even though the VDINT0 is manually set to a super small number, say one (originally set to 719 by the driver, it should work in my application). That means no data is received from the FPGA.

    Please let me know possible reasons. Many thanks.

Jerry

  • 0
    Guru 31670 points

    Jerry,

    You've to get into the CCDC driver to debug this issue. Since VDINT0 is not occurring, this is the first thing that you've to debug. You've to see whether the ISIF module is configured properly, and if configured properly, it should be able to capture and write to the memory. If the configuration is proper and you've are not seeing VDINT0, you can check whether any resizer interrupts are occurring or not. If so, resizer is enabled and the data goes through resizer and gets written to memory.

  • 0 in reply to Renjith Thomas
    Prodigy 170 points

    Thank you so much Renjith. Below is the part of the booting information.

    MT9p031-dbg: mt9p031_mod_init                                                   
    vpfe_init                                                                       
    vpfe-capture: vpss clock vpss_master enabled                                    
    IRQ VINT0 is registered                                                        
    IRQ VINT1 is registered                                                         
    vpfe-capture vpfe-capture: v4l2 device registered                               
    vpfe-capture vpfe-capture: video device registered                              
    Leopard: switch to HD imager-MT9P031 video input                                
    MT9p031-dbg: mt9p031_probe                                                      
    MT9p031-dbg: mt9p031_detect                                                     
    mt9p031 1-0048: Detected a MT9P031 chip ID 1801                                 
    i2c_davinci i2c_davinci.1: timeout waiting for bus ready                        
    i2c_davinci i2c_davinci.1: timeout waiting for bus ready                        
    mt9p031 1-0048: mt9p031 1-0048 decoder driver registered !!                     
    MT9p031-dbg: mt9p031_probe success                                              
    vpfe-capture vpfe-capture: v4l2 sub device mt9p031 registered                   
    vpfe_register_ccdc_device: DM365 ISIF                                           
    DM365 ISIF is registered with vpfe.       

    It seems the ccdc driver is registered fine and I am able to configure the value of VDINT0.

    I am trying to trace into the kernel of videobuf_qbuf and videobuf_dqbuf functions in videobuf-core.c. I found that the videobuf_dqbuf is ultimately blocked at wait_event_interruptible. It waits for the condition (vb->state != VIDEOBUF_ACTIVE && vb->state != VIDEOBUF_QUEUED) becomes true. Before calling wait_event_interruptible, I printed out vb->state=VIDEOBUF_ACTIVE and then the condition never satisfied.  The buffer state is marked as ACTIVE upon calling STREAMON ioctl, but it is not unmarked when calling DQBUF, which results in the deadloop.

    The driver has detected that there are buffers to dequeue, but it is aware that the dequeued buffer is in ACTIVE mode when calling list_entry. What does that mean by ACTIVE mode?

    Many thanks.

    Jerry

  • 0 in reply to Jerry Zuo
    Guru 31670 points

    Can you put a print inside the interrupt handler in the driver and see whether it gets executed at least once? I don't have the code with me, other wise I could have mentioned the exact function.

    wait_event is basically waiting for the event, which will get triggered as part of the interrupt handler when the interrupt occurs. 

    Could you please share the following info?

    1. What is the pixel clock generated by the FPGA? 

    2. Which are the signals that are used in the interface between FPGA and DM36x?

    3. Width of the data bus?

  • 0 in reply to Renjith Thomas
    Prodigy 170 points

    Thank you so much for your reply Renjith. There is a confusion in the design with the inconsistency in the timing between the output data from the FPGA and the driver.

    The FPGA design has been changed to output video signal of OV5642, and I'll try to cheat the driver again.

    I'll resort to you later if I encounter any problem.

    Thank you again Renjith for your generous help.

    Jerry