[imx6]how to capture 16bits generic data

[osaka]

hi all:

we use imx6 ipu/csi (no mipi) to capture 16bits yuv data with external hsync/vsync,

( IOMUX = D19~D12=Y, D11~D4=U/V,  MCLK+HSYNC+VSYNC)

( input = CSI-MEM, ipr_csi_enc.c )

( size = raw.width*height:858*525, active.width*height:720*480, active.left*top:0*4)

Mr Qiang Li notice us that should use generic data mode, so we modify code (some in bsp).

unfortunately, all viodioc went without err, but still :

ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

ERROR.VIDIOC_DQBUF failed.

ERROR.VIDIOC_QBUF failed.

the following is regs dump before streamon, which we added in mxc_v4l2_capture: ( CSI-MEM only use IDMAC_ch0, right?)

******** Dump Registers.IPU_CONF

         [263_0000]: 000007A1

******** Dump Registers.IPU_INT_CTRL_x

         [263_003C]: 80000001

         [263_0040]: 00080000 00000000 00000000 BFFEFF2F

         [263_0050]: 001FFF02 00000000 00000000 DC000001

         [263_0060]: 777F000F 00000000 00000000 00000000

         [263_0070]: 00000000 00000000

******** Dump Registers.CSI_SENS_CONF

         [263_0000]: 0400CB00 020C0359 01DF02CF 00000004

         [263_0010]: 00000000 00000000 00000000 00000000

         [263_0020]: FFFFFFFF 00000000 00000000 00000000

******** Dump Registers.CPMEM channel.0

         channel.0      word 0[4:0] - 00077C59 E0001800 00000000 00000000 00000000

         channel.0      word 1[4:0] - 00000000 000167C0 00CFC000 0088C000 04440000

Does anyone could give us some infor to insure any regs setting err or any possible ressons lead to this timeout err ?

all for thanks.

[meflo]

Thank you very much for the info.

[meflo]

Okay then, seems like I should recheck the data pins again, as I suspect one of them might actually be the pixel clock.

As for setting the frame data size in CPMEM, could you point me to some code example so I could see how it is done correctly?

Thank you for your time.

[andyclayton]

We couldn't located the error point, it was trial and error ( and the fact our decoder with default settings allowed video to be captured).

[osaka]

andy

with the great help from Mr.Qiang Li,   we could get our 16bit generic data ,

Watching to NPB in CPMEM,  it make the raw data to be separated by 0x0000 ( within NPB=64pixel/burst )

our BPP=16bit/pixel,  so NPB = 512bit/16 = 32,  then we could get correct raw data.

owe everything to Mr.Li, THX

[meflo]

Hi Jian, could you detail a little bit on how you got it working? How exactly do you setup NPB and BPP in code?

Thanks

[andyclayton]

Li Jian,

Have you connected the DE signal on the CSI port? if so disconnect it or set it high. In our case no interrupts were generated because it was connected and was being held low.

Andy

[osaka]

THX, andy

i'll follow your suggest and test it,  by the way , anytime u meet a non-interrupt state, how to locate the err point?  such as u mentiond DE-connection err,  something more? ( beside this page's "externel 16bit generic data", we're asked to capture 800*480 non-interlace whith BT.656,   it failed in non-irq too,  :smileycry: really shame )

[qiang_li-mpu_se]

From my experience, no EOF interrupt always means the frame data size is not correct set in CSI IDMAC CPMEM.

[meflo]

Hi,

could you detail a bit on how I can set the correct frame data size in CSI IDMAC CPMEM? Is there any existing code that handles this in any drivers currently in the kernel, specifically in the ADV7180 kernel driver? I am facing this exact timing issue with an ADV7180 (ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0).

P.S.: I should also note that I am only using the 8 data pins for CSI, no HSYNC, VSYNC nor PIXCLK.

Thanks

[qiang_li-mpu_se]

Hi Menton,

    If you only used 8 data pins, no pixel clock pin, I think it can't be supported by CSI. At least, 9 pins were needed, 8 data pins and pixel clock pin, in this 9 pins mode, BT656 protocol should be used, EAV/SAV should be embedded on data pins.

    For frame data size setting in CPMEM, it was calculated with width * height * (bits/pixel / 8) = FW*FH*(BPP/8).

[meflo]

Thanks for getting back to me, Qiang. Indeed, the intent is to use BT.656, but there's not PIXCLK, only 8 data pins are used. For the adv 7180 kernel driver, I saw in the code that implicitly it does not use external HSYNC / VSYNC as bt_sync_correct is set to 0. So I assume EAV / SAV is used instead and presumably it is working as implemented currently in that kernel driver. Seems like the only outstanding issue is the lack of the pixel clock pin. Would you have some info at hand about CSI so I could look further into it and check out weather the clock pin is absolutely needed or not?

Also, I am not sure I understand where the frame data size setting in CPMEM is done, meaning where in the code I should actually do that.

Thank you!

[qiang_li-mpu_se]

Hi Menton, pixel clock pin is must for CSI.

[meflo]

Thanks Qiang for the confirmation. Is there any code example somewhere about how to set the correct frame data size in CPMEM?

[qiang_li-mpu_se]

In linux BSP, your sensor driver just needs report the data format to the MXC V4l2 capture driver.

The final code for CPMEM initialize is in function _ipu_ch_param_init(), kernel file drivers\mxc\ipu3\ipu_param_mem.h

[qiang_li-mpu_se]

There are some discusstion for generic mode capture, you can reference to them:

https://community.freescale.com/message/327657

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

[DraganOstojic]

Mr. Li, the link https://community.freescale.com/message/327657#327657 gives the "Unauthorized" message. As I'm experiencing the similar issue with 16-bit generic capture, can you please check how this link can be enabled?

Thanks

[osaka]

Mr. Li:

h ttps://community.freescale.com/message/327657

this page may not be found , since it shows

"Access to this place or content is restricted. If you think this is a mistake, please contact your administrator or the person who directed you here."

[andyclayton]

Qiang,

We are also having difficulty capturing 16 bit generic data, and have followed the advice in the thread, but I can't seem to access the message/327657 - I get an "unauthorized Access" message.

We can actually capture images but the data seems to be incorrect :-

We've tried to set the IPU/IDMAC to

run in "generic data 16 bit" mode, but it doesn't transfer

the data correctly.  I'm getting stuff like this:

0038b40: 0000 9e64 9362 715d 0000 9e64 9362 6764 ...d.bq]...d.bgd

0038b50: 0000 9c65 9b65 6865 0000 9c65 9b65 6865 ...e.ehe...e.ehe

0038b60: 0000 9c65 9c65 6865 0000 9c65 9c65 6865 ...e.ehe...e.ehe

0038b70: 0000 9c65 9c65 6865 0000 9c65 9c65 6865 ...e.ehe...e.ehe

0038b80: 0000 9b65 9c65 6865 0000 9b65 9c65 6965 ...e.ehe...e.eie

0038b90: 0000 93a7 9f65 6565 0000 93a7 9f65 7065 .....eee.....epe

See the blank (zero) words?  That should not happen.

The Imx6 is connected to a video decoder on CSI0, with the video decoder set to output 16 bit YUV 422 data with seperate Hsync and Vsync. The CSI0 pins are configured for 16 bit generic data (we are aware that the 16bit BT.1120 type data is a different set of pins and have allowed for it in the design if the need arises), and the IMx6 is configured to run in gated clock mode.

Any help or pointers on setting the Imx6 up to accept 16 bit generic data and/or BT1120 data would be appreciated.

Regards

Andy

[osaka]

:smileycry:

u are still fortunate that u had already gotten video data, our work is right failing in video capture, without any EOF irq, but only "mxc_v4l_dqueue timeout enc_counter 0",

for god save.