imx6 CSI and TW9960

[ThorstenSchmelzer]

Hi community,

I am trying to use the composite video decoder chip TW9960 on the parallel CSI of the i.MX6 (Dual). We only have the data pins and the pixelclock connected so I want to use BT656 internal SAV and EAV signals. I have created a driver based on the one for the adv7180. Basically the driver is working. I2C communication to the TW9960 is working, the corresponding slave ioctrls are called inside my driver form the mxc_v4l2_capture driver. I have set the following parameters in my ioctl_g_ifparm:

parm->if_type = V4L2_IF_TYPE_BT656; /* This is the only possibility. */

parm->u.bt656.mode = V4L2_IF_TYPE_BT656_MODE_BT_8BIT;

parm->u.bt656.bt_sync_correct = 1; // also tried with =0 does not seem to make a difference

parm->u.bt656.clock_curr = 0;

parm->u.bt656.latch_clk_inv = 1;

As test applications I use the ones from the imx-test package (mxc_v4l2_still.out, mxc_v4l2_capture.out and mxc_v4l2_tvin.out). Everything seems to work until I get to the point where the data is actually captured. For for the mxc_v4l2_still I get an:

ERROR: v4l2 capture: mxc_v4l_read timeout counter 0

When using mxc_v4l2_capture.out or mxc_v4l2_tvin.out I get an:

ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

Both errors seem to indicate that we are waiting for an EOF interrupt which does not occur. We measured the output stream of the TW9960 and it seem to produce a valid bt656 video signal. It is also generating the EAV and SAV fields inside the stream. This led me to the CSI configuration in ipu_csi_init_interface, file ipu_capture.c. For clock mode IPU_CSI_CLK_MODE_CCIR656_INTERLACED the registers CSI_CCIR_CODE_1/2/3 are written depending on wether PAL or NTSC is used (the camera we are using on the tw9960 is a PAL camera). The meaning of CSI_CCIR_CODE_3 register is quite clear to me. But the description of CSI_CCIR_CODE_1/2 sound rather unspecific. I assumed that the 3-bit fields are representing the F,V and H bits in EAV and SAV codes in the bt656 stream. And theses registers have to be set accordingly to the data produced by the video input stream. However the datasheet does not specify the order (or usage) of the individual bits. Can anyone confirm my assumtion?

Any other suggestions what I could check?

I am enabling parallel video inputs in my board configuration file with:

/* enable parallel input for IPU1 CSI0 */

mxc_iomux_set_gpr_register(1, 19, 1, 1);

/* enable parallel input for IPU2 CSI1 */

mxc_iomux_set_gpr_register(1, 20, 1, 1);

Thanks and regards

Thorsten Schmelzer

[juangutierrez]

According to the next note on the code at drivers/mxc/ipu3/ipu_capture.c

/* PAL case */                

/*

* Field0Blank END  = 0x7, Field0BlankStart = 0x3,

* Field0Active END  = 0x5, Field0ActiveStart = 0x1

*/  

ipu_csi_write(ipu, csi, 0xD07DF, CSI_CCIR_CODE_1);

/*

* Field1Blank END  = 0x6, Field1BlankStart = 0x2,

* Field1Active END  = 0x4, Field1ActiveStart = 0

*/

ipu_csi_write(ipu, csi, 0x40596, CSI_CCIR_CODE_2);

We can get the next table that clarifies that the order in CSI_CCIR_CODE_1/2 is HVF

FIELD  VTIME  HTIME    H V F

Field0  Blank    END        1 1 1   0x7

Field0  Blank    START    0 1 1   0x3

Field0  Active   END        1 0 1   0x5

Field0  Active   START    0 0 1   0x1

Field1  Blank    END        1 1 0   0x6

Field1  Blank    START    0 1 0   0x2

Field1  Active   END        1 0 0   0x4

Field1  Active   START    0 0 0   0x0

[osaka]

some more questions, please do give us a favor.  thx

within ipu_capture.c , the ccir code is 0x40596/0xD07DF.

if we change any value of ccir code,  we will fail to capture anything .

so we consider the 0x40596/0xD07DF is exactly the same code which our camera decoder sends out.

but we just can only get 25field/s (12.5 frame/s ) in PAL,   ( omg ...)

so , any any any suggestions ?  T_T

Thanks and regards

[juangutierrez]

The ccir code  depends of the resolution. For PAL the correct code is 0xD07DF for Field0 (CSI0_CCIR_CODE_1) and 0x40596 for Field1 (CSI0_CCIR_CODE_2).

In both the 1st and 2nd blanking have the same values. If you are capturing PAl you should keep this settings

/*

* Field0Blank END  = 0x7, Field0BlankStart = 0x3,

* Field0Active END  = 0x5, Field0ActiveStart = 0x1

*/

           ================================================ FIELD  0 =================================================

          |StartActive | EndActive | Reserved | Start2ndBlanking | End2ndBlanking | Start1stBlanking | End1stBlanking |

0xD07DF = |    b001    |    b101   |  b0000   |        b011      |      b111      |        b011      |      b111      |

          |    0x1     |    0x5    |          |        0x3       |      0x7       |        0x3       |      0x7       |

           ===========================================================================================================

/*

* Field1Blank END  = 0x6, Field1BlankStart = 0x2,

* Field1Active END  = 0x4, Field1ActiveStart = 0

*/

           ================================================ FIELD  1 ===================================================

          |  StartActive | EndActive | Reserved | Start2ndBlanking | End2ndBlanking | Start1stBlanking | End1stBlanking |

0x40596 = |     b000     |    b100   |  b0000   |      b010        |      b110      |        b010      |      b110      |

          |     0x0      |    0x4    |          |      0x2         |      0x6       |        0x2       |       0x6      |

           ==============================================================================================================

So, the problem seems to be in the frame rate. Make sure you are not skipping frames CSI0_MAX_RATIO_SKIP_SMFC should be 0.

Maybe some problem with some clock configuration

[ThorstenSchmelzer]

May I add that since the BSP Release 4.0.0 the CCIR values have been swapped. Since this Commit/Patch:

[PATCH 2432/2508] ENGR00243315-1 IPUv3 CSI:Correct CCIR code1/2 for PAL and NTSC

We reversed CCIR code1/2 setting before, which may brings

captured frame quality issue(jaggy edge can be seen). This

patch revert that change.

The resulting code for PAL is:

		/* PAL case */
		/*
		* Field0BlankEnd = 0x6, Field0BlankStart = 0x2,
		* Field0ActiveEnd = 0x4, Field0ActiveStart = 0
		*/
		ipu_csi_write(ipu, csi, 0x40596, CSI_CCIR_CODE_1);
		/*
		* Field1BlankEnd = 0x7, Field1BlankStart = 0x3,
		* Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1
		*/
		ipu_csi_write(ipu, csi, 0xD07DF, CSI_CCIR_CODE_2);

ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3);

@Li

As we still do not get any capture data from our chip. May I ask which camera/decoder chip you are using? You do not use any external Hsync and Vsync signals ?

[juangutierrez]

Also I guess you already have this patch, or making your changes based on this

https://community.freescale.com/docs/DOC-94019

[ThorstenSchmelzer]

Thanks for the clarification of the CCIR_CODE registers. I had seen this patch but I did not take it into account because it is for bt656 output. If I only want to use camera inputs I should not need this patch. Or am I wrong?

So far I only want to use bt656 input for the TW chip, a display is connected through LVDS.

[juangutierrez]

Yes you are right, this is only for bt656 output, you don't need to worry about for  bt656 input