screen rolling on a short video source interrupt

[charleschang]

my target board is adv7180 + iMX51.

I run the mxc_v4l2_tvin to display the video .

when the video source has a short interrupt, the display start rolling for a period.

-- please ref the attached video.

The interrupt is so short, even ADV7180 cannot generate a Lost-Lock signal.

It seems that the camera interface cannot re-sync the input.

Is there any way to fix this problem ?

to detect it or force re-syncing ?

Thanks.

Charles.

[bikash]

Hii, we have successfully integrated tv-in(adv7180) in android ICS alpha release. But the problem we are facing is we are getting continuous rolling image in the screen. And the upper part of the screen is green coour. Please suggest some solution  .

Regards,

Bikash

[oliverkuo]

Hi bikash,

You can try to change the resolution reported by ADV7180 driver, change between raw and active of PAL or NTSC.

In my experience, green colour appeared on the top often caused by incorrect height.

Oliver

[charleschang]

seems..

type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
ioctl(fd_output_v4l, VIDIOC_STREAMOFF, &type);

type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
ioctl(fd_capture_v4l, VIDIOC_STREAMOFF, &type);

for (j = 0; j < g_output_num_buffers; j++) {
munmap(output_buffers[j].start, output_buffers[j].length);
}
for (j = 0; j < g_capture_num_buffers; j++) {
munmap(capture_buffers[j].start, capture_buffers[j].length);
}

John Doe said:

Hi,

charles chang said:

Thanks your reply.

＊ By resetting the IDMAC when I detect the ADV7180 Lost-Lock bit, 90% of scrolling device can be solved.

but some video device, the interrupt period is so short, the ADV7180 cannot report 'Lost-Lock' corrently.

that's why I need to know it from iMX51.

Charles.

As I'm facing a similar problem, can you please tell me how you did reset the IDMAC?

[JohnDoe1z]

Hi,

charles chang said:

Thanks your reply.

＊ By resetting the IDMAC when I detect the ADV7180 Lost-Lock bit, 90% of scrolling device can be solved.

but some video device, the interrupt period is so short, the ADV7180 cannot report 'Lost-Lock' corrently.

that's why I need to know it from iMX51.

Charles.

As I'm facing a similar problem, can you please tell me how you did reset the IDMAC?

[charleschang]

Problem Solved.

In im53 unit test program, I can get the interrupt on each frame,

read ADV7180 after each frame complete to get the 'frame, scanline lost " status..

 --- the IPU_INT_CTRL seems not work :(

[anthonymorel]

Hi Charles,

Please, could you tell me what is the ADV register to get the 'frame, scanline lost' status ?

Thank you.

[charleschang]

Thanks you.

I check the source : drivers/mxc/ipu3/ipu_common.c

the intial codes set all the IPU_INT_CTRL registers(5.6.9.10) to 0xFFFFFFFF. -- enable the 'new frame before end of frame" in every channel.

and there is a printk( ) in irq_handler, to print out the error message when it found any bit of them was set.

but.. there is not message out when the video source is interrupted...

[qiang_li-mpu_se]

I haven't tried such method, maybe you can enable the "New Frame before end-of-frame error indication of Channel interrupt" to check if there will be interrupt or not.

And if your hardware design can know such video interrupt, it will be more easy to handle.

[charleschang]

Thanks your reply.

Is there any method to know it ?

for example,

Can I know CSI is re-syncing or the IDMAC is mixing ?

＊ By resetting the IDMAC when I detect the ADV7180 Lost-Lock bit, 90% of scrolling device can be solved.

but some video device, the interrupt period is so short, the ADV7180 cannot report 'Lost-Lock' corrently.

that's why I need to know it from iMX51.

Charles.

Qiang Li said:

After the short interrupt, if the video source will re-start from a new frame, there will be problem. Because the IPU IDMAC is still receiving data for one frame, in this case, the frame data will be mixed. For example, if 1 frame data is 320*240*2 bytes, but when the video source interrupt happens, only 320*240*1 bytes was sent to CSI port, then the next frame's first 320*240*1 bytes will be received and mixed as 1 frame data. Although the CSI can re-sync the frame, but the IDMAC can't empty the internal buffer for a new frame's data.

You have to reset the IDMAC for the video source interrupt to capture a new frame.

[qiang_li-mpu_se]

After the short interrupt, if the video source will re-start from a new frame, there will be problem. Because the IPU IDMAC is still receiving data for one frame, in this case, the frame data will be mixed. For example, if 1 frame data is 320*240*2 bytes, but when the video source interrupt happens, only 320*240*1 bytes was sent to CSI port, then the next frame's first 320*240*1 bytes will be received and mixed as 1 frame data. Although the CSI can re-sync the frame, but the IDMAC can't empty the internal buffer for a new frame's data.

You have to reset the IDMAC for the video source interrupt to capture a new frame.