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!