AnsweredAssumed Answered

mxc_v4l2_capture.c - V4L2_PIX_FMT_*  to IPU_PIX_FMT_* conversion issue

Question asked by kt1023 on Dec 13, 2013



I have tried to add a new pixel format to the "MXC Video For Linux Camera" driver in


for a setup consisting of an i.MX536 and an MT9D131 on csi0. I have been able to get it to work

capturing bayer data using the V4L2_PIX_FMT_GREY which goes in line with the code we

already have for it.


There is however one niggling issue with the driver internal translation between the various pixel formats.

As I see it I need to translate from V4L2_PIX_FMT_GREY to IPU_PIX_FMT_GENERIC and finally

to CSI_SENS_CONF_DATA_FMT_BAYER as the value that is written to the sensor configuration register.


The following piece of code in mxc_v4l2_capture.c:1637


pr_debug("End of %s: crop_current widthxheight %d x %d\n", __func__, cam->crop_current.width, cam->crop_current.height);


csi_param.data_fmt = cam_fmt.fmt.pix.pixelformat;


pr_debug("On Open: Input to ipu size is %d x %d\n", cam_fmt.fmt.pix.width, cam_fmt.fmt.pix.height);

ipu_csi_set_window_size(cam->crop_current.width, cam->crop_current.width, cam->csi);

ipu_csi_set_window_pos(cam->crop_current.left, cam->, cam->csi);

ipu_csi_init_interface(cam->crop_bounds.width, cam->crop_bounds.height, cam_fmt.fmt.pix.pixelformat, csi_param);



causes a problem in ipu_csi_init_interface where cam_fmt.fmt.pix.pixelformat is passed as a value that should rather

transport IPU_PIX_FMT_* type format data instead of V4L2_PIX_FMT_* type data. I just set this to IPU_PIX_FMT_GENERIC

for my special case but this is unacceptable. I'm really not sure how this driver is supposed to be used especially since the

test code Freescale has mentioned in imx-test also causes an issue if it gets extended to support V4L2_PIX_FMT_GREY.


I hope you can help.


Best Regards,


K. Timmler