Problem capturing 12bit greyscale (parallel interface -> IPU -> IDMAC -> MEM) - bits seem to be interleaved/shifted

[-robert-]

Hi all,

I am trying to capture a 12bit greyscale image from a custom camera using a SabreLite board equipped with a IMX6Q running Yocto  with kernel 3.10.17 (latest available beta from boundary devices repo, manually updated recipe).

Having read quite a bunch of ressources on this forum and the RM, I was able to capture images having the correct width, height, size without getting error messages and/or unwanted IPU-interrupts.

Nevertheless, the data captured is corrupted/only half-way correct: of every data word (16bit, not packed!), it looks like it consists of only 8 valid bits which are repeated in a pattern that depends on the CSI_DATA_WIDTH (hex-numbers represent anticipated bit-positions in a captured 16bit word!):

Intended (Little-Endian!?): 7654 3210 FEDC BA98

DATA_WIDTH ("N") = 9: ???? 8765 BA98 7654

DATA_WIDTH ("N") = 10: ???? _876 BA98 7654

DATA_WIDTH ("N") = 11: ???? __87 BA98 7654

DATA_WIDTH ("N") = 12: ???? ___8 BA98 7654

DATA_WIDTH ("N") = 13: ???? ____ BA98 7654

DATA_WIDTH ("N") = 14-16 - same as 13

So what is weird is the data being both shifted and not shifted when changing DATA_WIDTH.

I intensively considered 16-bit generic capture not working, IPU - bayer pattern conversion and i.MX6Q MIPI CSI2: Capturing RAW12 generic data . The IC is bypassed, burst sizes were checked carefully but do not show any difference, pixelformats/-widths were thoroughly checked as well and bayer/generic format was selected whereever possible. Patches were applied to the ipuv3-files (drivers/mxc/ipuv3), mxc-v4l2-capture-files (drivers/media/platform/mxc), Freescale gstreamer-plugins (both 0.10 and 1.0) and the custom camera driver.

Is the CSI_DATA_WIDTH considerd for some unpacking/extension? At what stage could the data handled in such a way so the described pattern occurs?

Thank you very much!

BR

Robert

[-robert-]

Hi!

Just to close this issue, although we found the solution long time ago:

DATA_WIDTH etc. were all set correctly.

The missing link was the pin-mapping in the board-file: in arch/arm/boot/dts/imx6qdl.dtsi the "pinctrl_ipu1_2: ipu1grp-2 { /* parallel camera */" entry defines only eight bit data width (although the ov5640 is using this entry and "claims" 12bit!). As soon as we defined the entry to have four more pins all the weird behaviour was gone. Now the only thing left is that as we don't want the 12bit being packed they are for some reason left-adjusted, requiring a 4bit-shift for further processing. Did not find a way to fix this as well.

Cheers

Robert

[joanxie]

how did you set SI0_DATA_WIDTH , I wonder if the SI0_DATA_WIDTH in IPUx_CSI0_SENS_CONF register should be set to 0101 (12 bits per color) instead of  0001 (8 bits per color)