This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DMAI Capture_Create doesn't work with MT9P031 camera module

Other Parts Discussed in Thread: TMS320DM368, TVP5146

I'm using the LeopardBoard DM368 with the dvsdk-4_02_00_06 and the RidgeRun SDK to prototype a capture application using the MT9P031 camera module (the actual camera module I intend to use is is the AR03331 but it isn't ready yet so I'm learning with the MT9P031)

I thought perhaps I should use the DMAI API's to make my code portable, etc, etc. 

However I've discovered that the Capture_create() api doesn't work with this camera module. Specifically it doesn't work because Capture_create() in Capture.c attempts to set the input to a video standard via VIDIOC_S_STD and the camera driver doesn't support any video standards. I'm not sure why it doesn't support any standards, probably because it's not a standard analog video device I don't know.

All of this predefined video standard stuff seems rather short sighted to me so I'm a little confused on what to do. So my question is should I just abandon the DMAI Capture_create() api for these types of camera devices or is there something I'm missing, any advice would be appreciated. 

Thanks, 

Matt Schuckmann
matt.schuckmann@imoveinc.com 

  • So I figured I'd come back and share what I learned. 

    Create_Capture() wants to use the S_STD IOCT to set the device to a known standard something like NTSC 30FPS, PAL 25 FPS, 1080I 30 FPS, 1080P 60 FPS, etc there are bunch of them but they are all discrete values that are tied to analog, broadcast or DVD, BluRay video standards for a camera module like the MT9P031 many of these could apply but the module can do much much more, specifically it could do full 5mpix capture at 1 FPS if you wanted and there is no standard for that. 

    To complicate things further whomever implemented the MT9P031 driver didn't setup it up to work with the S_STD IOCT, they could have but they didn't, I can kind of sort of understand why they might have done this but it would have been nice for them to do it as it isn't too hard. I figured out how do this by setting the v4l2_input.std field for the mt9p031_inputs structure in {kernel}/arch/arm/mach-davinci/board-dm368-leopard.c 

    /* MZS MOD added MT9P031 std bit filed and set it in the struct */
    #define V4L2_STD_625P_50|V4L2_STD_720P_30\
    |V4L2_STD_720P_50|V4L2_STD_720P_60\
    |V4L2_STD_1080I_30|V4L2_STD_1080I_50\
    |V4L2_STD_1080I_60|V4L2_STD_1080P_30\
    |V4L2_STD_1080P_50|V4L2_STD_1080P_60)
    /* Input available at the mt9p031 */
    static struct v4l2_input mt9p031_inputs[] = {
    {
    .index = 0,
    .name = "Camera",
    .type = V4L2_INPUT_TYPE_CAMERA,
    .std = V4L2_STD_MT9P031_STD_ALL,
    }
    };
    This allows the S_STD IOCT get a little further, however there is another problem the vpfe_capture implementation of the S_STD IOCT calls vpfe_config_image_format() which
    attempts to call the g_fmt operation handler on the sub-device (in this case the MT9P031 driver), however there this driver doesn't implement the g_fmt operation which would be ok
    and the function should fall back on some defaults but the logic here is very bad and it ends up trying to setup the ccdc with an uninitialized stuct and everything fails.
     (see this thread  http://e2e.ti.com/support/embedded/linux/f/354/t/182860.aspx)
    To fix this I eventually ended up adding this line just before calling the g_fmt operation so that the defaults will get used if g_fmt fails or isn't implemented. 
     sd_fmt = vpfe_dev->fmt;
    After this the DMAI Create_Capture() function finally works and Capture_get() and Capture_put() work but that's as far as I got because I realized that this interface just isn't going
    to be flexible for me and I'd have to write the capture part of my application using IOCTL calls.
    I hope this info helps someone else down the road. 
    Matt S. 
     
  • Hi Matt,
    I see your mt9p031 works after your fix, could you share some information to me ?

    After we got Mouser's DM368 LEOPARDBOARD, we setup dvsdk_dm368-evm_4_02_00_06_setuplinux.bin as it told, and start to build kernel as TMS320DM368_Software_Developers_Guide.pdf said.

    (I only plus "Usb Video Capturing" configured as enabled based on .config which is created from build on DVSDK default environment.)

    But from kernel logs, it seems mt9p031 module is init from kernel bootup but it is not probed as we think.

    So i add some printk logs in kernel as below git diff told:
    -----------------------------------------------------------------------
    davinci@ubuntu:~/dm368/dvsdk_dm368_4_02_00_06$ ls -l psp/linux-2.6.32.17-psp03.01.01.39/drivers/media/video/mt9p031.c 
    -rw-r--r-- 1 davinci davinci 25089 2012-04-15 21:46 psp/linux-2.6.32.17-psp03.01.01.39/drivers/media/video/mt9p031.c
    davinci@ubuntu:~/dm368/dvsdk_dm368_4_02_00_06$ git diff psp/linux-2.6.32.17-psp03.01.01.39/drivers/media/video/mt9p031.c
    diff --git a/dvsdk_dm368_4_02_00_06/psp/linux-2.6.32.17-psp03.01.01.39/drivers/media/video/mt9p03
    index 66b5e54..df619c4 100644
    -----------------------------------------------------------------------
    --- a/dvsdk_dm368_4_02_00_06/psp/linux-2.6.32.17-psp03.01.01.39/drivers/media/video/mt9p031.c
    +++ b/dvsdk_dm368_4_02_00_06/psp/linux-2.6.32.17-psp03.01.01.39/drivers/media/video/mt9p031.c
    @@ -862,6 +862,7 @@ static int mt9p031_probe(struct i2c_client *client,
            int pclk_pol;
            int ret;
     
    +        printk(KERN_INFO "start: mt9p031_probe");
            if (!i2c_check_functionality(client->adapter,
                                         I2C_FUNC_SMBUS_WORD_DATA)) {
                    dev_warn(&client->dev,
    @@ -910,9 +911,11 @@ static int mt9p031_probe(struct i2c_client *client,
                            MT9P031_PIXEL_CLOCK_CONTROL, 0x8000);
     
            v4l2_info(sd, "%s decoder driver registered !!\n", sd->name);
    +        printk(KERN_INFO "mt9p031_probe >>");
            return 0;
     
     clean:
    +        printk(KERN_ERR "fail - mt9p031_probe >>");
            kfree(mt9p031);
            return ret;
     }
    @@ -945,6 +948,7 @@ static struct i2c_driver mt9p031_i2c_driver = {
     
     static int __init mt9p031_mod_init(void)
     {
    +        printk(KERN_INFO "mt9p031_mod_init >>");
            return i2c_add_driver(&mt9p031_i2c_driver);
     }
    -----------------------------------------------------------------------

    From kernel bootup logs, i can see "mt9p031_mod_init >>", but there is no logs for "start: mt9p031_probe".

    So i guess my kernel config file is not correct.(default build's kernel config is not correct ?)

    Could you help to give me some tips for kernel config file which can detect and probe MT9P031 camera well in Mouser's DM368 LEOPARDBOARD ?
  • I've been using the RidgeRun SDK which handles the kernel config file for me you and I haven't had any problems with it finding the MT9p031. 

    You may already know this but this may help, you need to have the "cpfe_capture.interface=1" in the kernel boot arguments, this lets it know that you are dealing with the MT9P031 instead of TVP5146, apparently the 2 share the same I2C address. There are some comments about this in linux-kernel/drivers/media/video/davinci/vpfe_capture.c

    I put a copy of what I think is my kernel config file ".config" here http://pastebin.com/7iFFbSpy

    I took the time to get KGDB -> GDB debugging working with my board and it has been invaluable for figuring this stuff out. 

    I hope this helps. 

    Matt S.