This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Regarding V4L2 drivers

Other Parts Discussed in Thread: TVP7002

Greetings,

I have read some documents about v4l2 driver, however I am still not clear about how to deal with our following application scenario.

We have a custom design with dm814x/dm816x with a HDMI Rx on the board.

The I2C of HDMI Rx will be taken care of by a microcontroller, so I do not need actually write the sub-driver for the hdmi chip.

My HDMI Rx will give me hsync, vsync, DE signals.

There is a TI wiki shows us how to add external decoders, however after reading it carefully I am still confused about what I should do.

Here are my questions:

1. if I donot need write the registers of our hdmi rx via I2C, what should I change in ti81xx_fb.c to let Davinci Soc can recognize video and sync data ?

Hardik once told me in the other thread that the place where master driver and subdriver hooked up is in ti81xx_fb.c.

And the bold places should be modified if using a different decoder. As far as I undersood, there only give the master driver the I2C address of tvp7002.

    This  " .platform_data = &tvp7002_pdata"  just define the polarities of hsync, vsync, de etc.

struct ti81xxvin_interface tvp7002_pdata = {
    .clk_polarity = 0,
    .hs_polarity = 0,
    .vs_polarity = 1,
    .fid_polarity = 0,
    .sog_polarity = 0,

};
static struct ti81xxvin_subdev_info hdvpss_capture_sdev_info[] = {
    {
        .name    = TVP7002_INST0,
        .board_info = {
            /* TODO Find the correct address
                of the TVP7002 connected */
            I2C_BOARD_INFO("tvp7002", 0x5d),
            .platform_data = &tvp7002_pdata,
        },

Let's say if i want to support RGB24 bit- discrete sync mode of my hdmi rx, the following codes should be change. Please correct me or remind me if any other changes is required.

ti81xx_fb.c:

 hdvpss_capture_sdev_info[ 0 ].vip_port_cfg.ctrlChanSel=VPS_VIP_CTRL_CHAN_DONT_CARE.

hdvpss_capture_sdev_info[ 0].vip_port_cfg.video_capture_mode=VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_DISCRETE_SYNC_HSYNC_VSYNC. hdvpss_capture_sdev_info[ 0 ].vip_port_cfg.video_if_mode=VSP_CAPT_VIDEO_IF_MODE_24BIT.

hdvpss_capture_sdev_info[ 0 ].vip_port_cfg.input_data_format= FVID2_DF_RGB24_888.

2. Where exactly is the place tvp7002.ko used?

To keep the changes of driver minimum, I am going to just empty tvp7002.c to let it serve as a dummy driver. The reason for that is our hdmi rx will be wrote by an external microcontroller. Am I right about this? Any problem with this approach?

I was also wondering which  file in the linux kernel used tvp7002.ko? This is the file after recompiling tvp7002.c and should be copied to /targetfs/lib/modules/2.6.37/kernel/drivers/media/video

If later I do need use Davinici to write our HDMI rx registers via I2C, I will have to create v4l2 sub-driver.

Thanks in advance,

Jun


  • Hi,

    Answers to some of your questions.

    1. V4L2 driver architecture requires to have sub-device. This is because data from external world comes through sub-devices like decoders. In your case, since you dont want to use decoder from A8, you have to modify drivers  and ti81xxfb.c files to remove all decoder calls. We have patch for explaining the changes required. Please find the attached patch.  V4L2 capture driver is connected to TVP7002 using the platform data.

    2. TVP7002.ko is used by V4L2 capture driver for all sub-devices calls. All "v4l2_subdev_call" in v4l2 capture driver will finally land in TVP7002.ko. Driver is present in $Kernel_source/drivers/media/video/tvp7002.c

    For better understanding of V4L2 sub-device model you can refer to following documentation of kernel $Kernel_source/Documentation/video4linux/v4l2-framework.txt. Most of the questions will be answered if you read above V4L2 driver model.

    Regards,

    Hardik shah

  • Hi,

    Attaching the patch.

    Regards,

    Hardik Shah

  • Hi Hardik,

    Thanks for your quick reply very much.

    Somehome I cannot see the attachment. Could you please post it again?

    Regards,

    Jun

  • Hello,

    I am basically working through the same issues as described in this post.  Is this patch posted somewhere, I also do not see it attached.

     Thanks,

    Craig

  • Hello,

    here is the attached patches.

    It may not apply directly on your version of driver but you will get idea about changes required

    Regards,

    yihe

    sub_devices_calls_removed.zip
  • Thanks yihe,

    It really helps us.

    Regards,

    Jun

  • Yihe,

     Thanks also for attaching the patch, it does help.   Further question....

     I hand applied the patch to the kernel that I am using and tried to insert the ti81xxvin.ko as a module and am getting missing symbols referenced below when I try to insert the module.  Any thoughts on what I missing?   I am using 2.6.37-psp0400.01.13.patch2 for my kernel base and building for the dm816x. 

     I am not inserting the tvp7002.ko module now, since I believe it is not longer needed.  I also did try to insert it and got the same error messages.

     Thanks for any help....

     Craig

     Also:  I can start a new thread for this question if it would be better to keep it separate, don't want to take over the post.....

     

     root@dm816x-evm:~# insmod ti81xxvin.ko

    ti81xxvin: Unknown symbol vps_capture_unregister_isr (err -22)

    ti81xxvin: no symbol version for vps_capt_get_num_cap

    ti81xxvin: Unknown symbol vps_capt_get_num_cap (err -22)

    ti81xxvin: no symbol version for vps_capt_get_ctrl

    ti81xxvin: Unknown symbol vps_capt_get_ctrl (err -22)

    ti81xxvin: no symbol version for vps_capture_register_isr

    ti81xxvin: Unknown symbol vps_capture_register_isr (err -22)

    ti81xxvin: no symbol version for vps_capture_unregister_isr

    ti81xxvin: Unknown symbol vps_capture_unregister_isr (err -22)

    ti81xxvin: no symbol version for vps_capt_get_num_cap

    ti81xxvin: Unknown symbol vps_capt_get_num_cap (err -22)

    ti81xxvin: no symbol version for vps_capt_get_ctrl

    ti81xxvin: Unknown symbol vps_capt_get_ctrl (err -22)

    ti81xxvin: no symbol version for vps_capture_register_isr

    ti81xxvin: Unknown symbol vps_capture_register_isr (err -22)

  • Hi Craig,

    I have not tested this patch yet. (I am waiting for our custom board.)

    But, I guess I will meet the same problem with you.

    Just one quick question, did you run rmmod ti81xxvin.ko before you insmod again?

    For me I donot mind you take over my post.

    Thanks,

    Jun

  • Hi Jun,

    Looks like the missing symbols should be defined in the vpss.ko module.  I think the issue is that I configured the kernel correctly for the video input, but since this is loaded as a module I need to regenerate the module.   Missed this step..

    make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- modules

    I am in the process of doing this, and well let you know if I get it working.

    Craig

  • Craig,

    Did you load vpss.ko or rebuild modules(vpss.ko) after applying patches?

    Regards,

    yihe

  • yihe,

    You where correct, the issue with the unresolved symbols is that I was not moving over the new vpss.ko module.  I have now got passed this.. 

    I can now insert the module, but when I try to run the "saloopBack.c" example the driver crashes.  The module that I am patching is much longer then your example and had a few more V4l2_ calls later on that I comment out. 

    Few questions:

    1) I comment out the register call v4l2_device_register on line 2456 and then most of the for loop from lines 2468 to 2502.    I have attached the modified file. Note sure this is correct.  Any guidance would be helpful.

    2) With these changes, am I correct that I no longer will need the tvp7002.ko module.

    Thanks,

    Craig

  • Hi,

    Can you please attach the diff instead of ti81xxvin_main.c and the crash log you were seeing without making any changes.

    Regards,

    Hardik Shah

  • Hardik,

     Thanks for the response.  I think I figured out the crash issue.  I had originally made the mistake of commenting out the registration call below trying to get read of the requirement for loading the tvp7002.ko driver.  

     err = v4l2_device_register(ti81xxvin_dev, &ti81xxvin_obj.v4l2_dev);

     So I believe when I tried to call anything in the driver, I would get a reference to a NULL device.  I put back in the call, and made a dummy tvp7002.ko module that does nothing in the load/unload but return a good status.  This seems to work, and I am now in the process of trying to modify the saLoopBack.c example to capture a single image.  Let me know if there is better example that I should started with since I really only want to capture an image, not loop it back onto the display.

     I have attached the difference file for reference.  Let me know if you see anything that may be an issue.  I started with the file that came in the linux-2.6.37-psp04.00.01.13patch2 linux kernel.

     Thanks.

     Craig  

  • Hi,

    Good to hear that you are making progress. I will try to generate one more example for capture only in our next release. I also suggest you to  move to latest release that is PSP04.00.02.14. It will be easy to get support on latest release than on old release.

    Regards,

    Hardik shah

  • Hardik,

    Thanks for the response.  On your advice I have updated to the latest release (PSP04.00.02.14).   I have made some progress, but also have more questions.   Just so you are clear on what we are trying to accomplish are configuration is as follows:

    • We have a custom board with an omi-vision OV7740 sensor that puts out data in 640x480 resolution.  We have configured the sensor to put out 16 bit YUYV format, interleaved (But code change it if needed)
    • We are configuring the sensor through an I2C bus connected to another micro controller.  Linux is not configuring the device, so we have used the patch to comment out all the sub v4l2_subdev_ calls.
    • We are using a dummy tvp7002 module that does nothing, just returns success on module load.

    Some Questions:

    1. Are sensor is connected to VIN1. I would assume I would open “/dev/video1” to read from the device.  Is this correct?  If so where would I configure this?  I can open “dev/video0” and do the VIDIOC_G_FM OCTL command, but fails if I do it to “dev/video1”. 

     

    1. I get failures back when I try to start the stream using the IOCTL command VIDIOC_STREAMMON. These are being generated from the ti81xxvin_check_format. I would assume I do not having something configured correctly.  Should I be able to configure the driver to support my sensor?

    Finally I have attached a simple capture application that I am generating to try to test just the capture.  If you notice anything obviously incorrect let me know.

    Thanks for any guidance you can give.

    Thanks,

    Craig

  • Hi,

    Following are answers to your questions.

    1. You should be opening /dev/video2. This is because video0 and video1 goes to same VIP with different ports.

    2. You need not to insert tvp7002 in case you have commented out all the sub-devices call.

    You need to take care in driver that query_dv_preset returns VGA resolution when you do query_dv_preset. This will make sure that you s_fmt and check_fmt passes. You need to take care all the v4l2 ioctls returns proper data in case where they are calling sbu-devices. This is because sub-devices calls are commented out you need to hardcode to return proper value. Please dont change app sequence. 

    Regards,

    Hardik Shah

  • Hardik Shah,

    Thanks for the clarification.  Now that I have comment out all the sub-device sub I don't need to insert the tvp7002 driver. 

    I did update the functionp vidioc_query_dv_preset to setup the resolution to VGA.  I added the following code:

     

                mbus_framefmt.width = 640;

                mbus_framefmt.height = 480;

                mbus_framefmt.code = V4L2_MBUS_FMT_YUYV8_2X8;

                mbus_framefmt.field = V4L2_FIELD_NONE;

                mbus_framefmt.field = V4L2_COLORSPACE_REC709;

                qpreset->preset = V4L2_DV_INVALID;

                inst->video.cur_dv_preset.preset = V4L2_DV_INVALID;

                inst->video.cur_std_id = V4L2_STD_UNKNOWN;

                inst->video.cur_dv_preset = *qpreset;

     I now get to the point where I have setup all the buffers and call the ictol command VIDIOC_DQBUF, which never returns, which I assume it means it is not detecting any input frames.

     So A Question:

    If we injecting the input into VIN1A_D0-VIN1A_D9 and are using external VIN1A_VSYNC/VIN1A_HSYNC.  Where do I configure this?  Do I need to update the file ti81xx_fc.c to have the correct configuration?  I was thinking I need to update the ti81xx_hsvpss_capture_cfg .inst_config[2] to match our setup.  If not where does this get configured?

     Thanks,

     Craig

  • Hi,

    Few clarificationns,

    1. HDVPSS VIP port can support 8/16/24 bit capture. It cant support 10 bit capture. 

    Yes you have to change ti81xxfb.c file as V4L2 capture driver is configured for embedded sync reception. Further you also need to take care of the Errata point 1.1.10 at http://www.ti.com/lit/er/sprz329a/sprz329a.pdf

    How to modify ti81xxfb.c is explained in following document.http://processors.wiki.ti.com/index.php/DM81xx_AM38xx_Adding_External_Decoders_to_V4L2_Capture_Driver

    I advise you to operate in embedded sync mode till you get some data out of VIP. this is because V4L2 capture driver is configured for embedded sync by default second because of the errata point 1.1.10.

    Regards,

    Hardik Shah

  • Craig,

    Did you ever get this working? I am trying to integrate with a CMOS as well. Whenever i enable some form of discrete syncing the application times out inside ti81xxvin_vps_start and then crashes. Did you experience something similar? If switch to embedded sync it "works" in that it sits there waiting to dequeue a buffer but of course the embedded sync never comes since its a CMOS imager.

    Any input would be greatly appreciated!

    Thanks,

    Ben

  • Hi,

    You might be missing errata advisory 1.1.10 @http://www.ti.com/lit/er/sprz329a/sprz329a.pdf

    Regards,

    Hardik Shah

  • Hardik,

     I stated the configuration incorrectly, we are only doing 8 bit input connected to VIN1, data bits 0-7. 

     I have taken your advice and configured connected camera to use embedded sync mode,  can use an oscilloscope to see that the signals are making it to the integra, but currently still do not see any frames being captured when I start the stream and try and dequeue images.  

     I now am wondering if I am using the correct version of the firmware for the M3 processor.  I did not realize  that the binary image in the HDVPSS-01.00.01.33 associated with the latest release of the PSP (04.00.02.14)  has a different name then the image that came with the latest EZSDK (5_03_1_15). 

                EZSDK                       - dm816x_hdvpss.xem3  (~16 meg)

                HDVPSS-01.00.01.33 - ti816x_hdvpss.xem3 (~8 meg)

     Questions:

     1) Should we now be loading the M3 image ti816x_hdvpss.xem3, instead of dm816x_hdvpss.xem3 to get display/capture to work?

     

    2) I have update my configuration to try and use the ti816x_hdvpss.xem3 that came in the HDVPSS-01.00.01.33 version.  I update the start script from:

             firmware_loader $HDVPSS_ID /usr/share/ti/ti-media-controller-utils/dm816x_hdvpss.xem3 start

     to:

            ./slaveloader startup VPSS-M3 /usr/share/ti/ti-media-controller-utils/ti816x_hdvpss.xem3

     Now the system boots, but hangs when loading the M3 core with the last message of:

     SysLink version : 2.00.05.85

    SysLink module created on Date:Feb  8 2012 Time:08:59:48

    Loading HDVPSS Firmware

    Attached to slave procId 2.

    Any thoughts on what can be causing the hang?  The syslink that was part of the binary package was complaining about a mismatch with the kernel, so I am using a slightly newer version.

     

    3) Finally on our custom board we only have 512 Megs of memory and where using the following boot argument notifyk.vpssm3_sva=0xBF900000.  I changed it to the address given on the user guide "notifyk.vpssm3_sva=0xA0000000".  Not sure this if this is correct for our configuration.  Both addressed caused the board to hang.   

     

    Thanks for you help on this issue.

     

    Craig

  • Ben,

     I have not got this working yet and am not questioning if I have the correct M3/VPSS configuration (See post below).  What version of the M3 firmware are you trying to use?

     I will let you know if I make progress...

     

    Craig

  • Hi Craig,

    If i were to guess i would say stick with the original v4l2 exectuable. The ezsdk comes with 2 vpss binaries. The default which is used with OMX and the v4l2 flavor. I am currently using the psp .13patch2 version.

    I happen to have access to both 1.1 and 2.0 hw versions. I have an EVM and a custom board.

    When i run the appilation on the evm the application hits a timeout when it tries to start the video capture. When it comes back from timeout it then crashes when it tries to dequeue a buffer. From the old source code that i have seen there is an if statement that the code only goes into when discrete syncing is enabled AND when you have less than 2.0 hw. This is i think where it is crashing. 

    When i run the application on 2.0 HW it makes it all the way up to the waiting to dequeue a buffer and then just sits there. I would assume this means that it is waiting for what it thinks is the proper sync pulse and it never happens. I am currently have the sync mode set to VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_DISCRETE_SYNC_HSYNC_VSYNC since i am using 2.0 hw and it should have the active video issue. I have changed the pinmuxing of the hsync and vsync pins. I don't know what else i am missing. Again, from what i saw of the old HDPVSS source code there was that if statement that the code will not enter because i am using 2.0 HW, i am hoping that it still sets things up properly for discrete sync. 

    Hardik,

    the above file i am referencing is is vpsdrv_captureList.c and the function Vps_captDoDisSyncStartSequence gets called. this only gets called if it passes the check Vps_captIsDisSyncStartSequenceNeeded which is essentially if (usingDiscreteSync && using1.1silicon). Do we need to go into that if statement if we have 2.0 silicon and still want to use discrete sync?

    thanks

    -Ben

  • So i got things working... mostly. My goal is this: Capture 16bit raw monochrome data at a custom resolution (I am currently doing 720p but would like to do 1280 * 960) and pass it to the arm, then use the arm to do a little processing and then format it for display (copy the luma into a YUV display buffer).

    I realize that the 8168 isn't really meant for capturing raw data and that i have to tell it is some flavor of YUV, but as long as it doesn't go through any processing the data should come out just fine, right?

    What i am seeing is the image is in the lower right corner of the screen. This would make sense if it was displaying at 1080p but it is displaying at 720p so the image should take up the whole screen. I am thinking that it is getting resized perhaps?  How do i disable any processing done and just pass the raw data to the ARM?

    Thanks,

    Ben

  • Hi,

    If you set input_data_format = FVID2_DF_YUV422P in arch/arm/mach-omap2/ti81xx_fb.c and set output data format at YUV422I then there is not processing involved, captured data directly comes out of the port. Instead of seeing it on TV, you should dump data to file and see few images to make sure whether its a problem with capture or display. You need to make sure that while doing S_FMT you give the buffer width, height and pitch based on how you require the data in buffer. Further in discrete sync mode, VIP capture driver captures vertical blanking data as well, so you will see a black horizontal bar on top which corresponds to vertical blanking data. This you can strip off using buffer pointer manipulation.

    Regards,

    Hardik Shah

  • Thanks Hardik,

    I have capture working correctly now on the first video port. I am now trying to add a second instance of the driver. I see in ti81xxfb.c all of the info for the second instance (the only thing different is the i2c address) but i am not seeing how to tell the kernel to probe for a second instance of the device when i insert the module. Is there some place to tell the module that I want to look for the second instance and not just the first? 

    I really appreciate the help that you have supplied so far, thanks for doing a great job.

    -Ben

  • Hi,

    Good to know that you have 1st instance of I2C working. If you are using V4L2 capture in 16-bit mode that instance 2nd (0.1) is not available to you. You need to use 3rd instance of driver that is (0,1,2) to get the second video capture (/dev/video2) in case you insert V4L2 capture first, or (/dev/video5/) in case you insert V4L2 display first. Now coming to your original question, I am not able to get your question fully, but what i understood is that you are trying to add the second instance for your decoder right using sub-device model. if that is the case you can use $Kernel/drivers/media/video/tvp514x.c file as source to know how to add multiple instance for same decoder.

    Regards,

    Hardik Shah

  • Thanks for all your help Hardik, I have capture working simultaneously with two 12 bit CMOS imagers. 

  • Hi,

    Thanks for update. All efforts materialized.

    Regards,

    Hardik Shah

  • Hey Ben,

     

    Good to hear that you got this working.  I have been doing other tasks and just getting back to look at this.  I was wondering what changes you need to make to ti81xx_fb.c.

     

    I am adding a decode to support 640x480 YUYV, and currently getting no frames captured.  Not sure if I need to have my decode have a preset that supports this resolution or if I set this in another way.  I don't see a preset for this resolution, like the other resolutions (Ex: 4L2_DV_720P60).  Was wondering if you had to do something like this for your custom resolution.

     

    Any help would be appreciated.

     

    Thanks,

    Craig

  • Craig,

    be sure to set these two

     .lineCaptureStyle =	VPS_VIP_LINE_CAPTURE_STYLE_HSYNC,
    .fidDetectMode =	VPS_VIP_FID_DETECT_MODE_PIN,
    
    
    I set the resolution in my module file in the my_device_mbus_fmt function and just hard coded it. 
    
    
    Hope this helps,
    
    
    Ben
  • Hi all,

    Has anyone had any luck with the patches contained in sub_devices-calls_removed.zip (which yihe posted a while back in this thread)?  I applied these patches, reran a 'make linux' from the EZSDK top level, and copied over the new ti81xxfb.ko and ti81xxvin.ko modules to my rootfs.

    Note that I have removed the EVM's IO board, and replaced it with our custom capture board.  However, it seems that the ti81xxvin driver now fails out after attempting to probe the (now unused) I2C bus for the TVP7002:

    tvp7002 3-005d: tvp7002 found @ 0x5d (OMAP I2C adapter)
    tvp7002 3-005d: TVP7002 read error -121
    tvp7002: probe of 3-005d failed with error -121
    ti81xxvin ti81xxvin: Error registering v4l2 subdevice

    I see that Craig previously tried removing the subdevice registration, which caused issues.  That being said, what is recommended as far as using those patches without a TVP7002 attached to the I2C bus? Am I correct in assuming that I'll have to create a subdevice driver, even if the properties of the input stream are fixed?

    Thanks!

    Jon

  • BenM,

    Can you post your working code for V4L driver here. I am on the same boat and would like to use it as a reference for my code.

    Thanks

    RV
     

  • A note for everyone....I am working with Craig on this problem.  Using a FPGA to drive the eval board inputs, we have found that on the eval board, without driving TIM4_OUT (SYNC_DET on daughtercard) with a HSYNC like signal, one can not capture frames.  We are awaiting feedback from TI on if/where this is documented and how to get around this for an encoder that doesn't have the same signal.  We hope that embedded syncs are supported without the need to drive this pin, but are awaiting some help with this.

    Just posting this in case anyone is trying the same thing without driving that signal...you might be tormenting yourself needlessly ;)

  • Hi,

    You got this capture working, congrats  I am struggling a bit to get capture work.

    I will briefly explain What I did so far.

    I have TI8148 based custom board. It has video capture chip connected to port A of VIP instance 1. It is a 24 bit interface.

    Currently I am working with ezsdk 05_03_01_15.  which has PSP 04.01.00.06.patch2 and HDVPSS 01.00.01.33.

    I want to capture video using Port A of VIP instance 1. (Release notes and user guides only talk about capturing from Port A of VIP instance 0)

    With above PSP and HDVPSS binaries I am able to open the device(/dev/video2). When I sent create command to video-M3. I got filehandle  NULL error.

    VPSS_FVID2: create handle is NULL

    This is exact error that I got from vpss on create command.

    My question is whether above mentioned HDVPSS firmware supports capturing from Port A of VIP instance 1.

    If No, then which release of HDVPSS binaries supports it.

    I will be grateful to any kind of help on this topic.

    Regards,

    Prashant.

  • Hi everyone,

    I am under NDA with our customer so unfortunately I cannot post a bunch of code. I can give a little advice though.

    First off my configuration is using EZSDK 5.3.1.15 with the .13patch2 release of the kernel for DM8168. I am captureing with a 1280x960 12bit monochrome cmos imager at 45 fps on both capture ports. I based my project out of the saLoopback V4L2 example. I followed the "adding V4l2 decoder" user guide to create my own kernel  module for my imager. I stubbed out basically all of the functions and had them return 0. I do set the resolution and kept portions of the probe. I don't really use any of the "presets" but i did put some in there so that it would not be empty. I did not have to change/comment out any of the subdevice code, they all call my module and get happy responses. The main area of change is the ti81xxfb file that configures all of the syncing. Go through each field and check to see if what you have makes sense compared to options available. If you are not using embedded syncs then put "dont care" in for those options. set the syncing to discrete hsync/vsync and set the triggering to pin mode. If you get to the point where it is just sitting there waiting to dequeue buffers and it is never getting one, then that means one of these parameters is wrong and that it never thinks that it is capturing a frame. When the board boots is should say that it detected your imager and inserted the device. In order to enable the second port you need to go into the ti81xxvin_main.c the is a for loop that goes from 0<1, and calls some subdevice informations. Make it so it loops twice and it will try to add the second capture port. that is all i had to do to enable the second capture port. 

    Best of luck,

    -Ben

  • Prashant,

    We have a custom board using the ti8168 based processor.  We have yet to get it to capture on our custom board, but have it capturing on the Eval board using our external sensor.  We are using 8 bit capture on VIP1 port A.  We had to make the following changes to the eval configuration.

    -        We had to setup the eval MUX and switches to select the correct port.

    -         For the configuration for this port we are using TVP7002_INST0, NOT TVP7002_INST1 that would be expected.  This is due to a defect in the driver code, that I believe Ben is describing above in ti81xxvin_main.c.

    -        We also have to drive the sync_dect signal, even with embedded syncs enabled.  This post describes what we are seeing.

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/170619.aspx

    Regards,

    Craig

  • Hi,

    We have tested only VIP0 port A but code is there for all the ports and instances of VIP. So for you it must work. You can get file handle Null if configuration passed in invalid. Make sure the configuration passed is correct.

    Regards,

    Hardik Shah

  • Hardik,

    Thanks for reply.

    Can you briefly tell me what are  the parameters which can cause file handle to be NULL.

    because I have only changed video interface mode from 16 bit to 24 bit .

    Now corresponding to this, do I need to chanage few more parameters?

    Regards,

    Prashant.

  • Hi,

    Can you please print following structure and paste it here. I want to see parameters passed on capture driver.

    Vps_CaptCreateParams. Its a part of instance object

    ti81xxvin_instance_obj->vps_capt_ctrl->cparams.

    Please print it in the streamon function of capture driver.

    Regards,

    Hardik Shah

  • Hardik,

    Thanks for the reply.

    I am able to get the handle now.

    But I think saLoopBackFbdev seems to be hanging at IOCTL VIDIOC_DQBUF.

    I think It is because VPSS not able capture the video.

    I am using 24 bit capture and data format is 24 bit RGB 4:4:4.

    The sync is embedded and complete SAV/EAV codes are available on three channels(R, G, B).

    Please let me know, what is going wrong.

    Regards,

    Prashant.

     

  • Hi,

    Can you dump following registers once it hangs at DQbuf. Open another telnet session and try dumping the registers.

    0x48105500 --> 100 registers

    0x48105a00 --> 100 registers.

    Regards,

    Hardik shah

  • Thanks Hardik,

    Please find the dump of the regvals .

    Just one query, Is there any documnet which gives descriptions of HDVPSS registers.

    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105500 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105504 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105508 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10550c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105510 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105514 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105518 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10551c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105520 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105524 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105528 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10552c regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105530 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105534 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105538 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10553c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105540 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105544 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105548 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10554c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105550 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105554 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105558 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10555c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105560 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105564 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105568 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10556c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105570 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105574 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105578 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10557c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105580 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105584 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105588 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10558c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105590 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105594 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105598 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10559c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055a0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055a4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055a8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055ac regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055b0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055b4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055b8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055bc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055c0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055c4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055c8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055cc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055d0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055d4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055d8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055dc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055e0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055e4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055e8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055ec regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055f0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055f4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055f8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa1055fc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105600 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105604 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105608 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10560c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105610 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105614 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105618 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10561c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105620 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105624 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105628 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10562c regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105630 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105634 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105638 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10563c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105640 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105644 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105648 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10564c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105650 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105654 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105658 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10565c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105660 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105664 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105668 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10566c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105670 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105674 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105678 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10567c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105680 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105684 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa105688 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP0 reg addr fa10568c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a00 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a04 regval 8000a415---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a08 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a0c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a10 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a14 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a18 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a1c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a20 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a24 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a28 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a2c regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a30 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a34 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a38 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a3c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a40 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a44 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a48 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a4c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a50 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a54 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a58 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a5c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a60 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a64 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a68 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a6c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a70 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a74 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a78 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a7c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a80 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a84 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a88 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a8c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a90 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a94 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a98 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105a9c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105aa0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105aa4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105aa8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105aac regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ab0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ab4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ab8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105abc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ac0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ac4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ac8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105acc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ad0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ad4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ad8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105adc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ae0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ae4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105ae8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105aec regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105af0 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105af4 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105af8 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105afc regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b00 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b04 regval 8000a415---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b08 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b0c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b10 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b14 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b18 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b1c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b20 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b24 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b28 regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b2c regval ffffffff---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b30 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b34 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b38 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b3c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b40 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b44 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b48 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b4c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b50 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b54 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b58 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b5c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b60 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b64 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b68 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b6c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b70 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b74 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b78 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b7c regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b80 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b84 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b88 regval 00000000---
    ti81xxvin ti81xxvin: ---VIP1 reg addr fa105b8c regval 00000000---

    Regards,

    Prashant.

  • Hi Hardik,

    I am able to capture  video successfully using VIP 1 PORT A, and also able to display the captured data using frame buffer device.

    I have used saLoopBackFbdev to capture and display video.

    But I am getting an error

    Port A overflowed.

    After this error driver stops and restarts again. Because of this error display flickers a lot.

    Now in the saLoopBackdev.c there is this comment

    /* HDVPSS VIP capture is having bug that it locks up some time
             * under heavy bandwidth conditions. DQBUF will return error in
             * case hardware lock up. Applicatin needs to check for the
             * lockup and in case of lockup, restart the driver */

    What do you mean by heavy bandwidth conditions. because I am capturing 720p60 RGB24 video data.

    Is there any workaround like changing buffering mechanism etc.

    Regards,

    Prashant.

  • Hi,

    Can you please give me following details.

    1. You are trying to capture 24bit RGB on TI814x right.

    2. Are you getting this overflow immediately once you start capture.

    3. Once you get this, do capture remains in overflow condition?

    We have bug in M3 whereby, once port is overflow it never gets reset. Are you seeing that behavior.

    Regards,

    Hardik Shah

  • Hi,

    Thanks for the reply.

    1. You are trying to capture 24bit RGB on TI814x right.

    Ans -: yes

    2. Are you getting this overflow immediately once you start capture.

    Ans-: yes

    3. Once you get this, do capture remains in overflow condition?

    Ans-: Yes,

    Let me explain here, once it goes into overflow condition,  aplication  stops and restarts the capture after this  capturing seems to be starting as we can see the video. but yes overflow  condition occurs immediately after restart. so there is continuous overflow, stop, start sequence.

    Regards,

    Prashant.

  • Hi,

    This is problem in M3 binary. You will have to wait for the next EZSDK release.

    Regards,

    Hardik Shah

  • Hi

    What is expected date for next ezsdk release

    currenlty I am using TI814x-HDVPSS-01.00.01.33 v4l2 binaries which is part  EZSDK_05_03_01_15.

    If I use HDVPSS bins TI814x-HDVPSS-01.00.01.37 and use kernel from PSP_04_01_00_07, will the problem be solved or it will still persist.

    Regards,

    prashant.

  • Hi,

    Answers inline,

    Prashant Dhumal said:
    What is expected date for next ezsdk release

    I am not sure about this. Let me checkout here and let you know.

    Prashant Dhumal said:

    currenlty I am using TI814x-HDVPSS-01.00.01.33 v4l2 binaries which is part  EZSDK_05_03_01_15.

    If I use HDVPSS bins TI814x-HDVPSS-01.00.01.37 and use kernel from PSP_04_01_00_07, will the problem be solved or it will still persist.

    No this is not possible as there is interface changes in binary.

    Regards,

    Hardik Shah

  • Hi,

    Thanks for your prompt reply.

    Is there any release of HDVPSS binaries which has VPSS locking/reset problem solved,

    if it is there just let me know and tell me its dependencies,  I myself will try to get it work. So that I did not have to wait till next EZSDK release.

    Regards,

    prashant.