ADV7180 and IMX6 - does NTSC work?

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

ADV7180 and IMX6 - does NTSC work?

4,982 Views
simonr99
Contributor II

I have an IMX6Q to which is attached an ADV7180 using 8 bit BT.656. PAL CVBS input works flawlessly using either:

gst-launch tvsrc device="/dev/video1" ! imxv4l2sink

or using /unit_tests/mxc_v4l2_tvin.out

But I cannot get NTSC CVBS to work. The picture rolls as though the IMX6 cannot sync to the incoming video. I've followed the many threads on this forum but have not found a solution that works.

I've tested multiple sources of NTSC video, the 7180 has happily detected the NTSC format, I've tried different values of active_top. I've tried connecting up the hardware HSync and VSync, although they don't appear to be used with the working PAL setup.

Questions:

  1. Does NXP/Freescale test with a PAL input or NTSC input when they test their reference boards with mxc_v4l2_tvin.out?
  2. Is the IMX6 IPU expecting BT.656-3 or BT656-4? A change to the V bit in the SAV/EAV codes happened between these two revisions of the standard, and this would only affect NTSC. (The 7180 can be configured for either.)
  3. I connected the hardware HSync/VSync signals, but these aren't currently being used (I can disconnect them and PAL still works). Can I force the IMX6 to use these? I tried p->u.bt656.bt_sync_correct = 1; in adv7180.c but it still isn't depending on the hardware sync lines.
  4.  What is the impact of the different CSI clock modes: IPU_CSI_CLK_MODE_CCIR656_INTERLACED, IPU_CSI_CLK_MODE_GATED_CLK etc. Do these dictate use of the hardware H/V sync lines?

I'm running a Yocto build of Kernel 3.14.60.

My device tree pin mux for this device is:

MX6QDL_PAD_EIM_A24__IPU2_CSI1_DATA19 0x10
MX6QDL_PAD_EIM_A23__IPU2_CSI1_DATA18 0x10
MX6QDL_PAD_EIM_A22__IPU2_CSI1_DATA17 0x10
MX6QDL_PAD_EIM_A21__IPU2_CSI1_DATA16 0x10
MX6QDL_PAD_EIM_A20__IPU2_CSI1_DATA15 0x10
MX6QDL_PAD_EIM_A19__IPU2_CSI1_DATA14 0x10
MX6QDL_PAD_EIM_A18__IPU2_CSI1_DATA13 0x10
MX6QDL_PAD_EIM_A17__IPU2_CSI1_DATA12 0x10
MX6QDL_PAD_EIM_DA12__IPU2_CSI1_VSYNC 0x10
MX6QDL_PAD_EIM_DA11__IPU2_CSI1_HSYNC 0x10
MX6QDL_PAD_EIM_D17__IPU2_CSI1_PIXCLK 0x10

Thanks 

Simon

Labels (3)
8 Replies

3,260 Views
jamescovey-crum
Contributor II

I appreciate this is an old thread, but in case someone stumbles across it.

We're using the 3.14.79 kernel at GitHub - SolidRun/linux-fslc: Linux kernel source tree although I believe the adv7180.c driver is the same as the fslc kernel.

PAL was okay, but NTSC rolled - the same issue you described. 

The solution was to add a missing case for V4L2_BUF_TYPE_SENSOR in the ioctl_g_fmt_cap() function in adv7180.c...

/*!
 * ioctl_g_fmt_cap - V4L2 sensor interface handler for ioctl_g_fmt_cap
 * @s: pointer to standard V4L2 device structure
 * @f: pointer to standard V4L2 v4l2_format structure
 *
 * Returns the sensor's current pixel format in the v4l2_format
 * parameter.
 */
static int ioctl_g_fmt_cap(struct v4l2_int_device *s, struct v4l2_format *f)
{
     struct sensor *sensor = s->priv;

     dev_dbg(&adv7180_data.sen.i2c_client->dev, "adv7180:ioctl_g_fmt_cap\n");

     switch (f->type) {
     case V4L2_BUF_TYPE_VIDEO_CAPTURE:
          pr_debug("   Returning size of %dx%d\n",
                sensor->sen.pix.width, sensor->sen.pix.height);
          f->fmt.pix = sensor->sen.pix;
          break;

     case V4L2_BUF_TYPE_SENSOR:
          pr_debug("%s: left=%d, top=%d, %dx%d\n", __func__,
               sensor->sen.spix.left, sensor->sen.spix.top,
               sensor->sen.spix.swidth, sensor->sen.spix.sheight);
          f->fmt.spix = sensor->sen.spix;
          break;

     case V4L2_BUF_TYPE_PRIVATE: {
          v4l2_std_id std;
          adv7180_get_std(&std);
          f->fmt.pix.pixelformat = (u32)std;
          }
          break;

     default:
          f->fmt.pix = sensor->sen.pix;
          break;
     }

     return 0;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The I2C settings for the adv7180 remained the same (as in I didn't need to do the changes described in this thread).  In our case VSYNC and HSYNC are not connected (so seems to be correctly used from those in the data stream).

And also a change to mxc_v4l2_capture.c (.active_top should be 13 in the NTSC settings)...

/*!
 * Description of video formats supported.
 *
 *  PAL: raw=720x625, active=720x576.
 *  NTSC: raw=720x525, active=720x480.
 */
static video_fmt_t video_fmts[] = {
     {               /*! NTSC */
      .v4l2_id = V4L2_STD_NTSC,
      .name = "NTSC",
      .raw_width = 720,          /* SENS_FRM_WIDTH */
      .raw_height = 525,          /* SENS_FRM_HEIGHT */
      .active_width = 720,          /* ACT_FRM_WIDTH */
      .active_height = 480,          /* ACT_FRM_HEIGHT */
      .active_top = 13,          /* FIX - MODIFICATION from 0 */
      .active_left = 0,
      },
     {               /*! (B, G, H, I, N) PAL */
      .v4l2_id = V4L2_STD_PAL,
      .name = "PAL",
      .raw_width = 720,
      .raw_height = 625,
      .active_width = 720,
      .active_height = 576,
      .active_top = 0,
      .active_left = 0,
      },
     {               /*! Unlocked standard */
      .v4l2_id = V4L2_STD_ALL,
      .name = "Autodetect",
      .raw_width = 720,
      .raw_height = 625,
      .active_width = 720,
      .active_height = 576,
      .active_top = 0,
      .active_left = 0,
      },
};‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

JamesCC

0 Kudos
Reply

3,260 Views
dh29
Contributor IV

I am using an i.MX7 with an ADV7280M to capture PAL & NTSC camera feeds. It seems that NTSC causes more problems than PAL !

The ADV7280M is connected via a CSI MIPI interface on the i.MX7. As I understand it, the CSI MIPI deals with the syncs (SAV/EAV). I am not sure if the MIPI also throws away the blanking lines??? and only passes forward the ACTIVE image??? I should add that the ADV7280M has built-in interpolation, so it is outputting PROGRESSIVE (thus avoiding any interlacing problems).

PAL is working fine. I have a image size of 720x576 configured.

BUT, with NTSC I get a diagonally scrolling image. The image itself is clearly there, just not locked. The only thing I changed is the image size to 720x480.

My Kernel is different from the above posts (Linux v4.9.11) and the i.MX7 differs from the i.MX6 in that it does not have an IPU. As such, it is not obvious to me how I might try and apply the above suggested fixes.

Most of the solutions for 'scrolling NTSC' seems to involve setting the ACTIVE TOP frame value. Can anybody explain WHY setting ACTIVE TOP stops the scrolling?  I am not sure if this is relevant to my issue, but I would like to understand why as it might help me diagnose my issue.

0 Kudos
Reply

3,058 Views
abeeshmp_dct
Contributor II

hi , 

You got any solutions to this issue? I m facing similiar issue for NTSC, PAL is woking fine.

If you have any solution please share.

0 Kudos
Reply

3,260 Views
junzhang8421
Contributor II

After all, I have tried setting ADV7180 register for many times, now IMX6 can show ADV7180 both PAL and NTSC video without any rolling.  my seting is shown as below:

adv7180_write_reg(0x0f, 0x80);
msleep(300);


adv7180_write_reg(0x00, 0x00);
adv7180_write_reg(0x04, 0x45);
adv7180_write_reg(0x17, 0x01);
adv7180_write_reg(0x31, 0x12);

adv7180_write_reg(0x34, 0x00);
adv7180_write_reg(0x35, 0x02);
adv7180_write_reg(0x36, 0x00);

adv7180_write_reg(0x3d, 0xb2);
adv7180_write_reg(0x3e, 0x64);
adv7180_write_reg(0x3f, 0xe4);

adv7180_write_reg(0xe8, 0xfc);
adv7180_write_reg(0xe9, 0x60);
adv7180_write_reg(0xea, 0x60);

adv7180_write_reg(0x0e, 0x80);
adv7180_write_reg(0x55, 0x81);
adv7180_write_reg(0x0e, 0x00);

0 Kudos
Reply

3,260 Views
amirlk
Contributor I

Hi Simon,

Was facing the exact same problem you have, with the exact same kernel you are using,

Was able to fix it.

If you haven't figured it out yet I would be happy to share my solution for this problem

Just let me know in a reply post ( I dont want to waste time If you already got this solved )

Amir

0 Kudos
Reply

3,260 Views
simonr99
Contributor II

Amir

Thanks for your reply. I have fixed the issue, by going back over the patches I applied from the Gateworks kernel drivers, and ensuring I had relevant changes in mxc_v4l2_capture.c, ipu_capture.c and adv7180.c

0 Kudos
Reply

3,260 Views
junzhang8421
Contributor II

Dear Simon. 

 Please share your mxc_v4l2_capture.c, ipu_capture.c and adv7180.c to us, thank you in advance!

0 Kudos
Reply

3,260 Views
igorpadykov
NXP Employee
NXP Employee

Hi Simon

please create service request to obtain additional document

describing these operations.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply