We recently ported over to the RR2011Q2 SDK. One of the issues we found was that video (both composite and component) stopped working. Well, you can fix that :)
- The BSP file supplied is unsuitable because it's essentially setup for a TI EVM, not a Leopardboard. One way to fix it: get the arch/arm/board/mach-davinci/board/board-dm365-leopard.c BSP file from the previous RidgeRun DM365 SDK (e.g. SVN r76), and copy it into the new SDK. Or, if you had a home-brewed BSP in the previous SDK, use that (e.g. ours has fixes for THS7303 video filter, enables extra discrete IO's, etc). Then, in the BSP add the following lines which are needed for the new kernel:
void enable_lcd(void){}EXPORT_SYMBOL(enable_lcd);void enable_hd_clk(void){}EXPORT_SYMBOL(enable_hd_clk);
This fixes the video for DM365.
- On DM368 when running at full 432MHz speed, it's possible that the video clocks aren't precisely set to their exact rated values, because of PLL divider limitations (see my earlier post at http://designsomething.org/leopardboard/f/33/t/615.aspx where the HD video clock is set to 74.24MHz not the exact 74.25MHz). This is normally fine in practice, however the new kernel has check code that causes the clock to be recognized as invalid. This can be remedied by modifying the function davinci_enc_select_venc_clock() in the kernel file drivers/media/video/davinci_platform.c as follows:
int davinci_enc_select_venc_clock(int clk){ struct clk *pll1_venc_clk, *pll2_venc_clk; unsigned int pll1_venc_clk_rate, pll2_venc_clk_rate; pll1_venc_clk = clk_get(NULL, "pll1_sysclk6"); pll1_venc_clk_rate = clk_get_rate(pll1_venc_clk); pll2_venc_clk = clk_get(NULL, "pll2_sysclk5"); pll2_venc_clk_rate = clk_get_rate(pll2_venc_clk); // MJL Allow a tolerance here: 1 part in 1000 should be fine // The reason is that for DM368 it's difficult to get precise clocks // (e.g. using 74.24MHz instead of 74.25MHz). //if (clk == pll1_venc_clk_rate) if (clk >= pll1_venc_clk_rate/1000*999 && clk <= pll1_venc_clk_rate/1000*1001) __raw_writel(0x18, IO_ADDRESS(SYS_VPSS_CLKCTL)); //else if (clk == pll2_venc_clk_rate) else if (clk >= pll2_venc_clk_rate/1000*999 && clk <= pll2_venc_clk_rate/1000*1001) __raw_writel(0x38, IO_ADDRESS(SYS_VPSS_CLKCTL)); else if (cpu_is_davinci_dm368()) { enable_hd_clk(); __raw_writel(0x3a, IO_ADDRESS(SYS_VPSS_CLKCTL)); } else { dev_err(venc->vdev, "Desired VENC clock not available\n"); return -EINVAL; } return 0;}
With the tolerance factors of 1/1000 in place, the clock of 74.24MHz will now be accepted as valid by the driver allowing HD component video to work on DM368.
Mark Lesha, ANSTO
Hi Mark,
Thanks for your contribution to the community. Great hint.
Regards,
Marco MadrigalEmbedded Software EngineerRidgeRun
we are using dm365-leopard board. and RR2011Q2 SDK. then video composite output not working.
and a question:
i could not find the file from the previous RidgeRun DM365 SDK.
where can i find?
thank you
Timur Cakal
Electronic R&D EngineerAug, 25, 2011TeknikSAT Uydu & Guv. Sis. Tic. Ltd. Sti.Esenyurt / Istanbul
Hi,
Composite not working? This may help you:
www.ridgerun.com/.../LeopardBoard_365_TVP5146
Carlos AgueroEmbedded Software EngineerRidgeRun
I last downloaded the RidgeRun SDK from here, before 2001Q2 was released:
www.ridgerun.com/.../SDK_Release_for_DM365_Leopard_Board
Carlos, I am not sure if the kernel configuration you suggest is enough to get the video going for the Leopardboard. I will look into it when I get time though. The TVP5146 is not even present on the Leopardboard - this part is only on the TI EVM board. It is a video encoder - the problem I was addressing was video output (composite and component), not video encoder input.
Mark,
I'm new to LeopardBoard development but have been developing on the Spectrum Digital DM365EVM for awhile with good success.
I recently obtained a new LeopardBoard DM368 plus LI-5M03 Camera Board on which I have installed ti-dvsdk-dm368-evm_4_02_00_06 according to the recipe formulated by Steve at tw.myblog.yahoo.com/.../article (thank you Steve!); however, when I run root@dm368-evm:/usr/share/ti/ti-dmai-apps# ./video_loopback_dm368.x470MV -O component -I camera -y 4 (or -y 5), i.e., at resolutions of 1280x720 or 1920x1080 I get no video out of the component output while a -y 3, i.e., 720x480 the component output is as it should be.
I have checked and rechecked my bootargs, VPFE/VPBE driver registration/initialization, system clocks, and my /dev device directory - everything looks as it should - but the DMAI application starts up and "runs" with no errors but just does not output component video at HD resolutions.
I found both of your posts on this topic but am uncertain how to proceed: do you recommend that I update both the kernel davinci_platfrom.c and the U-Boot device.c in U-Boot? Or is there a better / simpler approach? Is there a way to read the VPBE registers directly to see what is going wrong? Any advise you can give would be greatly appreciated.
Thank you,
-Chuck
Mark, Steve, and All:
It turns out that Steve's recipe for hosting TI's DVSDK 4.02 onto the LeopardBoard DM368 is very good but incomplete ;-).
Recall from above that my configuration is: LeopardBoard DM368 v 1.5 + LI-5M03 Camera Board + DVSDK 4.02.00.06 installed per Steve's recipe. After DVSDK installation, creation of SD Card file system, etc. - the only resolution that would work using ./video_loopback_dm368.x470MV -O component -I camera -y x was 720x480 while using -y 4 or -y 5 (1280x720 or 1920x1080) will not output video via the VPBE component video output.
As Mark points out, the problem is due to the way the EVMDM36x derives its VPBE clocks externally via the CPLD resulting in the way the davinci_enc_select_venc_clock() function operates due to the fact that it checks the requested clock frequency against the current frequency of pll1_sysclk6 or pll2_sysclk5; therefore, Mark's modification must be applied. Although I find that my 16:9 LCD TV can tolerate more than the 1 part in 1000 frequency variance Mark cites.
It's interesting that running ./video_loopback_dm368.x470MV -O component -I camera -y 4 (or -y 5) will not cause an error or any other complaint but the application will hang at the DMAI Display_get() function that is called after Display_create().
Thanks again Steve and Mark,