• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 436 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.

Problem with getting YUV data over the camera ISP port operating in the parallel sync mode into memory

EugeneS
Prodigy 150 points

Hi,

We are trying to use Linux camera driver to get our data into memory. Our setup uses uses 8 data lines and HSync, VSync and WEN signals are configured as input into the ISP.

When we start capture we see HSYNC and VSYNC interrupts. The driver also reports VD0 and VD1 interrupts. But when it comes time to reprogram CCDC_SDR_ADDR the driver enters into the busy loop trying to detect NON-BUSY state of the CCDC module but it never sees such state.

We are using Linux PSP 03.00.01.06.

What can be wrong if our registers are reported to have the following values:

ISPCCDC: ISP_CTRL =0x218308
ISPCCDC: ccdc input format is CCDC_YUV_SYNC
ISPCCDC: ccdc output format is CCDC_OTHERS_MEM
ISPCCDC: ###ISP_CTRL in ccdc =0x218308
ISPCCDC: ###ISP_IRQ0ENABLE in ccdc =0x0
ISPCCDC: ###ISP_IRQ0STATUS in ccdc =0x80000300
ISPCCDC: ###CCDC SYN_MODE=0x3172c
ISPCCDC: ###CCDC HORZ_INFO=0x27f
ISPCCDC: ###CCDC VERT_START=0x0
ISPCCDC: ###CCDC VERT_LINES=0x1df
ISPCCDC: ###CCDC CULLING=0xffff00ff
ISPCCDC: ###CCDC HSIZE_OFF=0x500
ISPCCDC: ###CCDC SDOFST=0x0
ISPCCDC: ###CCDC SDR_ADDR=0x0
ISPCCDC: ###CCDC CLAMP=0x10
ISPCCDC: ###CCDC COLPTN=0x0
ISPCCDC: ###CCDC CFG=0x100
ISPCCDC: ###CCDC VP_OUT=0x0
ISPCCDC: ###CCDC_SDR_ADDR= 0x0
ISPCCDC: ###CCDC FMTCFG=0x0
ISPCCDC: ###CCDC FMT_HORZ=0x0
ISPCCDC: ###CCDC FMT_VERT=0x0
ISPCCDC: ###CCDC LSC_CONFIG=0x6600
ISPCCDC: ###CCDC LSC_INIT=0x0
ISPCCDC: ###CCDC LSC_TABLE BASE=0x0
ISPCCDC: ###CCDC LSC TABLE OFFSET=0x0

Documentation states that it is possible to get YUV data into memory. What can be wrong with our setup? Any help/advice would be very helpful.

Thank you,

Eugene

 

  • 0
    TI__Guru*** 125430 points

    What's the speed of the external PCLK being provided?  How much blanking is there (horizontal and vertical)?  One thought that comes to mind is if you don't have enough blanking perhaps the code would never "see" the CCDC_PCR[1] BUSY bit get cleared since it would be too fast.

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Do you see any data actually landing in memory?  In other words, does it seem like you are actually capturing a frame of data but just having issues related to swapping out memory pointers for the next frame?

  • 0 in reply to Brad Griffis
    Intellectual 380 points

    Hi 

    I'm facing same issue on same environment.

    Taking a look in the code, I notice that the acquisition process (isp_buf_process) doesn't start due to a if condition unsatisfied (V4L2_FIELD_INTERLACED):

    drivers/media/video/isp/isp.c:977

    if (irqstatus & CCDC_VD0) {

    if (isp->pipeline.pix.field == V4L2_FIELD_INTERLACED) {

    /* Skip even fields, and process only odd fields */

    if (isp->current_field != 0)

    if (RAW_CAPTURE(isp))

    isp_buf_process(dev, bufs);

    }

    I tried to force the process to start, but I got iommu errors.

    I hope my observations could help you.

    Andrea

     

     

     

     

  • 0 in reply to Andrea Cattani
    TI__Guru*** 125430 points

    When you look at the data in memory can you tell if it's all there?  Hopefully you can send in some kind of data pattern like a count so that you can easily tell if any of the data is missing, corrupted, etc.  Looking at your register settings it appears your horizontal and vertical syncs have been configured as active low signals.  Does that match your hardware, i.e. those signals are asserted low while the data is being captured?  One thought that comes to mind is if your syncs are not quite right then perhaps you're only capturing 639 pixels per line or something like that and so it doesn't think it's done with the frame.  If you can capture an incrementing count I think it should be pretty easy to see what's happening.

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Hi Eugene,

    What's the current status of this issue?  Were you able to send in a data pattern to look at the corresponding data landing in memory?

    Best regards,
    Brad