capture from CMOS

There is documentation under

dvsdk_1_30_00_41/PSP_XX_XX_XX_XXX/docs

directory that describes how to enable the appropriate drivers in the kernel as well as some u-boot parameter settings you need to set to get this interface up and running.  I believe you can just run encodedecode demos to acpture raw data, compress, decompress and display.

Juan Gonzales said:

I believe you can just run encodedecode demos to acpture raw data, compress, decompress and display.

Thank  you for your answer!

My boot options:

setenv videomode video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=$(videostd)
setenv bootcmd 'nboot 0x80700000 0 0x400000;bootm'
setenv capture v4l2_video_capture=device:MT9T031
setenv bootargs console=ttyS0,115200n8 noinitrd rw ip=192.168.0.32:192.168.0.132:::arm:eth0:off root=/dev/nfs nfsroot=192.168.0.132:/home/kirill/nfs/busybox,nolock mem=116M $(videomode) $(capture)

My devices:

# ls -l /dev
crw-r--r--    1 root     root     254,   0 Dec  1  2008 cmem
crw-rw----    1 1000     1000     254,   0 Aug 27  2008 davinci_pwm0
crw-rw----    1 1000     1000     254,   1 Aug 27  2008 davinci_pwm1
crw-rw----    1 1000     1000     254,   2 Aug 27  2008 davinci_pwm2
crw-rw----    1 1000     1000     254,   3 Aug 27  2008 davinci_pwm3
crw-r--r--    1 root     root     250,   0 Sep  1  2008 dm350mmap
crw-r--r--    1 root     root     252,   0 Sep  1  2008 dm355_aew
crw-r--r--    1 root     root     253,   0 Sep  1  2008 dm355_af
crw-r--r--    1 root     root     254,   0 Sep  1  2008 dm355_ipipe

This is strange, but earlier, when I have worked via TVP5146, cmem hase 251 major number.

# lsmod
Module                  Size  Used by    Not tainted
dm350mmap               5204  0
cmemk                  17368  0

When I running encodedecode demo I see error:

# ./encodedecode
Encodedecode demo started.
Encodedecode Error: Failed to set video input to 0
Rszcopy: failed to open device
Encodedecode Error: Failed to create resize copy job

I have found error "Failed to set video input to 0" in demos/dm355/encodedecode/capture.c:

/* Select the video input */
    if (svideoInput == TRUE) {
        input = TVP5146_AMUX_SVIDEO;
    }
    else {
        input = TVP5146_AMUX_COMPOSITE;
    }

    if (ioctl(fd, VIDIOC_S_INPUT, &input) == -1) {
        ERR("Failed to set video input to %d\n", input);
        return FAILURE;
    }

Also I have found this error in drivers/media/davinci/davinci_vpfe.c:

case VIDIOC_S_INPUT:
        {
            int *index = (int *)arg;
            dev_dbg(vpfe_dev, "\nStart of VIDIOC_S_INPUT ioctl");
            if (device_type != TVP5146) {
                return -1;
            }
            if (*index > 1 || *index < 0) {
                ret = -EINVAL;
            }
            vpfe->tvp5146_params.amuxmode = *index;
            tvp5146_ctrl(TVP5146_SET_AMUXMODE, index);
            dev_dbg(vpfe_dev, "\nStart of VIDIOC_S_INPUT ioctl");
            break;
        }

How can I work with encodedecode demo if its code allow work only via TVP5146?

Kirill said:

How can I work with encodedecode demo if its code allow work only via TVP5146?

It seems you may have to make some modifications to the demo if it is referencing TVP5146 directly, however it should not be to complex. For the most part the capture and display drivers within Linux should be independent of what hardware they are on, in this instance the demo is not entirely portable but if you can remove the TVP5146 related code it should be usable.

Hello!

I modifying demo and succesfully get video from CMOS, but video have some strange moment:

- black/green image

- horizontale splited screen on two parts

In my opinion this can by linked with capture format.

What I need to do to get correct video?

Thank you.

Horizontal aplitted screen sounds like a video timing problem, which can also contribute to black/green iamge.  I would look at how the video window size and blanking intervals (if any) are defined in CMOS and DM355

If you can get a stable full screen image but still see black/green image, then you are likely seeing wron pixel format configuration (bad color space convertion).  But I would correct the horizontal split image first as this can lead to weird colors.

Kirill said:

- black/green image

Just a thought, if I remember correctly you will get a neon green and black with some pink looking output if your Y values are swapped with the Cb/Cr values, so if you have a buffer of what is meant to be YCbCr 4:2:2 interleaved data you might end up with the correct color if you offset the buffer by a byte.

Hello!

In file drivers/media/video/davinci/davinci_vpfe.c I have found this:

fmt->index = index;
            if (device_type == TVP5146) {
                if (index == 0) {
                    /* only yuv4:2:2 format is supported
                     * at this point
                     */
                    fmt->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
                    strcpy(fmt->description,
                           "YCbCr4:2:2 Interleaved UYUV");
                    fmt->pixelformat = V4L2_PIX_FMT_UYVY;
                } else if (index == 1) {
                    fmt->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
                    strcpy(fmt->description,
                           "YCbCr4:2:2 Interleaved YUYV");
                    fmt->pixelformat = V4L2_PIX_FMT_YUYV;
                } else {
                    ret = -EINVAL;
                }
            } else if (device_type == MT9T001
                   || device_type == MT9T031) {
                if (index == 0) {
                    /* only Bayer Raw Mode format is
                     * supported at this point
                     */
                    fmt->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
                    strcpy(fmt->description,
                           "Raw Mode -Bayer Pattern GrRBGb");
                    fmt->pixelformat = V4L2_PIX_FMT_SBGGR8;
                  }

Will the demo work with Raw Mode -Bayer Pattern GrRBGb?

To run demo I have to disable many chechks of the TVP5146 and this facts points to decision that demo works only via TVP5146.

Am I right?

I believe "VPFE_CMD_CONFIG_CCDC_RAW" ioctl is required for RAW capture.  Please see the LSP 1.20 DaVinci Linux CCDC Driver User Guide (SPRUEP7) included in the DVSDK (under PSP_XX_XX_XX_XXX folder) for more details.

Also, you can find reference source code under

dvsdk_1_30_00_41/PSP_01_20_00_014/examples/dm355/ipipe

I hope this helps.

[edit] Forgot to mention that "V4L2_PIX_FMT_SBGGR8" does not set the required pixel format for RAW capture.  Use VPFE_CMD_CONFIG_CCDC_RAW ioctl instead.

Hello!

I have found some strange facts:

demo/dm355/encodedecode/capture.c:

fmt.type                = V4L2_BUF_TYPE_VIDEO_CAPTURE;
fmt.fmt.pix.width       = D1_WIDTH;
fmt.fmt.pix.height      = D1_HEIGHT;
fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_UYVY;
fmt.fmt.pix.field       = V4L2_FIELD_INTERLACED;

kernel/drivers/media/davinci/davinci_vpfe.c:

else if (device_type == MT9T001
                   || device_type == MT9T031) {
                if (index == 0) {
                    /* only Bayer Raw Mode format is
                     * supported at this point
                     */
                    fmt->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
                    strcpy(fmt->description,
                           "Raw Mode -Bayer Pattern GrRBGb");
                    fmt->pixelformat = V4L2_PIX_FMT_SBGGR8;

Please comment difference between pixel format in demo and kernel drivers.

The demos assume you are using TVP5146 by default (hence V4L2_PIX_FMT_UYVY); when you need to use MT9XXX instead, you need to refer to the example on iotcl I mentioned in my previous post (e.g. VPFE_CMD_CONFIG_CCDC_RAW); encodedecode does not support CCD sensors.

Juan Gonzales said:

Also, you can find reference source code under

dvsdk_1_30_00_41/PSP_01_20_00_014/examples/dm355/ipipe

I hope this helps.

Hello!

I have successfully made ipipe demo.

When I run demo with TVP5146 I get error:

# ./ipipe_720p_example
initializing capture device
Open Done
vpfe vpfe.1:
 Validation pass
Calling confiUnable to handle kernel NULL pointer dereference at virtual address 00000000
gCCDCraw()
pgd = c511c000
[00000000] *pgd=85102031, *pte=00000000, *ppte=00000000
Internal error: Oops: 0 [#1]
Modules linked in: dm350mmap cmemk
CPU: 0
PC is at 0x0
LR is at vpfe_doioctl+0x2388/0x23fc
pc : [<00000000>]    lr : [<c0193fb8>]    Not tainted
sp : c0f7fde0  ip : 60000013  fp : c0f7fe4c
r10: 00000000  r9 : c0afe1b8  r8 : c0f7fe58
r7 : c0fca7c0  r6 : c0f7fe58  r5 : c035f908  r4 : 803456c6
r3 : 803456c6  r2 : 00000000  r1 : c0f7fe58  r0 : 00000002
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F  Table: 8511C000  DAC: 00000015
Process ipipe_720p_exam (pid: 837, stack limit = 0xc0f7e1a0)
Stack: (0xc0f7fde0 to 0xc0f80000)
fde0: c0034780 c00363b0 c5154a04 befff224 00000000 00000000 00000000 00000000
fe00: 00000000 fffffff2 00000000 c0afe1b8 c5154000 c0f7ff04 000009e0 c0f7fe34
fe20: c01885b4 00008034 803456c6 befffc48 fffffff2 c0f7fe58 c0afe1b8 00000000
fe40: c0f7ff04 c0f7fe50 c01885f0 c0191c40 00000000 c0032bc0 c0f7fe9c c0f7fe68
fe60: c0f7e000 a0000013 c0f7fe84 c0f7fe78 c0169388 c016cbac c0f7fe9c c0f7fe88
fe80: c01693bc c0169340 00000003 00000003 c0f7ff0c c0f7fea0 c015a2a4 c00681cc
fea0: 00000000 c0f7e000 60000093 a0000013 00000019 40018019 00000000 c0be8bec
fec0: c0f7feec c0f7fed0 c004c3cc c004c31c 00000000 00100100 c0f7e000 c0032bc0
fee0: c0afe1b8 803456c6 c0032bc0 befffc48 c0f7e000 c0191c30 c0f7ff34 c0f7ff08
ff00: c0194058 c01884a4 c0191c30 c0153a3c c0032bc0 ffffffe7 803456c6 befffc48
ff20: c00352f4 00900036 c0f7ff54 c0f7ff38 c00a50d4 c019403c c0032bc0 befffc48
ff40: 00000000 00000003 c0f7ff7c c0f7ff58 c00a53e8 c00a5068 00000000 00000000
ff60: fffffff7 befffc48 803456c6 c0032bc0 c0f7ffa4 c0f7ff80 c00a544c c00a50f8
ff80: c0090734 00000000 ffffeb90 4001ee10 0000ab58 00000036 00000000 c0f7ffa8
ffa0: c0034b60 c00a5418 ffffeb90 4001ee10 00000003 803456c6 befffc48 00014264
ffc0: ffffeb90 4001ee10 0000ab58 00000000 00000000 00000000 40129000 befffc94
ffe0: 00014114 beffe810 0000a774 400c9294 00000010 00000003 e1a05001 e3a00001
Backtrace:
[<c0191c30>] (vpfe_doioctl+0x0/0x23fc) from [<c01885f0>] (video_usercopy+0x15c/0x21c)
[<c0188494>] (video_usercopy+0x0/0x21c) from [<c0194058>] (vpfe_ioctl+0x2c/0x84)
[<c019402c>] (vpfe_ioctl+0x0/0x84) from [<c00a50d4>] (do_ioctl+0x7c/0x90)
[<c00a5058>] (do_ioctl+0x0/0x90) from [<c00a53e8>] (vfs_ioctl+0x300/0x320)
 r7 = 00000003  r6 = 00000000  r5 = BEFFFC48  r4 = C0032BC0
[<c00a50e8>] (vfs_ioctl+0x0/0x320) from [<c00a544c>] (sys_ioctl+0x44/0x68)
 r7 = C0032BC0  r6 = 803456C6  r5 = BEFFFC48  r4 = FFFFFFF7
[<c00a5408>] (sys_ioctl+0x0/0x68) from [<c0034b60>] (ret_fast_syscall+0x0/0x2c)
 r7 = 00000036  r6 = 0000AB58  r5 = 4001EE10  r4 = FFFFEB90
Code: bad PC value.
 Segmentation fault

When I run demo with CMOS-matrix I get error:

# ./ipipe_480p_example
initializing capture device
Open Done
vpfe vpfe.1:
 Validation pass
mt9t001_ctrle
Calling confimt9t001_getparams
gCCDCraw()
mt9t001_getformat
the col size is : 12mt9t001_ctrl
99
configCCDmt9t001_setstd
Craw Done
settimt9t001_setformat
ng data format
write reg = 0x3, data[1] = 0x3, data[2] = 0xcf
SetDataFormat:sewrite reg = 0x4, data[1] = 0x5, data[2] = 0xbf
write reg = 0x5, data[1] = 0x1, data[2] = 0x5e
write reg = 0x6, data[1] = 0x1, data[2] = 0x5e
write reg = 0x9, data[1] = 0x3, data[2] = 0x82
write reg = 0x8, data[1] = 0x0, data[2] = 0x0
write reg = 0x22, data[1] = 0x0, data[2] = 0x11
write reg = 0x23, data[1] = 0x0, data[2] = 0x11
write reg = 0x49, data[1] = 0x0, data[2] = 0x40
 ERROR: i2c readback failed, val = 0x40, readval = 0x0, reg = 0x49
write reg = 0x1, data[1] = 0x0, data[2] = 0x0
write reg = 0x2, data[1] = 0x0, data[2] = 0x0
write reg = 0xa, data[1] = 0x80, data[2] = 0x0
 ERROR: i2c readback failed, val = 0x8000, readval = 0x8001, reg = 0xa
write reg = 0x7, data[1] = 0x0, data[2] = 0x2
mt9t001_readregs
S_STD Done
GetSTD Done WITH std = 15
SetDataFormat:requesting width:720 height:480
S_FMT Done
initializing capture buffers
REQBUF Done
QUERYBUF Done
QUERYBUF Done
QUERYBUF Doregw ccdc_dm355 val = 0x0, port = 0x0
ne
IPIPE_SET_PARAM fail, null parametr

Line with write reg from ccdc kernel driver.

I have found IPIPE_SET_PARAM fail in the dvsdk/examples/dm355/ipipe/ipipe_config.c:

static void config_ipipe(ipipe_dpaths_fmt_t data_fmt, int i_width, int i_height,
        int o_width, int o_height)
{
    int ret;
    ret = ioctl(ipipefd, IPIPE_SET_PARAM, NULL);
        if (ret < 0) {
            printf("IPIPE_SET_PARAM fail, null parametr\n");
            exit(0);
    }
    ret = ioctl(ipipefd, IPIPE_GET_PARAM, &params);
        if (ret < 0) {
                printf("IPIPE_GET_PARAM fail\n");
                exit(0);
        }

I have found this ioctl in the kernel/drivers/media/video/davinci/dm355_ipipe.c:

case IPIPE_SET_PARAM:
        /*set the parametres */

        down_interruptible(&(device->sem));
        /*default parameters */
        if ((void *)arg == NULL) {
            params = &param_def;
            dev_dbg(ipipe_dev, "NULL parameters.\n");
        } else {
            /* copy the parameters to the configuration */
            if (copy_from_user
                (params, (struct ipipe_params *)arg,
                 sizeof(struct ipipe_params))) {
                /* if it fails return error */
                up(&(device->sem));
                printk("dm355_ipipe: error IPIPE_SET_PARAM - copy_from_user\n");
                return -EFAULT;
            }
        }

What can cause this problems?

Is there any demos/examples in SDK to work with CMOS-matrix?

1) I believe IPIPE demo assumes MICRON CCD sensor is present and pixel format is raw-bayer patter; this probrably explains why you get errors when trying to run it with TVP5146.  Unless you have to correct Micron sensor daughter card, I would expect errors when you try to use CMOS sensor option as well.

2) The demos (encode, decode, encodedecode) work with the TVP5146; unfortunately, I cannot think of any demos other than ipipe which use CMOS sensor interface (hence my suggestion to use ipipe); however, when user confogures linux kernel to use cmos sensor (via u-boot parameters, hence cannot be changed on the fly and requires reboot), you will see errors if correct cmos sensor is not present.  Regardless, ipipe is probrably still the best place to start from, but it will not run without some modifications at the kernel level (and probrably application level as well).