How do I turn on video clock, DM6467T EVM

Hi,

You can call this CPLD function at the driver init time, so that it will be enabled at kernel boot time.

Thanks,

Brijesh Jadav

Thanks very much for working on evaporating the black hole...

I may have misled you with my own confusion on the post.  And now your response further confuses me -- unless the two confusions cancel each other out!

1) when you say "call this CPLD function", do you mean an actual C language "function", or do you simply mean to control the CPLD?  If you mean a "function", what' s the name of it? If you mean simply to control, then perhaps the other thread is where I'll find my answer.

2) NEVERTHELESS, my original confusion was that Reg 1 Bit 1 is *not* where my issue is.  In order to turn on the video clock, some DaVinci registers need to be set so that VPIF_CLKIN2 is forwarded to VPIF_CLKOUT2.  This seems to be in the DaVinci and has nothing to do with the CPLD.

So my real question, is how do I get this clock to pass through, within the context of running under linux and trying to do things in the 'right' way?

Hi,

I think you have added an API in the board specific file (board-dm646x.c) to write to CPLD register. You will required to call this API from driver init function to turn it on.

I still do not understand why you want to forward VPIF_CLKIN2 to VPIF_CLKOUT2. VPIF_CLKIN2 is input clock for the capture not for the display. For display, you can have independent clock, which can be either sysclk or external clock. I think by default it uses external clock source (CDCE949) for the display driver. You will just require turn on this clock to provide clock to your encoder. Are you using internal color bar in your encoder for the display? If not, you will need to configure VPIF display also to send out data in correct format i.e. 720p, 1080i etc.

Thanks,

brijesh Jadav

Brijesh,

Regarding board-dm646x-evm.c, I have indeed *envisioned* adding an API, but I haven't done it yet.  I'm trying to figure out how to communicate with this API first, from user space, and I don't know that yet.  Also, note that this API relates to setting a bit in an already partially used register of the CPLD, that I haven't been able to access otherwise because the resource is busy.  The end objective here is to power down the Internet PHY chip at times, which uses a lot of power.  This is a separate objective from the subject of this thread.  My thread for this I2C/CPLD issue is at http://e2e.ti.com/support/embedded/f/354/p/103153/363342.aspx#363342 where you have already been kindly helping me.

Regarding VPIF_CLKOUT2, I am only slightly confused.  For certain, VPIF_CLKOUT2 drives my newly designed ADV7171 video output chip circuit, just as it drove the EVM's video output chip.  For comparison, the TVP5147 video input chip is driven by VPIF_CLKIN0 on both the EVM and my board.  My confusion must be on the DM6467T end of the VPIF_CLKOUT2 signal...

I know for certain that this VPIF_CLKOUT2 signal comes from the DM6467T, out the pin with label VP_CLK02.  I may have incorrectly assessed its input as coming from VPIF_CLKIN2.  

**REGARDLESS** of from where its input comes, I need to enable this path.  I need VPIF_CLKOUT2 to become active during boot, presumably by custom code I add to the ADV7170 driver ("70" vs "71" spelling is correct).  Once my ADV7171 chip has a clock, I have already configured it to generate color bars from inside this chip.  So, this driver gets loaded within less than 16 seconds of power on.  Thus, my device will show "proof of life" on the video output within 16 seconds of the power being turned on.  This is in contrast to the 2.5 minutes originally and 68 seconds now (that I have a splash screen in my encodedecode derived program, prior to the very slow codec server load out of nand memory).

So, to recap, how do I activate VPIF_CLKOUT2, in same manner as it's otherwise activated when the encodedecode derived program runs?

Note that I have done some hacking down of a temporary copy of the encodedecode derived program.  Inside the DMAI function Display_create(), the key actions are to call _Dmai_v4l2UserAlloc() followed by ioctl(fd, VIDIOC_STREAMON, &type/*V4L2_BUF_TYPE_VIDEO_OUTPUT*/).  The ioctl causes the VPIF_CLKOUT2 to activate, but the ioctl gets an error if not preceded by the _Dmai_v4l2UserAlloc().  Without the shortcut assistance I'm hoping for on this forum, my plan of attack would be to dig through the ioctl to find out why it fails without the _Dmai_v4l2UserAlloc().  Then I would make a local (user space) clone of that code in order to whittle it down, and eliminate that dependency.  Next, I would whittle down further to find the true action enabling the clock.  (I may be able to determine all this just by looking, now that I've found the ioctl(...VIDIOC_STREAMON...), and not need to clone or whittle.)  After that, if the truly responsible code is in kernel space, I'll just copy a clone of it into my ADV7170 driver, that's already conditionally modified to output color bars.  

I will finally need one more thing.  Whenever the encodedecode derived program *does* run, I need the ADV7170 driver to reconfigure the ADV7171 to no longer generate color bars.  There are some V4L2 sub functions being called, and I'll probably be able to trap on one of those to accomplish this.  In fact, I will probably be able to determine if the system is idle or active, and every time it's idle, including boot up, turn the darned VPIF_CLKIN2 back on and reconfigure back to color bars.  That is, right now the display is off with no clock prior to the application, and once again after the application.  All that off time needs to be replaced with colorbars.  (My final app will never stop, so boot up time is more important.  For purists, I'll clarify that my app will never stop while power remains on, and if power is removed, boot will occur after power returns.)