Blurry image with CSI1 overlay

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Blurry image with CSI1 overlay

1,883 Views
henri_bragge
Contributor II

I have two TVP5150 decoders + PAL cameras attached to i.MX53 CSI0/1 interfaces. When I use "mxc_v4l2_overlay.out" or "csi_v4l2_overlay.out" unit test to overlay video, I get a very nice and sharp (although interlaced) picture from CSI0 through CSI->IC path. But when I attach the TVP driver to the second chip and change the hardcoded csi to "csi = 1" in the mxc_v4l2_capture driver, then I get very blurry and incomprehensible image. It changes when I move my hand in front of the camera, so some information data goes through.

 

When I use CSI->MEM path (with mxc_v4l2_tvin.out), both CSI0 and CSI1 work fine.

 

My guess is that some IPU parameters are set wrong in "ipu_prp_vf_sdc.c" or "ipu_prp_vf_sdc_bg.c", but I have no idea what it could be. The blur effect is similar when using either of these modules. No hardcoded CSI settings catches the eye when looking at the code or anything obvious. I guess it could be a clock problem too, but it's interesting that it only happens with CSI->IC path.

 

I attached IPU register dumps when using CSI0 and CSI1. To me it didn't reveal any problems, but I don't understand much about processing flows and that stuff anyway.

Original Attachment has been moved to: overlay-csi0.txt.zip

Original Attachment has been moved to: overlay-csi1.txt.zip

Labels (4)
0 Kudos
2 Replies

679 Views
henri_bragge
Contributor II

For anyone interested, I attached a patch that adds dual CSI support and TVP5150 support for kernel 2.6.35.3 with latest Freescale patches (from http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_11.09.01). All credit for TVP5150 part goes to Adam Sutton, though I have made some little modifications.

Apparently there is a bug that sometimes causes a crash when using gstreamer, but I'm not using that so I have not bothered to debug it much. Feel free to point out any bugs you notice in this patch.

After applying this patch, two camera and v4l2 input devices need to be defined in arch/arm/mach-mx5/<board>.c. For example my platform description code looks like this:

static struct mxc_camera_platform_data camera0_data = {
        .csi = 0,
};

static struct mxc_camera_platform_data camera1_data = {
        .csi = 1,
};

static struct i2c_board_info mxc_i2c0_board_info[] __initdata = {
          {
          .type = "tvp5150",
          .addr = 0x5c,
          .platform_data = (void *)&camera0_data,
          },
          {
          .type = "tvp5150",
          .addr = 0x5d,
          .platform_data = (void *)&camera1_data,
          },
};
static void __init mxc_board_init(void)
{
...
          i2c_register_board_info(0, mxc_i2c0_board_info,
                                       ARRAY_SIZE(mxc_i2c0_board_info));
          mxc_register_device(&mxc_v4l2out_device, NULL);
          mxc_register_device(&mxc_v4l2_device, NULL);
          mxc_register_device(&mxc_v4l2_device1, NULL);
          ...
}

In devices.c:
struct platform_device mxc_v4l2_device = {
          .name = "mxc_v4l2_capture",
          .id = 0,
};

struct platform_device mxc_v4l2_device1 = {
          .name = "mxc_v4l2_capture",
          .id = 1,
};

struct platform_device mxc_v4l2out_device = {
          .name = "mxc_v4l2_output",
          .id = 0,
};

The camera selection is based on using a device node either with minor number 1 (= csi0) or 2 (= csi1), with major number 81 (video4linux).

0 Kudos

679 Views
henri_bragge
Contributor II

I have been debugging this and nothing seems to indicate a HW problem (I have measured clocks and other signals on TVP5150, they are the same on both chips).

If anyone has seen CSI1 overlay working or not working, or has any other relevant information, please provide help. My main concern is still if the "ipu_prp_vf_sdc.c", "ipu_capture.c" or "ipu_common.c" drivers are doing the right thing or not (concerning the CSI independence), so it would very helpful to know that someone has actually seen them working. I'm using Freescale patched version of kernel 2.6.35.3.

0 Kudos