Question: DM8168 use VIN0 to capture discrete RGB data

Hello,

You could check here:

http://processors.wiki.ti.com/index.php/DM81xx_AM38xx_Adding_External_Decoders_to_V4L2_Capture_Driver

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/154092.aspx?PageIndex=1

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/159978.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/160009.aspx?pi239031349=1

Hope this help.

Best Regards,

Margarita

thanks for your advise, i have read some before,

when i capture discrete data with fpga on vip0, it cannot work properly ,so i think if the sinal have problem or not

i have modify signal follow "The VIP port requires that the ACTVID signal is active for all lines of the incoming data, including the vertical blanking region. The vertical blanking region, itself, is not written to memory", but when i start capture , vip say "V4L2_BUF_FLAG_ERROR present!!! Port a overflowed"

so i want to know if vip have some other important points about sinal timing?

Hi,

Which Silicon revision you are using? Also are you doing any in scaling in VIP path?

Regards,

Brijesh

from bootmsg can see  Silicon revision is 1.1 , what means "in scaling in VIP path"? input of vip0 is 1080p60 RGB,  because if i capture with RGB888,the board will hangs, so i capture vip0 with V4L2_PIX_FMT_YUYV, the capture app is saLoopBackFbdev

Are you making sure of toggling ACTVID signal on all lines including blanking lines? On 1.1 silicon revision, it will not work otherwise. Also you should use ACTVID style of capture.

Regards,

Brijesh

yes, i has check the signal of VSYNC/HSYNC/ACTIVD,and follow Docment "TMS320DM816x DaVinci Video Processors Silicon Errata (Rev. 2.1, 2.0, 1.1, & 1.0) (Rev. D).PDF", when VSYNC is high means vertical blanking region, at this time also have HSYNC and ACTIVD? when HSYNC is low and ACTIVD is high means data is active, now i can capture only 18 byte one frame or appear "Port a overflowed"

Hi Wen,

VSYNC not necessarily mean vertical blanking area, is it the case in your decoder? Yes, you will have to toggle ACTVID signal during this signal as well. Are you using any other modules in the VIP path like scalar? Also is your output format YUV420? If it is, please note it could cause overflow when it receives odd number of lines?

Regards,

Brijesh

thanks

      input RGB data are given by fpga to vin0, in capture app 'saLoopBackFbdev.c", we set capt.fmt.fmt.pix.pixelformat to V4L2_PIX_FMT_YUYV, I think i did not use other modules,our output format is YUV422, input format is RGB888,as i said, only capture 18byte every frame and frame rate is too big or recieve overflow,so what i should check ?

Hi Wen,

Could you explain your input signals? which pins are connected? which input signals you are using? Have you configured VIP accordingly?

Regards,

Brijesh Jadav

1. my input signals is 1920*1080@60p RGB24 data given by our fpga

2.the jpeg file is our  connectedadd  signal pin

3.follow is pin mux in /arch/arm/mach-omap2/device.c

  omap_mux_init_signal("vin0_d16", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_d17", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_d18", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_d19", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_d20", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_d21", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_d22", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_d23", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_vsync0", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_hsync0", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_de0", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin0_fld0", OMAP_MUX_MODE1);    
  omap_mux_init_signal("vin1_d8",  OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_d9",  OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_d10", OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_d11", OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_d12", OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_d13", OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_d14", OMAP_MUX_MODE1);
  omap_mux_init_signal("vin1_d15", OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_clk1",   OMAP_MUX_MODE2);
  omap_mux_init_signal("vin1_vsync1", OMAP_MUX_MODE3);
  omap_mux_init_signal("vin1_hsync1", OMAP_MUX_MODE3);  
  omap_mux_init_signal("vin1_fld1", OMAP_MUX_MODE3);
  omap_mux_init_signal("vout0_r_cr2",    OMAP_MUX_MODE0);
  omap_mux_init_signal("vout0_r_cr3",    OMAP_MUX_MODE0);
  omap_mux_init_signal("vout0_r_cr4",    OMAP_MUX_MODE0);
  omap_mux_init_signal("vout0_r_cr5",    OMAP_MUX_MODE0);
  omap_mux_init_signal("vout0_r_cr6",    OMAP_MUX_MODE0);
  omap_mux_init_signal("vout0_r_cr7",    OMAP_MUX_MODE0);
  omap_mux_init_signal("vout0_r_cr8",    OMAP_MUX_MODE0);
  omap_mux_init_signal("vout0_r_cr9",    OMAP_MUX_MODE0);
  omap_mux_init_signal("tsi7_dclk",    OMAP_MUX_MODE1); //vout0_hsync
  omap_mux_init_signal("tsi7_data",    OMAP_MUX_MODE1); //vout0_vsync
  omap_mux_init_signal("tsi7_bytstrt",    OMAP_MUX_MODE1);//vout0_fld
  omap_mux_init_signal("tsi7_pacval",    OMAP_MUX_MODE1); //vout0_avid
  omap_mux_init_signal("iic1_scl", OMAP_MUX_MODE0 | OMAP_PULL_UP);
  omap_mux_init_signal("iic1_sda", OMAP_MUX_MODE0 | OMAP_PULL_UP);  

4.follow is vip config in arch/arm/mach-omap2/ti81xxfb.c,

static struct ti81xxvin_subdev_info hdvpss_capture_sdev_info[] = {
 {
  .name = FPGA_INST0,
  .board_info = {
   // TODO Find the correct address
   // of the TVP7002 connected
   //I2C_BOARD_INFO("tvp7002", 0x5d),   
   //.platform_data = &fpga_pdata,
  },
  .vip_port_cfg = {
   .ctrlChanSel = VPS_VIP_ANC_CH_SEL_DONT_CARE,
   .ancChSel8b = VPS_VIP_ANC_CH_SEL_DONT_CARE,
   .pixClkEdgePol = VPS_VIP_PIX_CLK_EDGE_POL_FALLING,  
   .invertFidPol = 0,
   .embConfig = {
    .errCorrEnable = 1,
    .srcNumPos = VPS_VIP_SRC_NUM_POS_DONT_CARE,
    .isMaxChan3Bits = 0,
   },
   .disConfig = {
    .fidSkewPostCnt = 0,
    .fidSkewPreCnt = 0,
    .lineCaptureStyle =     
     VPS_VIP_LINE_CAPTURE_STYLE_ACTVID,     
    .fidDetectMode =
     VPS_VIP_FID_DETECT_MODE_DONT_CARE,     
    .actvidPol = VPS_VIP_POLARITY_HIGH,               
    .vsyncPol =  VPS_VIP_POLARITY_LOW,                
    .hsyncPol = VPS_VIP_POLARITY_LOW,               
   }
  },
  .video_capture_mode =   
   VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_DISCRETE_SYNC_ACTVID_VSYNC,
  .video_if_mode = VPS_CAPT_VIDEO_IF_MODE_24BIT,
  .input_data_format = FVID2_DF_RGB24_888, 
 },
 {
  .name = TVP5150_INST0,
  .board_info = {   
   I2C_BOARD_INFO("tvp5150", 0x5d),
   //.platform_data = &tvp5150_pdata,
  },
  .vip_port_cfg = {
   .ctrlChanSel = VPS_VIP_CTRL_CHAN_SEL_15_8,
   .ancChSel8b = VPS_VIP_ANC_CH_SEL_DONT_CARE,
   .pixClkEdgePol = VPS_VIP_PIX_CLK_EDGE_POL_RISING,
   .invertFidPol = 0,
   .embConfig = {
    .errCorrEnable = 1,
    .srcNumPos = VPS_VIP_SRC_NUM_POS_DONT_CARE,
    .isMaxChan3Bits = 0,
   },
   .disConfig = {
    .fidSkewPostCnt = 0,
    .fidSkewPreCnt = 0,
    .lineCaptureStyle =
     VPS_VIP_LINE_CAPTURE_STYLE_DONT_CARE,
    .fidDetectMode =
     VPS_VIP_FID_DETECT_MODE_DONT_CARE,     
    .actvidPol = VPS_VIP_POLARITY_DONT_CARE,
    .vsyncPol =  VPS_VIP_POLARITY_DONT_CARE,
    .hsyncPol = VPS_VIP_POLARITY_DONT_CARE,
   }
  },
  .video_capture_mode =
   VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_EMBEDDED_SYNC,    
  .video_if_mode = VPS_CAPT_VIDEO_IF_MODE_8BIT,
  .input_data_format = FVID2_DF_YUV422P,                 
 },
};

as you see 

our fpga send discrete sync 24Bit-RGB to 8168 vin0,capture fail

our tvp5150 send embedded sync 8Bit-BT656 to 8168 vin1_B,capture ok

thanks

Hi Wen,

Can you check if your ACTVID and Hsync polarity is matching with the configuration? Also can you try inverting pixel clock polarity?

Regards,

Brijesh Jadav

yes, i has check the ACTVID and Hsync polarity, they are right ,ACTIVD is high active,Hsync is low active

when i invert pixel clock polarity from VPS_VIP_PIX_CLK_EDGE_POL_FALLING to VPS_VIP_PIX_CLK_EDGE_POL_RISING,  capture also failed

follow is dump register from 0x48105500 after ioctl(capt.fd, VIDIOC_DQBUF, &capt.buf); when pixel clock polarity is set to be VPS_VIP_PIX_CLK_EDGE_POL_FALLING and VPS_VIP_PIX_CLK_EDGE_POL_RISING

VPS_VIP_PIX_CLK_EDGE_POL_FALLING :

48105500:  0000 0000 a50a 8040 0000 0000 0000 0000
48105510:  0000 0000 0000 0000 0000 0000 0c10 0000
48105520:  fffc ffff fffc ffff ffff ffff ffff ffff
48105530:  0001 0037 0000 0000 0000 0000 0000 0000
48105540:  0000 0000 0000 0000 0000 0000 0000 0000
48105550:  0000 0000 0000 0000 0000 0000 0000 0000
48105560:  0000 0000

VPS_VIP_PIX_CLK_EDGE_POL_RISING:

48105500:  0000 0000 a10a 8040 0000 0000 0000 0000
48105510:  0000 0000 0000 0000 0000 0000 0c10 0000
48105520:  fffc ffff fffc ffff ffff ffff ffff ffff
48105530:  0001 00ae 0000 0000 0000 0000 0000 0000
48105540:  0000 0000 0000 0000 0000 0000 0000 0000
48105550:  0000 0000 0000 0000 0000 0000 0000 0000
48105560:  0000 0000

i do not know whether 1.1 can capture discrete sync on vin0 ?

Hi wen,

From the register configuration,

hsync polariyt is active low

vsync polarity is active low

actvid polarity is active high

pixel clock is set to rising edge

Could you please check if configuration is correct?

Regards,

Brijesh Jadav

hi Brijesh

yes  when pixel clock polarity is set to be VPS_VIP_PIX_CLK_EDGE_POL_FALLING or VPS_VIP_PIX_CLK_EDGE_POL_RISING,the result is same

i has test again,some other info:

1. capture format 1920*1080 YUV422, before fpga singal 1920*1080p60 24Bit RGB,then vpss creat failed

                                                                     after  fpga singal 1920*1080p60 24Bit RGB,then capture overflow or caputre frame rate is more than 60

2.capture format 1920*1080 RGB888,before fpga singal 1920*1080p60 24Bit RGB,then board waitting at DQBUF ioctl, I can use ctrl+c end app

                                                                    after  fpga singal 1920*1080p60 24Bit RGB,then board hangs ,I cannot use ctrl+c end app, must restart board

Hi

could you clearly tell me version 1.1 can support discrete 24Bit capture on vin0?

if my signal is wrong, or can you given me a right signal timing for discrete syns?

Hi Wen,

It is supported and tested with the TVP7002, but as i said, there are issue in discrete sync capture, we need to have a specific start up condition, otherwise, it will not capture, could you tell me which hdvpss release you are using?

Regards,

Brijesh

ok,our work at EZSDK5.03,which hdvpss is 01_00_01_35

when rootfs print such info:

Loading HDVICP2 Firmware
DM816X prcm_config_app version: 2.0.0.1
Doing PRCM settings...
        PRCM for IVHD0 is in Progress, Please wait..... 
                        BW Phy Addr : 0x48180600 Data : 0x00000002
                        AW Phy Addr : 0x48180600 Data : 0x00000002
                        Phy Addr : 0x48180c04 Data : 0x00000037
                        BW Phy Addr : 0x48180620 Data : 0x00070000
                        AW Phy Addr : 0x48180620 Data : 0x00070002
                        BW Phy Addr : 0x48180624 Data : 0x00030000
                        AW Phy Addr : 0x48180624 Data : 0x00010002
                        Phy Addr : 0x48180600 Data : 0x00000102
                        BW Phy Addr : 0x48180c10 Data : 0x00000007
                        AW Phy Addr : 0x48180c10 Data : 0x00000003
                        Phy Addr : 0x48180c14 Data : 0x00000004
                        BW Phy Addr : 0x58088000 Data : 0xf231adbb
                        AW Phy Addr : 0x58088000 Data : 0xeafffffe
                        BW Phy Addr : 0x58098000 Data : 0x69526d1d
                        AW Phy Addr : 0x58098000 Data : 0xeafffffe
                        BW Phy Addr : 0x48180c10 Data : 0x00000003
                        AW Phy Addr : 0x48180c10 Data : 0x00000000
                        Phy Addr : 0x48180c14 Data : 0x00000007
        PRCM for IVHD0 is Done Successfully 
        PRCM for IVHD1 is in Progress, Please wait..... 
                        BW Phy Addr : 0x48180700 Data : 0x00000002
                        AW Phy Addr : 0x48180700 Data : 0x00000002
                        Phy Addr : 0x48180d04 Data : 0x00000037
                        BW Phy Addr : 0x48180720 Data : 0x00070000
                        AW Phy Addr : 0x48180720 Data : 0x00050002
                        BW Phy Addr : 0x48180724 Data : 0x00030000
                        AW Phy Addr : 0x48180724 Data : 0x00010002
                        Phy Addr : 0x48180700 Data : 0x00000102
                        BW Phy Addr : 0x48180d10 Data : 0x00000007
                        AW Phy Addr : 0x48180d10 Data : 0x00000003
                        Phy Addr : 0x48180d14 Data : 0x00000004
                        BW Phy Addr : 0x5a088000 Data : 0x5f71e06a
                        AW Phy Addr : 0x5a088000 Data : 0xeafffffe
                        BW Phy Addr : 0x5a098000 Data : 0x31963d7b
                        AW Phy Addr : 0x5a098000 Data : 0xeafffffe
                        BW Phy Addr : 0x48180d10 Data : 0x00000003
                        AW Phy Addr : 0x48180d10 Data : 0x00000000
                        Phy Addr : 0x48180d14 Data : 0x00000007
        PRCM for IVHD1 is Done Successfully 
        PRCM for IVHD2 is in Progress, Please wait..... 
                        BW Phy Addr : 0x48180800 Data : 0x00000002
                        AW Phy Addr : 0x48180800 Data : 0x00000002
                        Phy Addr : 0x48180e04 Data : 0x00000037
                        BW Phy Addr : 0x48180820 Data : 0x00070000
                        AW Phy Addr : 0x48180820 Data : 0x00050002
                        BW Phy Addr : 0x48180824 Data : 0x00030000
                        AW Phy Addr : 0x48180824 Data : 0x00010002
                        Phy Addr : 0x48180800 Data : 0x00000102
                        BW Phy Addr : 0x48180e10 Data : 0x00000007
                        AW Phy Addr : 0x48180e10 Data : 0x00000003
                        Phy Addr : 0x48180e14 Data : 0x00000004
                        BW Phy Addr : 0x53088000 Data : 0xb0540fb1
                        AW Phy Addr : 0x53088000 Data : 0xeafffffe
                        BW Phy Addr : 0x53098000 Data : 0x9971c3ef
                        AW Phy Addr : 0x53098000 Data : 0xeafffffe
                        BW Phy Addr : 0x48180e10 Data : 0x00000003
                        AW Phy Addr : 0x48180e10 Data : 0x00000000
                        Phy Addr : 0x48180e14 Data : 0x00000007
        PRCM for IVHD2 is Done Successfully 
PRCM Initialization completed
SysLink version : 2.00.05.85
SysLink module created on Date:Dec  9 2011 Time:12:47:37
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [Location of Mem map bin file]
FIRMWARE: Default memory configuration is used
MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.1.1
FIRMWARE: Memory Configuration status : In Progress
FIRMWARE: 1 start Successful
Loading HDVPSS (V4L2) Firmware
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [Location of Mem map bin file]
FIRMWARE: Default memory configuration is used
MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.1.1
FIRMWARE: Memory Configuration status : In Progress
FIRMWARE: 2 start Successful

Wen,

I still think there is some signalling issue. Can you again check that if vsync is active high or low?

Regards,

Brijesh

thanks,

I has try  work on EZSDK5.05 yesterday, but also fail! so i think it is  silicon version1.1 issue or signalling issue but not m3 binary

I check vsync it is do active low as hsync active low,  and when vsync is low or high, the activd and hvsyn also signal,

Because if i start signal, the app will wrong, this said 8168 can find signal,but however it cannot clearly distinguish    

Do you said tvp7002 has be test ok with discrete sync on silicon 1.1? I check 7002 docment, it's hsync_out and data_out has some delaytime to hsync_in ,but no said some vsync timting,can you give me a 7002 signal timing in order i can follow, 

Hi.can you check our signla is right or not