Screen Rolling with ISL7998x (quad FBAS in) / imx6 quad

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Screen Rolling with ISL7998x (quad FBAS in) / imx6 quad

1,678 次查看
holgerweber
Contributor IV

I use a ISL7998x which is connected to the mipi port of an imx6 quad core CPU. The image capturing runs as expected but sometimes the video starts rolling. That rolling takes sever seconds depending on the posittion of the frame start till it is stable again.

I get the following kernel output as soon as the image starts rolling till rolling stops: IPU Warning - IPU_INT_STAT_5 = 0x00000001 . The issue sems to come up if the ISL7998x does a resync an sends a shorter mipi package after that the IPU does a resync by incrementing the image by one line each frame (see link below).

I found several entries describing this issue with different video decoders but didn't find the "real" solution.

I followed the following links:

15. i.MX Video Capture Driver — The Linux Kernel documentation  (under the header 15.9 the rolling image effect is described - so it is known)

https://community.nxp.com/message/308948?commentID=308948#comment-308948 - Says that resetting the DMAC would help but I have no idea how to do that.

My idea was to reset the DMAC as soon as I get the error message in the kernel (isr) but I don't know how.

Maybe there is also another fix. At the moment I use kernel 4.1.15.

标签 (4)
0 项奖励
6 回复数

1,188 次查看
holgerweber
Contributor IV

I use gstreamer for video capturing so as soon as I detect a scrolling image I reinitialize the source element (Null/Playing).

For scroll detection I use the kernel ouput  "2400000.ipu IPU_INT_STAT_5 0x00000001". The first value tells me which IPU it is and the last which channel.

After that workaround I get another bug. After resetting the element the video picture is shiftet about 20 pixels to the right. So on the left side I can see 20px of the image which should be on the right side.

Is there a plan when this bug should be fixed?

0 项奖励

1,188 次查看
igorpadykov
NXP Employee
NXP Employee

this is not bug as normal ipu operation does not assume resetting the DMACs,

provided workaround does not guarantee full solution.

Best regards
igor

0 项奖励

1,188 次查看
holgerweber
Contributor IV

The bug is that the image starts rolling because the IPU gets out of sync. I don't like that workaround but I haven't seen any other solution.

0 项奖励

1,188 次查看
igorpadykov
NXP Employee
NXP Employee

probably ipu is not configured properly so IPU gets out of sync.

NXP has special service for helping with software customizations

Commercial Support and Engineering Services | NXP 

Best regards
igor

0 项奖励

1,188 次查看
igorpadykov
NXP Employee
NXP Employee

Hi holgerweber

one can check the "VIDIOC_STREAMON" IOCTL from V4L2 driver
linux/drivers/media/platform/mxc/capture/mxc_v4l2_capture.c,
functions mxc_streamon and mxc_streamoff.
These functions start/stop the streaming and may reset some IDMAC channel.

mxc_v4l2_capture.c\capture\mxc\platform\media\drivers - linux-imx - i.MX Linux kernel 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 项奖励

1,188 次查看
holgerweber
Contributor IV

Hi igor,

I tried this by issuing the VIDIOC_STREAMON/VIDIOC_STREAMOFF from another program. Stopping worked but getting the stream on again failed because there must be another ioctl before for setting buffers etc. which I have no access to from this program.

0 项奖励