YCC 422 16 bit parallel mode times out.

[robertchapin]

Kernel version: 4.1.15-1.1.0-ga-wandboard:

Board Support package/yocto: yocto pryo and fsl-community bsp.

Processor: IMX6 solo.

We have a FPGA connected to the CSI0 parallel port. The plan is to connect a sensor to the FPGA and output 422 data in parallel mode to the IMX6. To simplify things, we added a test pattern generator in the FPGA that is always running sending raw YCC422 data with no sync codes.

FPGA: I have verified the pin out from FPGA to IMX6 solo and was able to monitor CSIO_MCLK, CSI0_PIXCLK, CSIO_VSYN and CSI0_DATA_EN with an oscilloscope at the input pins of the IMX6.  CSIO_PIXCLK is free running at 8 MHZ.  We are sending 640x480 frames. CSI0_Vsync and CSI0_MClk are 1 clock wide and is the same as the timing diagrams in the IMX6SDLRM spec.

SOFTWARE: I used the ov5640 driver as the skeleton driver for the sensor/FPGA. The probe is successful and the driver is registered and loads just fine. To enable parallel mode, I made most of my mods in mxcv4l2_capture.c.  This is one of many scripts that I have played with to send video to the HDMI port/file capture.  This script (below) works when I enable the test pattern mode in the imx6. 

• gst-launch-1.0 imxv4l2videosrc device=/dev/video0 fps_n=30 imx-capture-mode=4 ! videoparse format=7 width=640 height=480 framerate=30 ! filesink location=testcapture.bin

I have tried both gated and non gated mode and used smaller sizes to try to get IDMAC events. I always get the same results with the following error message.

ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

Here are my registers at timeout.

In MVC:mxc_v4l_dqueue 614400

ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

## MXC RD IPU_CONF 0x2600000 Vir a0a5e000 = 761

## IMXC RD IPU_INT_CTRL_1 0x260003c Vir a0a5e03c = 80000001

## IMXC RD INT_STAT_3 EOF start 0x2600208 Virt a0a5e208 = 800000

## MXC RD INT_STAT_1 EOF end  0x2600200  a0a5e200 = 800000

## MXC RD IDMAC_CH_BUSY_1 0x2608100 Virt a0a66100 = 800000

## MXC RD CSI0_SENS_CONF 0x02630000 Vir a0a6e000 = 400cb10

## MXC RD CSI0_SENS_FRM_SIZE 0x02630004 Vir a0a6e004 = 1df027f

## MXC RD CSI0_ACT_FRM_SIZE 0x02630008 Vir a0a6e008 = 1df027f

## MXC RD CSI0_OUT_FRM_CTRL 0x0263000c Vir a0a6e00c = 0

## MXC RD IPU_CSI0_TST_CTRL  0x02630010 Vir a0a6e010 = 0

## MXC RD IOMUXC_GPR13 0x020e0034 Vir f42e0034 = 4

## MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_PIX 0x020e0094 Vir f42e0094 = 10

## MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_HSYNC 0x020e0090 Vir f42e0090 = 10

## MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_VSYNC 0x020e0098 Vir  f42e0098 = 10

## MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_DATA_EN  0x020e008c Vir f42e008c = 10

## MXC CPMEM WD 1  0x02700000 Vir a0a76000 = 0

## MXC CPMEM WD 2  0x02700004 Vir a0a76004 = 0

## MXC CPMEM WD 3  0x02700008 Vir a0a76008 = 0

## MXC CPMEM WD 4  0x0270000c Vir a0a7600c = e0001800

## MXC CPMEM WD 5  0x02700010 Vir a0a76010 = 77c4f

ERROR: from element /GstPipeline:In MVC:mxc_v4l_ioctl

pipeline0/GstImxV4l2VideoSrc:imxvIn MVC: mxc_v4l_do_ioctl 40045613

NOTES/more questions:

•      I do not see an IDMAC New frame acknowledge.
•     On page 2881 in the IMX6SDLRM spec it states

16 bit YUV422

In this mode the CSI receives 2 components per cycle. The CSI is programmed to

accept the data as 16 bit generic data. The captured data will be stored in the memory

through the SMFC. The IDMAC needs to be programmed to store 16bit generic data.

When the data is read back from the memory for further processing in the IPU it will

be read as YUV422 data.

I cannot find anywhere in the spec about how to program the IDMAC to store 16bit generic data.

•      Is there a way to monitor the SMFC to see if it gets any data?
•      It appears in order to get parallel data without using embedded sync codes, mxcv4l2_capture.c needs to be modified. Is there an mxcv4l2_capture.c that exists that has all the proper register setting to support the parallel interface sending generic/raw data.

[robertchapin]

Hi Igor, I have read the posts and compared to what my settings. I did see one difference.

In ipu_ch_param_init I forced pix_format = IPU_PIX_FMT_GENERIC_16. I also divided width in this inline routine by 2 to see if would make a difference.  In all cases, I still do not get a New Frame Ack. Can someone please take a look at the register settings below. I think the key is that I do not get a IDMAC_NFACK for channel 0.  

 In MVC:mxc_streamon 

IPU pix format pixel format 2UPI
pixel_fmt is 844451913, width 640, height 480

These are printk  I added in the fill_cpmem loop in ipu_param_mem_h.
IPU CPMEM addr a08c0000 = 0
IPU CPMEM addr a08c0004 = 0
IPU CPMEM addr a08c0008 = 0
IPU CPMEM addr a08c000c = e0001800
IPU CPMEM addr a08c0010 = 77c27
IPU CPMEM addr a08c0020 = 4a20000
IPU CPMEM addr a08c0024 = 944000
IPU CPMEM addr a08c0028 = c7c000
IPU CPMEM addr a08c002c = 13fc0
IPU CPMEM addr a08c0030 = 0

These are printk  I added at the end of mxc_v4l2_s_param in mxc_v4l2_capture.c
MXC RD IPU_CONF 0x2600000 Vir a0a36000 = 761
MXC RD IPU_INT_CTRL_1 0x260003c Vir a0a3603c = 80000001
MXC RD INT_STAT_3 EOF start 0x2600208 Virt a0a36208 = 800000
MXC RD INT_STAT_1 EOF end 0x2600200 a0a36200 = 800000
MXC RD IDMAC_CH_BUSY_1 0x2608100 Virt a0a3e100 = 0
MXC RD CSI0_SENS_CONF 0x02630000 Vir a0a46000 = 400cb00
MXC RD CSI0_SENS_FRM_SIZE 0x02630004 Vir a0a46004 = 1df027f
MXC RD CSI0_ACT_FRM_SIZE 0x02630008 Vir a0a46008 = 1df027f
MXC RD CSI0_OUT_FRM_CTRL 0x0263000c Vir a0a4600c = 0
MXC RD IPU_CSI0_TST_CTRL 0x02630010 Vir a0a46010 = 0
MXC RD IOMUXC_GPR13 0x020e0034 Vir f42e0034 = 4

MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_PIX 0x020e0094 Vir f42e0094 = 10
MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_HSYNC 0x020e0090 Vir f42e0090 = 10
MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_VSYNC 0x020e0098 Vir f42e0098 = 10
MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_DATA_EN 0x020e008c Vir f42e008c = 10

In MVC:mxc_v4l_ioctl
In MVC: mxc_v4l_do_ioctl c0445611
case VIDIOC_DQBUF
In MVC:mxc_v4l_dqueue 614400
ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

These are printk  I added for the dqueue timeout.
MXC RD IPU_CONF 0x2600000 Vir a0a4e000 = 761
MXC RD IPU_INT_CTRL_1 0x260003c Vir a0a4e03c = 80000001
MXC RD INT_STAT_3 EOF start 0x2600208 Virt a0a4e208 = 800000
MXC RD INT_STAT_1 EOF end 0x2600200 a0a4e200 = 800000
MXC RD IDMAC_CH_BUSY_1 0x2608100 Virt a0a56100 = 0
MXC RD CSI0_SENS_CONF 0x02630000 Vir a0a5e000 = 400cb00
MXC RD CSI0_SENS_FRM_SIZE 0x02630004 Vir a0a5e004 = 1df027f
MXC RD CSI0_ACT_FRM_SIZE 0x02630008 Vir a0a5e008 = 1df027f
MXC RD CSI0_OUT_FRM_CTRL 0x0263000c Vir a0a5e00c = 0
MXC RD IPU_CSI0_TST_CTRL 0x02630010 Vir a0a5e010 = 0

MXC RD IOMUXC_GPR13 0x020e0034 Vir f42e0034 = 4

MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_PIX 0x020e0094 Vir f42e0094 = 10
MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_HSYNC 0x020e0090 Vir f42e0090 = 10
MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_VSYNC 0x020e0098 Vir f42e0098 = 10
MXC RD IOMUXC_SW_MUX_CTL_PAD_CSIO_DATA_EN 0x020e008c Vir f42e008c = 10

[gcarlson]

igorpadykov

Rob contacted me for additional brainstorming.  Knowing that NXP can only offer very limited Linux support only on basic functions for their dev boards (and I'm not sure how much input/support NXP offers regarding WAND boards).....lets try looking at it a different way.....

Is there any test/validation/example code available that demonstrates  the parallel interface sending generic/raw data?

For example....the OBDS (On Board Diagnostic Software) package includes many bare metal code snippets that exercise and test the more basic I/0 and communications modules.  The IPU is certainly a much more extensive module, but if there was even non-linux driver test code that would exercise the parallel interface with raw data....we could use that as a template and reconfigure/customize the Linux driver to use the same IPU register settings.

Gordy Carlson

Avnet FAE - Upstate NY

[igorpadykov]

seems more close bsp example would be ov5647:

in 4.1.15 BSP release, there is ov5647_mipi driver for iMX7: drivers/media/platform/mxc/subdev/ov5647_mipi.c.

unfortunately I am not aware of any nxp test/validation/example code for parallel interface sending generic/raw data.

On community:

https://community.nxp.com/message/344529#344529 

Best regards
igor

[robertchapin]

Hi I looked at the new post but I am in parallel generic16 mode, a different mode of operation. I had already made sure that my capture input was not set to CSI IC MEM and I can turn on test pattern which works.

I’ll will still check out the mipi driver. I would really like to know if anyone can look at the registers that I have dumped and tell me why I am not getting an IDMAC_NFACK,(New frame Ack) assuming the hardware signals hsync, vsync and pixclock are being driven properly. I included the signal descriptions which I have probed in the original post.

Thanks,

Rob

[robertchapin]

Hi Igor ,

I am still waiting for an answer to this question. I have spent many hours trying to get this port working. Is there anyone at NXP that can actually review these register settings. I think I have looked at every post on the NXP on using this port so I do not  think referencing a post  will help me.

[igorpadykov]

Hi Rob

unfortunately there is no support for generic mode in nxp official bsps,

for help with bsp customizations one can apply to

NXP Professional Services:

http://www.nxp.com/support/nxp-professional-services:PROFESSIONAL-SERVICE

Best regards
igor

[igorpadykov]

Hi Robert

without hsync non-gated mode should be used. For generic/raw processing

one can look at

https://community.nxp.com/thread/302769

MX53 CSI/IDMAC config for Aptina 12-bit grayscale camera? 

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