IMX6Q Device Tree Binding for ADV7343 Encoder

[tengri]

Hello all,

We intend to use ADV7343 video encoder with IMX6Q (specifically IMX6Q Sabrelite) parallel RGB interface (DISP_DAT). I need to figure out few things on device tree binding and how to adapt it to this encoder. I am using BD Linux Kernel : boundary-imx_3.14.52_1.1.0_ga and the corresponding dts file has the notations of for adv7180 device :-

pinctrl_i2c3: i2c3grp {
	fsl,pins = <
	MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
	MX6QDL_PAD_GPIO_16__I2C3_SDA 0x4001b8b1
	#define GPIRQ_I2C3_J7 <&gpio1 9 IRQ_TYPE_EDGE_FALLING>
	#define GP_I2C3_J7 <&gpio1 9 GPIO_ACTIVE_LOW>
	MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0 /* I2C3 J7 interrupt */
	>;
	};
	pinctrl_i2c3_adv7180_gpios: i2c3-adv7180_gpiosgrp {
	fsl,pins = <
	/* No data enable pin, make sure it is not selected */
	MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x0b0b1
	#define GP_ADV7180_PWN <&gpio3 13 GPIO_ACTIVE_LOW>
	MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x0b0b0
	#define GP_ADV7180_RESET <&gpio3 14 GPIO_ACTIVE_LOW>
	MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x030b0
	#define GPIRQ_ADV7180 <&gpio5 0 IRQ_TYPE_LEVEL_LOW>
	MX6QDL_PAD_EIM_WAIT__GPIO5_IO00 0x1b0b0
	>;
	};

Can some one explain why we have two such nodes for this chip ? Has anyone done this for adv7343 chip ? 

Thanks

[tengri]

Hi, so I am trying to get the lcd signals directly to RGB port. The configuration settings are given below :

These are my dts information ---->

ipu1 = "/soc/ipu@02800000";
fb_hdmi = "/fb@0";
fb_lcd = "/fb@2";
fb_lvds = "/fb@1";
lcd = "/lcd@0";
ldb = "/soc/aips-bus@02000000/ldb@020e0008";
mxcfb0 = "/fb@0";
mxcfb1 = "/fb@1";
mxcfb2 = "/fb@2";

fb_lcd: fb@2 {
   compatible = "fsl,mxc_sdc_fb";
   disp_dev = "lcd";
   interface_pix_fmt = "RGB24";
   default_bpp = <16>;
   int_clk = <0>;
   late_init = <0>;
   status = "disabled";
};

lcd: lcd@0 {
   compatible = "fsl,lcd";
   ipu_id = <0>;
   disp_id = <0>;
   default_ifmt = "RGB24";
   pinctrl-names = "default";
   pinctrl-0 = <&pinctrl_lcd0>;  //having RGB DISP pins
   status = "okay";
};

And mxc_lcd infor ----> 

static struct fb_videomode lcdif_modedb[] = {
{
/* 800x480 @ 57 Hz , pixel clk @ 27MHz */
"CLAA-WVGA", 57, 800, 480, 37037, 40, 60, 10, 10, 20, 10,
FB_SYNC_CLK_LAT_FALL,
FB_VMODE_NONINTERLACED,
0,},

I used following Uboot command to pass the env information :-

=> setenv mmcargs setenv bootargs console=${console},${baudrate} root=${mmcroot} fbmem=24M video=mxcfb2:dev=lcd,CLAA-WVGA,if=RGB24,bpp=32 

=> saveenv

=> reset

But there is no signal present at pixel clock output, nor DRDY. Does the RGB port have an auto-detection mechanism for lcd mode ? But as I mentioned at the beginning, the RGB port signals are devoted for encoder chip. My Uboot terminal output at boot is attached herewith. 

Thank You

[qiang_li-mpu_se]

On NXP iMX6 SabreSD board:

video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565,bpp=32

In device tree file "arch\arm\boot\dts\imx6qdl-sabresd.dtsi", it is on IPU0 DI0 since the display PINs are on this interface:

 lcd@0 {
  compatible = "fsl,lcd";
  ipu_id = <0>;
  disp_id = <0>;
  default_ifmt = "RGB565";
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_ipu1>;
  status = "okay";
 };

  pinctrl_ipu1: ipu1grp {
   fsl,pins = <
    MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
    MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15       0x10
    MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02        0x10
    MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03        0x10
    MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04        0x80000000
    MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00   0x10
    MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01   0x10
    MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02   0x10
    MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03   0x10
    MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04   0x10
    MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05   0x10
    MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06   0x10
    MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07   0x10
    MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08   0x10
    MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09   0x10
    MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10  0x10
    MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11  0x10
    MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12  0x10
    MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13  0x10
    MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14  0x10
    MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15  0x10
    MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16  0x10
    MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17  0x10
    MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18  0x10
    MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19  0x10
    MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20  0x10
    MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21  0x10
    MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22  0x10
    MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23  0x10
   >;
  };

[tengri]

Exactly Qiang_FSL‌, sorry I missed that part in my previous comment. pincntrl looks like this (but having a different grp name). And I also included MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04        0x80000000 to the grp :

pinctrl_lcd0: lcd0grp {
fsl,pins = <
MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x10
MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10
MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10
MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x10
MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x10
MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x10
MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x10
MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x10
MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x10
MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x10
MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x10
MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x10
MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x10
MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x10
MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x10
MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x10
MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x10
MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x10
MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x10
MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x10
MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x10
MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x10
MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x10
MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x10
MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x10
MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x10
>;
}; 

and changed lcd@ as follows (from original sabrelite dts/dtsi and for that particular display the format is set to RGB666)

lcd: lcd@0 {
   compatible = "fsl,lcd";
   ipu_id = <0>;
   disp_id = <0>;
   default_ifmt = "RGB666";
   pinctrl-names = "default";
   pinctrl-0 = <&pinctrl_lcd0>;  //having RGB DISP pins
   status = "okay";
};

So basically settings look okay except the DI0_PIN4. But still I cannot detect a sensible signal from pixel clk, but strangely when I am in the Uboot through console, following signals (in attachment) were acquired from DRDR (Red) and DISP0_CLK (Blue). What could be the reason for this :

[qiang_li-mpu_se]

DI0_PIN4 is not used.

Maybe you had set lcd to second framebuffer, so it is blanked default.

Please attached your full kernel boot up log. And after booted into Linux, please run the followed commands to dump the display informamtions:

$ cat /sys/class/graphics/fb0/fsl_disp_dev_property

$ cat /sys/class/graphics/fb1/fsl_disp_dev_property

$ cat /sys/class/graphics/fb2/fsl_disp_dev_property

$ cat /sys/class/graphics/fb3/fsl_disp_dev_property

$ cat /sys/class/graphics/fb4/fsl_disp_dev_property

$ cat /sys/class/graphics/fb5/fsl_disp_dev_property

[tengri]

Dear Qiang Li,

Hi, I was able to detect a video signal with VSYNC/HSYNC mode after modifying the lcd code, now I have few questions about the video format of the lcd entry.

1. Should MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04        0x80000000 be used in LCD group in dts file ?

2. Since we are receiving signals from 24 bit RGB port, what should be correct settings of lcd@ in dts file ?

lcd: lcd@0 {
   compatible = "fsl,lcd";
   ipu_id = <0>;
   disp_id = <0>;
   default_ifmt = "RGB666"; //shouldn't this be RGB24 ?
   pinctrl-names = "default";
   pinctrl-0 = <&pinctrl_lcd0>; 
   status = "okay";
};

3. The adv7343 encoder provides cvbs output only for an SD video input (or since any input is coming 24 bit format, should this work?) so if we modify the lcd entry of mxc_lcdif.c for that, how does it look like ? 

/* 1280x720p @ 60 Hz , pixel clk @ 74.25MHz */

"LCD-720P60", 60, 1280, 720, 13468, 220, 110, 20, 5, 40, 5,

FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,

FB_VMODE_NONINTERLACED,

0,},

I'd be grateful if you could kindly answer these question, one by one.......

Thanks in advance !

[qiang_li-mpu_se]

For Q1, DI0_PIN4 is not needed, your hardware doesn't need use it.

For Q2, the ifmt depends on your hardware, for NXP reference board, we only connected 18 data lines to LCD panel, so it is RGB666, if your hardware had connected 24 data lines, then you should use RGB24.

For Q3, that LCD-720P60 timing parameters is from CEA-861-D specification, you can check the SD video timing with adv7343.

[tengri]

And for this FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, following are the HSYNC and VSYNC acquired at RGB port. Can you please verify these two signals ? :

Blue : HSYNC and RED : VSYNC

Anyway the encoded signal I have at cvbs output does not have color space, only leaving the color burst in the signal !!!

[qiang_li-mpu_se]

Can you run command "cat /sys/kernel/debug/clk/clk_summary" to dump the real clock tree setting? Maybe you had set the pixel clock to IPU internal clock mode.

Please check device tree and make sure int_clk is 0:

 mxcfb3: fb@x {
  compatible = "fsl,mxc_sdc_fb";
  disp_dev = "lcd";
  interface_pix_fmt = "RGB565";
  mode_str ="CLAA-WVGA";
  default_bpp = <16>;
  int_clk = <0>;
  late_init = <0>;
  status = "disabled";
 };

[tengri]

Dear Qiang,

Thanks for your reply, it's set to 0 in dtb. But in the kernel log I can see 'use special clk parent' :

mxc_sdc_fb fb.22: registered mxc display driver lcd
mxc_sdc_fb fb.22: 800x480 h_sync,r,l: 20,60,40 v_sync,l,u: 10,10,10 pixclock=27000000 Hz
imx-ipuv3 2400000.ipu: ipu1_di0_pre_sel=540000000
imx-ipuv3 2400000.ipu: use special clk parent
imx-ipuv3 2400000.ipu: disp=0, pixel_clk=27000000 27000000 parent=108000000 div=4

Kindly take a look at these boot logs -> 

kernel log :

[Bash] Kernel Boot Log - Pastebin.com 

clk summary :

[Bash] Clock Distribution - Pastebin.com 

Another issue I am having is that, although I set the pixel clock time to 37037ps (=27MHz right?) in mxc_lcdif.c as you noted, the clock summary always ends up having 38MHz for it (In this nitrogen6_max board hdmi = ipu2disp0 and lcd=ipu1disp0). I don't know why it gets 38MHz, even kernel log says the registering is done for 27MHz. This is same for both hdmi and CLAA-WVGA (instead of custom lcd entry). When lcd only is up, the clock result is same ! Does IMX6Q have a limitation for dual display, i.e. no hdmi and lcd can work together ?

Anuradha

[qiang_li-mpu_se]

Hi Anuradha, you had used PLL5 as the clock source for both HDMI and LCD, that's reason that you caused the issue.

When the second display enabled, it will update the PLL5 frequency for its own pixle clock frequency.

In your case, since your LCD needs 27MHz pixel clock, you can change its clock source from PLL5 to PLL3_PFD1_540M. In file clk-imx6q.c, LCD on IPU1 DI0 as the example:

 imx_clk_set_parent(clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL], clk[IMX6QDL_CLK_PLL3_PFD1_540M]);  /* For LCD 27MHz pixel clock */
 imx_clk_set_parent(clk[IMX6QDL_CLK_IPU1_DI1_PRE_SEL], clk[IMX6QDL_CLK_PLL5_VIDEO_DIV]);
 imx_clk_set_parent(clk[IMX6QDL_CLK_IPU2_DI0_PRE_SEL], clk[IMX6QDL_CLK_PLL5_VIDEO_DIV]);
 imx_clk_set_parent(clk[IMX6QDL_CLK_IPU2_DI1_PRE_SEL], clk[IMX6QDL_CLK_PLL5_VIDEO_DIV]);

[tengri]

Dear Quiang, I've tried that one too. But I noticed something very strange in my kernel build process. According to what's mentioned in the process, the 'galcore' graphic driver module has to be installed as an external module to the kernel. So after the kernel build and installing 'galcore' module, I can see that ipu1disp0 switched to 38MHz ! Before this galcore module installed the ipu1disp0 appears to be 27MHz ! I tried building galcore as an internal module when kernel is built, but the result is same !

Ahh btw, what is the correct mode instead of FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT to drive this encode in VSYNC/HSYNC low modes ? ADV7343 expects this kind of sync, in otherwords the inverted version of the signals in the oscilloscope view right ? 

Many Thanks

Anuradha

[qiang_li-mpu_se]

Dump the clock tree before and after your operation, it can identify the issue easyer. But till now, I haven't seen such useful information from you.

cat /sys/kernel/debug/clk/clk_summary

You can just replace "FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT " with 0, then VSYNC and HSYNC will be low active.

[tengri]

Hi, I found following lcd entry from one of your patches :

/* 720x480i @ 60 Hz , pixel clk @ 27MHz */
"LCD-NTSC", 60, 720, 480, 37037, 114, 38, 31, 8, 124, 6,
0,
FB_VMODE_INTERLACED,
0,},

For only this entry, I can get pixel data from IMX6 RGB output. But still the enocder chip cannot convert it to a CVBS output. The encoder has been set to 525i(NTSC) format, 24bit input mode. VSYNC/HSYN in active low mode. Now now flip irq errors come. Any suggestion for this ? 

[qiang_li-mpu_se]

"flip irq errors", in this case, I think there is other unknown errors in your driver.

in fact, even you don't connect and add the adv7343 hardware and driver, the iMX6 chip can also output BT656 or parallel RGB data from LCD interface without error. So I think you should go back to original BSP code, just apply the BT656 or interlace patch.

After it works, what you should do is just setting the adv7343 with I2C commands.

[tengri]

Dear Qiang Ling, I was able to solve this issue by changing the timing parameters of the lcd entry. Even earlier I had no issues initializing the i2c writings, so the issue was in video resolution I used. Encoder works well in 1440x480 interlaced mode at 27MHz pixel clock ! You have been so helpful to get this resolved. Thanks..... !

Rgs

Anuradha

[hoanganh]

Hi tengri,

Could you share with me your output by fbset command?

[tengri]

Dear Qiang Li,

I was able to get the pixel data output from RGB interface, now the issue is setting the timing parameter for the lcd entry of mxc-lcdif.c ! We intend to run this ADV7343 encoder in 525i (NTSC) mode using 24-bit output pixel bus of imx6q. I also tried the existing entry BT656-NTSC in mxc_lcdif.c, but receiving the error 'timeout when waiting for flip irq' ! I guess this BT656-NTSC lcd entry is not suitable for my application, it also uses 8-bit signals from RGB interface right ?

/* NTSC Interlaced output */
"BT656-NTSC", 60, 720, 480, 37037,
19, 3,
20, 3,
276, 1,
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
FB_VMODE_INTERLACED,
FB_MODE_IS_DETAILED,},
{

what should be the correct timing parameters for 525i lines NTSC standard ?

i.e. hback-porch, hfront-porch, vback-porch, vfront-porch, hsync-len, vsync-len

Thanks in Advance

[tengri]

Hi Qiang, one more thing to confirm. Does nxp imx6 have a restriction for dual displays if ubuntu X11 desktop is used ? I want to run the display on both HDMI and Encoder (through RGB) simultaneously. Would this be possible if I use Ubuntu trusty (14) or xenial (16) images based around X11 ?

Thanks in Advance

[tengri]

Dear Qian Li,

Hi, apart from the entry in mxc_lcdif.c, do I need to change settings in any other source files (i.e. ipu_disp.c ) to get this work ? After compiling the kernel, the pixel clock of IPU1DISP0 becomes 38MHz instead of SD 27MHz. I checked the imx6_clk.c file, the parent of the DISP0 is set to PLL5. The pixel clock value is similarly wrong for the CLAA-WVGA lcd ! what could cause this issue ?

and in mxc_lcdif.c
/* 800×480 @ 57 Hz , pixel clk @ 27MHz */
TENGRI-LCD”, 57, 800, 480, 37037, 40, 60, 10, 10, 20, 10,
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT
FB_VMODE_NONINTERLACED,
0,},

[tengri]

Dear Qing, 

Hi, the frame buffer assignment issue was in the 6x_bootscript file, as it is loaded after the uboot command and it overwrites whatever I specified with uboot commands. After adding the video command (setenv bootargs ${bootargs} video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB24,bpp=32) to 6x_bootscript, I was able to get sort of acceptable signal wave forms from the RGB port. Now the terminal outputs for the above cat commands look like this :

> cat /sys/class/graphics/fb0/fsl_disp_dev_property
> lcd                  //----------------------------------------- > so fb0 is assigned to our lcd, this must be okay right ?
> root@tengri:/home/ubuntu# cat /sys/class/graphics/fb1/fsl_disp_dev_property
> overlay
> root@tengri:/home/ubuntu# cat /sys/class/graphics/fb2/fsl_disp_dev_property
> cat: /sys/class/graphics/fb2/fsl_disp_dev_property: No such file or directory

And after the i2c settings, I received sort of a cvbs looking signal from the encoder. However the TV does not detect this cvbs signal. I have few doubts about the settings I am using and they are as follows :

---------   DTS Settings   ---------

1. pincntrl settings of the lcd are defines as exactly as the way you pointed out (including DI0_PIN4).

2. lcd: lcd@0 {
      compatible = "fsl,lcd";
      ipu_id = <0>;
      disp_id = <0>;
      default_ifmt = "RGB24";         //This was originally RGB666 in default dts, is it okay to change this to RGB24 ?
      pinctrl-names = "default";
      pinctrl-0 = <&pinctrl_lcd0>;
      status = "okay";
};

--------- 6x_bootscript ----------

setenv bootargs ${bootargs} video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB24,bpp=32

--------- But in mxc_lcdif.c ----------

{
/* 800x480 @ 57 Hz , pixel clk @ 27MHz */
"CLAA-WVGA", 57, 800, 480, 37037, 40, 60, 10, 10, 20, 10,
FB_SYNC_CLK_LAT_FALL,
FB_VMODE_NONINTERLACED,
0,},
{

I know this settings in the lcdif is not compatible with the device (in video command) I have used. But instead of compiling the whole kernel (as this is a built in driver, external module installation can't be done) can't we pass following parameters in the boot command ?  Specially the command FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, ?

/* 1280x720p @ 60 Hz , pixel clk @ 74.25MHz */

"LCD-720P60", 60, 1280, 720, 13468, 220, 110, 20, 5, 40, 5,

FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,

FB_VMODE_NONINTERLACED,

0,},

I've also attached the wave forms observed herewith, I'd be really grateful if you could take a look at them and advise me.....

Thanks in advance !