Split image on EVMDM6467

This issue is actually shown as a constraint as opposed to a known bug in the manual which unfortunately makes it sound like it may not be fixed, if it will or not I could not say for certain. The issue actually sounds like a similar issue that was common with the DM642 video ports where the DMA would get out of sync with the video port when the video was disconnected and reconnected while it was running. Back then the solution was to call a particular function to restart the DMAs and recover the signal when this happened, triggered by overrun event and/or by a hard signal from the video encoder that the disconnect/reconnect has happened. Unfortunately I do not see such a function in the API provided by the PSP driver, though you may be able to have the same effect by peforming a VIDIOC_STREAMOFF followed by a VIDIOC_STREAMON when you detect the issue which leads to the problem of detection which may have to be done by an interrupt line from the video encoder. Unfortunately I doubt the solution will be simple and all software, as this issue has been known about even in prior DM6467 VPIF driver releases.

The VIDIOC_STREAMON didn't quite work well and ioctl fails. Though, I was able to fix the issue by releasing the capture handle and re-create new one. But, it made my regular capture very slow as I make ioctl call every frame to detect the video cable disconnection.

I have following piece of code before I do capture:

     if (ioctl(fd, VIDIOC_G_INPUT, &input) == -1) {

        printf("ioctl - input not connected......\n");

        goto cleanup; //release the driver instance

        }

---------------

BTW.. We use DM642 and tried same test case but we don't see split images. I believe it must have been fixed at driver level and therefore we are not aware of this issue on DM642.  

 I profiled the ioctl and it takes @3sec on average:

ioctl took...... 2509 msec
ioctl took...... 2790 msec
ioctl took...... 5315 msec
ioctl took...... 2468 msec
ioctl took...... 3121 msec
ioctl took...... 2375 msec
ioctl took...... 5715 msec
ioctl took...... 3172 msec
ioctl took...... 5921 msec
ioctl took...... 2501 msec

Does it take so long normally? 

3 msec sounds quite long to process an IOCTL; in other products (and probably on this one as well), we use IOCTL (XXXX_WAIT_FOR_VSYNC) for each frame of video which means they are being processed faster than 33msec.

I would investigate the driver source code a bit further, try returning right away from the IOCTL to see if it is the user space to kernel space penalty is not the issue (I would hope not).  I would guess most likely it is the implementation of how this IOCTL is processed.

 Its 3 seconds and that's too long to process an IOCTL. Are you investigating the driver source? Do you point me to someone who has written the driver?

Apologies, I meant 3 sec.  In my previous post, I suggested you modify the code to return from the IOCTL call right away to confirm it is not the call from user space to kernel space that is taking long, but perhaps the implementation that processes that particular ioctl.  I can tell you for sure that other IOCTLs such as FBIO_WAITFORVSYNC on DM6446 are prcessed every 33 msec, hence I do not suspect it is the call itself.  You may need to change the implementation undeneath the IOCTL to achieve the performance you need (e.g. store needed info in global variable which you can return right away).

Hi,

It is correct that getinput ioctl takes more time. It is because it has to sense whether any input is active or not. For sensing the input, driver has to write a register and after some time, it has to read a status register to see if input is detected. This delay after which status register is read is very long because we had observed that it takes lot of time for status register to get updated and provide result of detection. Driver kept this delay constant, which is around 1 second. If hardware detects and updates the register within this time, driver returns this input to the application. Otherwise driver will go and try to detect next input in the same decoder or first input in the next decoder. Since getinput takes long time, it should not be called in loop. 

Plug out and re-plug in of physical inputs are not supported while streaming is going on. It is because we had observed that image gets split if we remove luma or composite cables and re-connect them while streaming on. This comes because DMA goes out of sync of VPIF. As VPIF has dedicated DMA channels and does not provide any facility of re-syncing the DMA, driver does not support this. The only way out here is to stop streaming by STREAMOFF and restart streaming by STREAMON ioctl. For calling STREAMON ioctl after STREAMON, we don't have to call getinput again if the input is same. If we change the input, then only, we should call getinpt ioctl to detect the input. So to remove this split images artifact, we just have to stop streaming by STREAMOFF, en-queueu the buffers and start the streaming by STREAMON ioctl.

Thanks,

Brijesh Jadav

 Hi Brijesh,

 Thanks for the explanation. So if getinput is not suppossed to be called in a loop the question remains then how does one detect that the input is unplugged "programatically". To make IOCTL calls to STREAMOFF and STREAMON the program will need to know that the input is unplugged.

Any suggestions to overcome this ?

Thanks and Regards

Krishna Prabhakaran

There is probably a better way, but one quick thought would be to have a thread periodically checking to see if a new frame was received, and if no new frame is detected within say half a second than go through the STREAMOFF/STREAMON sequence as that likely means that there are no more syncs coming into the device and thus some sort of disconnect. This makes some assumptions about the DM6467 driver that I am not the most familiar with, but I believe a mechanism like this could help to recover without constant delays, perhaps Brijesh may have additional feedback.

Thanks for the suggestion. I have tried with checking the signal on a periodic basis and reseting the video input upon detection of no signal, but as i am running an Computer vision algorithm on the captured image the algorithm changes its model causing it to behave wierdly. Although upon reset of the video input the model regains its state but for that period behaves weird which could not be accpetable on an real time enviornment.

Is there any way possibly an interrupt which will tell me the instant the video cables are unplugged so that can gaurd my algorithm model accordingly?

Unfortunately as far as I know there is no interrupt signal built into the DM6467 video port that would trigger the instant the video cables are unplugged. At a hardware level if your video decoder/ADC can detect the cable being unplugged than you could potentially have it drive a GPIO interrupt line on the DM6467 to make it aware of the event.

I don't think you can detect video signal at run time via v4l2 ioctls (May be I am wrong). Have you verified if DQBUF ioctl is blocked when is camera is disconnected? If the ioctl is blocked then you don't need to do anything.  FYI, you can detected video signal via checking  "Status 1 Register" in TVP5147.  See http://focus.ti.com/lit/ds/symlink/tvp5147.pdf for more information. You can access this register via i2c app from the user space.

Thanks - Brijesh Singh