Hi all,
I have been trying to run image capture demo software posted on Leopard support page, i have some doubts about the driver
Can someone explain me why you add the device info using dm355-evm board and not leopard board?
Even though, it seems to be incomplete, i had to add mt9v113 as an input to vpfe_capture, to achive to register the device, here is how i add it. i would like to know if this is the correct information, do i have to support routing?
+static struct vpfe_capture_input vpfe_capture_inputs = {+ .num_inputs = VPFE_MAX_DEC_INPUTS,+ .current_input = 0,+ .inputs[0] = {+ .dec_name = MT9V113_MODULE_NAME,+ .input = {+ .index = 0,+ .name = "VGA Sensor",+ .type = V4L2_INPUT_TYPE_CAMERA,+ .std = V4L2_STD_NTSC,+ },+ .routing_supported = 0,+ },
+};
Also, it seems weird to have ccdc_if_type wired to VPFE_RAW_BAYER on ccdc_dm355.c,
Are you sure you post the correct driver?
Maria
using dm355-evm instead of leopard board is just because there is no leoaprd board defined in 2.6.18. We should fix it in the future.
This driver has been tested with video capture demo, which is also posted together with the driver patch.
You are right, It looks a little bit strange thtat it defines VPFE_RAW_BAYER as the input type. It is actually due to hardware compatibility. Since all camera modules share the same module adapter board, and some of them have Bayer output only, we connect the image sensor date bus (11:0) to DM355 CCD(11:0) to maximize the data bus depth. As the result, when it is in YUV mode, its data bus is connected to 4 bits of YIN and 4 bits of CIN. That is why we can't use YUV input mode. Another reason is SOC image sensors (e.g. the VGA one) have RAW output options as well, to make use of all its bits.
What the current driver does is it config CCDC as RAW mode to right-shift input data, and store it as packed 8 bits in DDR memory. In this case, the image in DDR is in YUV format. Then you can feed it back to IPIPE for further processing if needed.
Hope that helps.
-Leon
Hi,
thanks for your reply, that help me!! :)
In the code, where does this right-shift is done, is it on an ioctl call?
I am still confuse, this wired input, dont let me set the format, i.e, if i call VIDIOC_S_FMT, it wont work, so probably standard application would break.
Am i wrong?
The shift is defined in ccdc_dm355.c, which could be overwritten by ioctl call.
It doesn't support VIDIOC_S_FMT currently, if you or someone could fix that, it will be very helpful to all others....
static struct ccdc_params_raw ccdc_hw_params_raw = {
.pix_fmt = CCDC_PIXFMT_RAW,
.frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
/*This numbers are for the mt9v113 VGA YCbCr mode. */
.win = {0,0,1280,480},
.fid_pol = CCDC_PINPOL_POSITIVE,
.vd_pol = CCDC_PINPOL_POSITIVE,
.hd_pol = CCDC_PINPOL_POSITIVE,
.image_invert_enable = 0,
.data_sz = _8BITS,
.med_filt_thres = 0,
.mfilt1 = NO_MEDIAN_FILTER1,
.mfilt2 = NO_MEDIAN_FILTER2,
.ccdc_offset = 0,
.gain = {
.r_ye = 256,
.gb_g = 256,
.gr_cy = 256,
.b_mg = 256
},
.lpf_enable = 0,
.datasft = 6, /*for EVM it should be 4 */
........
Thanks again for your reply!
And why do we have 1280, instead of 640? I also see it in vgs_num_active_pixels on mt9v113_davinci.h
The sensor is in YUV 422 mode. The format is like : Cb, Y0, Cr, Y1, Cb, Y2, Cr, Y3 .... each pixel has two bytes (such as Cb, Y0, or Cr, Y1), so the total size is 640x2.