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.

RDK2.8 YUV sensor support

I have a YUV sensor connected to ISS input. The sensor outputs 16bits YUV422 data, with 8bits for Y, 8bits of alternate U/V.
I set cameralink's inDataFormat to SYSTEM_DF_YUV422I_YUYV,

in cameralink_drv.c changed

pVipCreateArgs->videoIfMode = ISS_CAPT_YUV_8BIT;

When running capture_display demo, I get stable video outputs, however

1. I measured Vsync signal at 25Hz, but m3vpss reports 37fps.

2. Test color bar has completely wrong color/brighness.

I checked connection to DM8148 pins, they are in the right order. The sensor board works well with DM368 board.

I would appreciate any input and suggestions.

  • I have made some progress, but the progress is painfully slow without any support. I don't even have a ISS datasheet. I requested several times but still haven't got it. I just looked at the VPFE user guide of DM368, pretending they are the same.

    Now if I enable the color bar test on the sensor, I have stable and accurate image on the display. If the sensor outputs live data however, the video on the display looks like in a loop of displaying first several frames. I am not sure this is caused by video timing. M3vpss is reporting 37fps while i was expecting 25.

  • The first 2 seconds it runs perfectly, then the video get stuck. On the display, it displays a loop about half a second.

    How can I tell the ISS is really getting frames from sensors? There is no entry in /proc/interrupts for ISS.

    I tried printing out frame buffer for each frame in CameraLink and DisplayLink, but nothing obvious there.

  • When the display is in the loop, if I stop the pixel clock, the display will freeze as well.

    I printed out the frame buffer, and found the problem always starts on(or right after) frame 101. After that, it just keeps replaying loop of frame 94 to loop 101.

  • I dumped the frame buffer that the resizer outputs to, and found the frame didn't get updated.

    After about 100 frames, resized stopped generating interrupts, while ISIF interrupts are normal. This could explain why it displays the loop. I am trying to figure out why resizer stopped working after 100 frames.

    Here's the dump of resize registers.

    0x5c010400: 00000010
     0x5c010404: 00000301
     0x5c010408: 00000000
     0x5c01040c: 00000000
     0x5c010410: 09201500
     0x5c010414: 0000FFFF
     0x5c010418: 00000000
     0x5c01041c: 00000000
     0x5c010420: 00000001
     0x5c010424: 00000000
     0x5c010428: 00000000
     0x5c01042c: 00000000
     0x5c010430: 00000002
     0x5c010434: 00000433
     0x5c010438: 00000000
     0x5c01043c: 0000077D
     0x5c010440: 00000000
     0x5c010444: 00000000
     0x5c010448: 00000001
     0x5c01044c: 00000001
     0x5c010450: 00000000
     0x5c010454: 00000001
     0x5c010458: 00000000
     0x5c01045c: 00000000
     0x5c010460: 00000000
     0x5c010464: 000000FF
     0x5c010468: 00000000
     0x5c01046c: 000000FF
     0x5c010470: 00000000
     0x5c010474: 00000000
     0x5c010478: 00000001
     0x5c01047c: 00000000
     0x5c010480: 00000000
     0x5c010484: 00000000
     0x5c010488: 00000000
     0x5c01048c: 00000437
     0x5c010490: 0000077F
     0x5c010494: 00000000
     0x5c010498: 00000000
     0x5c01049c: 000000FF
     0x5c0104a0: 00000000
     0x5c0104a4: 000003CE
     0x5c0104a8: 00000000
     0x5c0104ac: 00000000
     0x5c0104b0: 000000FF
     0x5c0104b4: 00000000
     0x5c0104b8: 00000595
     0x5c0104bc: 00000000
     0x5c0104c0: 00000000
     0x5c0104c4: 00000000
     0x5c0104c8: 00000000
     0x5c0104cc: 00000000
     0x5c0104d0: 0000B900
     0x5c0104d4: 00001500
     0x5c0104d8: 0000B900
     0x5c0104dc: 00001500
     0x5c0104e0: 00000F00
     0x5c0104e4: 00000000
     0x5c0104e8: 00000FFF
     0x5c0104ec: 00000000
     0x5c0104f0: 00000000
     0x5c0104f4: 00000000
     0x5c0104f8: 00000000
     0x5c0104fc: 00000000