The frames I'm capturing from the TVP5158 look as if two interlaces frames are placed one on top of the other. Below is the frame, and a zoomed-in version, where you can see how the alternating lines seem to come from two distinct frames:
I'm very unsure about why this is happening. My first guess was that I wasn't clearing the frames fast enough from the frame-buffers queued for the capture driver, but even when all I do is clear frames and only collect the first frame from the queue, I still get the same problem. Here's the main loop that does the work:
while(!done) { status = MCVIP_getBuf(prm->info.mcvipHndl, &bufId, OSA_TIMEOUT_FOREVER); if(status!=OSA_SOK) { done = TRUE; break; } pBufInfo = MCVIP_getBufInfo(prm->info.mcvipHndl, bufId); if(pBufInfo != NULL) { tmpChId = (prm->info.createPrm.videoInputPort == MCVIP_VIDEO_INPUT_PORT_1) ? (pBufInfo->chId + prm->info.createPrm.chIdOffset) : pBufInfo->chId; if(tmpChId == recordedChannel) { chInfo = &prm->info.chList.info[pBufInfo->chId]; /* Save to file */ static int filenum=0; char filename[255]; static char buffer[736*576*2]; FILE* outFile; int frameBytesUsed = chInfo->offsetH * chInfo->offsetV * 2; memcpy(buffer, pBufInfo->virtAddr, frameBytesUsed); // Write to a file sprintf(filename, "cap-ch%d-n%03d-%c.yuv", tmpChId, filenum++, 'a'+bufId); outFile = fopen(filename, "w"); if (outFile) { fwrite(buffer, frameBytesUsed, 1, outFile); fclose(outFile); } MCVIP_putBuf(prm->info.mcvipHndl, bufId, MCVIP_FLAG_ALL_DONE); // skip the rest of the frames currently in the queue int dumpedBufId; while((status = MCVIP_getBuf(prm->info.mcvipHndl, &dumpedBufId, OSA_TIMEOUT_NONE)) == OSA_SOK) { MCVIP_putBuf(prm->info.mcvipHndl, dumpedBufId, MCVIP_FLAG_ALL_DONE); } } } }
Extra details:
- I'm running this on Linux dm368-evm 2.6.32.17-davinci1, from the DVSDK 4.02.00.06
- I'm using the TVP5158 MCVIP driver for DVSDK 3.x v00.02.00 from June 2011 (re-compiled for the DVSDK 4.x), with a downloadable patch v02.03.02
What can I do to prevent this "interlace" or "combing" effect?
Shalom,
I'm experiencing the same thing: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/162211.aspx. Did you ever find a resolution to your problem?
I've gone through everything I can think of to confirm that the buffers are processed in order and that each frame which is demuxed contains the appropriate number of lines. I'm running out of ideas short of writing my own tvp5158 driver.
Mark
Also, the good news (I suppose) is that you are using the DM368-EVM and that I am using the UDWORKS DVR hardware running DVSDK 4.02, so we have two different hardware designs exhibiting the same problem.
Hopefully the problem is in software.
I figured it out. In mcvip_tvp5158_i2c.c, super frame register (address 0xB7) is set to 0x14 (625 line mode). Change this to 0x04 (525 line mode) and the telecine effect is gone. I'm pretty sure that the people who wrote the driver had very limited access to NTSC hardware.
Hi Mark,
Good to know that the issue is solved. Now that you tell me the problem, it seems like the code is changed at some point of time to set register 0xB7 with value 0x14. In our earlier implementation (in UDWorks DVRRDK), we had 0xB7 set to 0x04 in NTSC mode and 0x14 in PAL mode.
The problem is that if you set Super Frame register to use 625 line mode, it will pump out a superframe with lines per frame as 2500 lines. In our ISR we would still be handling it as a NTSC super frame and switching buffers. We would be missing field of a channel as it was not expected in the ISR and would use the field of the missing fieldId whenever it comes. So the odd and even field can be off by many frames.
Sorry for the issues. We have raised this as a bug to the development team.
Regards,
Anshuman
PS: Please mark this post as verified, if you think it has answered the question. Thanks.
Anshuman,
There are some other problems as well. I'd suggest hooking up some NTSC hardware to see what I mean.
1. In the test application, PAL is hard coded in display_v4l2.c
2. There's a whole slew of compiler warnings, including some really basic ones like the lack for forward declarations for the i2c functions, etc.
3. The documentation is outdated. It references CSL as a requirement, for starters.
4. In the zip file, there are two copies of the I2C and DMA drivers. One in mcvip_tvp5158/drv/kermod/src and one in mcvip_tvp5158/lsp_files/lsp_patch/tvp5158.c. This is very confusing when you are trying to understand the source.
5. There is an excessive amount of debug output, such as dumping the i2c registers.
These are just off the top of my head, but I'd be grateful if you could pass them along to the development team.
Mark,
Thanks for your comments. I have passed this information to our development team. I would provide more updates later once i hear back from them.
hi,experts
i use DM365_DVR_DVSDK3_00.02.00.00.zip mcvip packages from http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/118704.aspx.
i see tvp5158 info from boot msg on dm365 as below:
...
i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery tsc2004: probe of 1-0049 failed with error -110 i2c /dev entries driver Linux video capture interface: v2.00 ths7303 1-002c: chip found @ 0x58 (DaVinci I2C adapter) i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery ths7303 1-002c: ths7303 write failed ths7303: probe of 1-002c failed with error -110 I2C: Module install successful, device major num = 251 DMA: Module install successful, device major num = 250 TVP5158: Module built on Feb 29 2012 21:39:09 vpfe_init vpfe-capture: vpss clock vpss_master enabled vpfe-capture vpfe-capture: v4l2 device registered vpfe-capture vpfe-capture: video device registered i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery mt9p031 1-0048: No MT9P031 chip detected, register read ffffff92 vpfe-capture vpfe-capture: v4l2 sub device mt9p031 register fails No sub devices registered vpfe-capture: vpfe capture clocks disabled vpfe_register_ccdc_device: DM365 ISIF dm365_isif: probe of dm365_isif failed with error -22 af major#: 249, minor# 0 AF Driver initialized aew major#: 248, minor# 0 AEW Driver initialized Trying to register davinci display video device.
....
however,i test mcvip_test.out and get errors like these:
/examples # ./mcvip_test.out ----MCVIP 0I2C: Driver registration in progress for address b6.. pObj->client=[0] Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c5690000 [00000000] *pgd=85679031, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: /sys/devices/virtual/irqk/irqk/dev Modules linked in: irqk edmak dm365mmap cmemk CPU: 0 Not tainted (2.6.32-17-ridgerun #7) PC is at memcpy+0x48/0x330 LR is at I2C_create+0xd4/0x19c pc : [<c015f328>] lr : [<c0222b10>] psr: 20000013 sp : c51efe7c ip : 00000000 fp : c51efeb4 r10: 00000000 r9 : c51ee000 r8 : 000000b6 r7 : c041a8fc r6 : 0000005b r5 : c53e0b00 r4 : c53e0b08 r3 : 00000000 r2 : 00000050 r1 : 00000000 r0 : c53e0b08 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 85690000 DAC: 00000015 Process mcvip_test.out (pid: 1117, stack limit = 0xc51ee270) Stack: (0xc51efe7c to 0xc51f0000) fe60: c53e0b00 fe80: 0000005b c041a8fc 000000b6 c53e0b08 c53e0b08 c0222b10 000000b6 00002c01 fea0: c5664e80 00000000 c51efeec c51efeb8 c0222c38 c0222a4c 0002dcf0 c51effb0 fec0: 00000000 00012c98 c51f7280 c41c8b80 c5664e80 000000b6 00002c01 c5664e80 fee0: c51eff0c c51efef0 c00a8378 c0222be8 00000005 c5664e80 00000005 c5664e80 ff00: c51eff7c c51eff10 c00a8a28 c00a8310 c560ad80 00000003 00000000 c5664e80 ff20: c51eff5c 00000000 00000000 c51f41f0 00000000 c41c8b80 00000020 c51f41f0 ff40: 00000000 c41c8b80 00000020 c51f41f0 c51eff94 00000005 000000b6 00002c01 ff60: c5664e80 c002c0e4 c51ee000 00000000 c51effa4 c51eff80 c00a8ac4 c00a84a4 ff80: c51ee000 00000000 beca3c9c 0002dcec 000000b6 00000036 00000000 c51effa8 ffa0: c002bf60 c00a8a94 beca3c9c 0002dcec 00000005 00002c01 000000b6 ffffffff ffc0: beca3c9c 0002dcec 000000b6 00000036 0002caa8 00000000 00000000 00000001 ffe0: 00000001 beca3c98 00012ce0 40de1aec 20000010 00000005 ffffffff ffffffff Backtrace: [<c0222a3c>] (I2C_create+0x0/0x19c) from [<c0222c38>] (I2C_devIoctl+0x60/0x2e0) r7:00000000 r6:c5664e80 r5:00002c01 r4:000000b6 [<c0222bd8>] (I2C_devIoctl+0x0/0x2e0) from [<c00a8378>] (vfs_ioctl+0x78/0x94) r7:c5664e80 r6:00002c01 r5:000000b6 r4:c5664e80 [<c00a8300>] (vfs_ioctl+0x0/0x94) from [<c00a8a28>] (do_vfs_ioctl+0x594/0x5f0) r7:c5664e80 r6:00000005 r5:c5664e80 r4:00000005 [<c00a8494>] (do_vfs_ioctl+0x0/0x5f0) from [<c00a8ac4>] (sys_ioctl+0x40/0x64) [<c00a8a84>] (sys_ioctl+0x0/0x64) from [<c002bf60>] (ret_fast_syscall+0x0/0x28) r7:00000036 r6:000000b6 r5:0002dcec r4:beca3c9c Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8) ---[ end trace 93e213e3096a1781 ]--- Segmentation fault /examples #
i find tvp5158 could not be probed.tvp5158 's vcc 3.3v 1.8v 1.1v are all right,and 27M crystal is right,too.my tvp5158 i2c address also is 5B(I2CA0=1,I2CA1=1,I2CA2=0).
why dm365 could not probe tvp5158?anyone could give me your correct boot msg or some lead?
need mcvip's my board-dm365-evm.c revised?anyone help me?
ths a lot
Jonny,
You probably need to set the proper platform data up in your board definition. This is what you should see in your kernel's boot log:
{ tvp5158_probetvp5158 1-005f: chip found @ 0xbe (DaVinci I2C adapter)tvp5158 1-005f: tvp5158 1-005f decoder driver registered !!tvp5158_initialize}tvp5158_probe}
or
{ tvp5158_probetvp5158 1-005b: chip found @ 0xb6 (DaVinci I2C adapter)tvp5158 1-005b: tvp5158 1-005b decoder driver registered !!tvp5158_initialize}tvp5158_probe}
Something like that. My board has 2x tvp5158s, and it is possible that I've changed the debug output slightly.
Anyway, you need to populate a vpfe_subdev_info structure, a vpfe_cfg structure and then call dm365_set_vpfe_config with a pointer to that structure as an argument.
There should be an example of this in the mcvip zip file. I ported my board definition from the UDWORKS sample before I noticed that one was provided in the mcvip stuff, so I can't say how accurate the provide one is.
hi,thank you,mdeneen
i have "vpfe_subdev_info structure, a vpfe_cfg structure and then call dm365_set_vpfe_config ",now my trouble is board cant find tvp5158.i have only one tvp5158.and schematics like below.I can check 27M crystal ok,and vcc3.3v vcc1.8v vcc1.1v all right.but board can't find tvp5158.My schematics has only one different net from Udworks DVR
schematics, which is my schematics has no intreq net,Udworks DVR schematics connecting intreq pin to gio60 of dm365.i think it is not necessary.my board have only one tvp5158,no slave tvp5158.so all pins related with slave chip is suspended.
Could you expert give me any lead.when my board boots,run initializeing tvp5158 code,it shows:
i2c_davinci i2c_davinci.1: initiating i2c bus recovery i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery
my board is ok if i connect mt9p031 sensor board to isif 17x2 connector of dm365 ,that is my board 's ccdc/isif interface is no problem. troubles come from tvp5158 board.
i have no idea how to do?any help would be appreciated.
my i2cad0-i2cad2 is 110,i only soldered three resistors on above schematics.
hi,kind mdeneen
could you show your tvp5158 part code in board c file in kernel/arch/arm/mach-davinci/ directory?
i find DM365_DVR_DVSDK3_00.02.00.00.zip has some bugs.
1,board-dm365-evm.c in mcvip lsp_file dir,line 139,
'static struct tvp7002_platform_data tvp5158_pdata={ ' should be 'static struct tvp5158_platform_data tvp5158_pdata={ '
2,board-dm365-evm.c should include tvp5158.h
after rectifying above code,i add
static struct i2c_board_info i2c_info[]={
{I2C_BOARD_INFO("tvp5158",0x5B),},
};
then i could find tvp5158 in boot infomation:
Linux video capture interface: v2.00 ths7303 1-002c: chip found @ 0x58 (DaVinci I2C adapter) { tvp5158_probe tvp5158 1-005b: chip found @ 0xb6 (DaVinci I2C adapter) tvp5158 1-005b: tvp5158 1-005b decoder driver registered !! tvp5158_initialize} tvp5158_probe} I2C: Module install successful, device major num = 251 DMA: Module install successful, device major num = 250 TVP5158: Module built on Mar 5 2012 18:18:23 vpfe_init vpfe-capture: vpss clock vpss_master enabled vpfe-capture vpfe-capture: v4l2 device registered vpfe-capture vpfe-capture: video device registered mt9p031 1-0048: No MT9P031 chip detected, register read ffffff87 vpfe-capture vpfe-capture: v4l2 sub device mt9p031 register fails
However,i run mcvip.out ,i have another error:
/examples # ./modules.sh /examples # ./mcvip_test.out ----MCVIP 0I2C: Driver registration in progress for address b6.. pObj->client=[0] I2C: Driver registration successful I2C_LG (address=5b)..[5b] DRV_i2cOpen: 5 TVP5158_checkCI2C: Driver registration in progress for address be.. hip found i2cHnd pObj->client=[1] l:2dcec (0xb6) iUnable to handle kernel NULL pointer dereference at virtual add0=0 j=0 ----MCVIpgd = c51f0000 P 1 [00000000] *pgd=851fc031, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: /sys/devices/virtual/irqk/irqk/dev Modules linked in: irqk edmak dm365mmap cmemk CPU: 0 Not tainted (2.6.32-17-ridgerun #27) PC is at memcpy+0x48/0x330 LR is at I2C_create+0xd4/0x19c pc : [<c015f328>] lr : [<c0222b10>] psr: 20000013 sp : c51d7e7c ip : 00000000 fp : c51d7eb4 r10: 00000000 r9 : c51d6000 r8 : 000000be r7 : c041a93c r6 : 0000005f r5 : c560d200 r4 : c560d208 r3 : 00000001 r2 : 00000050 r1 : 00000000 r0 : c560d208 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 851f0000 DAC: 00000015 Process mcvip_test.out (pid: 1121, stack limit = 0xc51d6270) Stack: (0xc51d7e7c to 0xc51d8000) 7e60: c560d200 7e80: 0000005f c041a93c 000000be c560d208 c560d208 c0222b10 000000be 00002c01 7ea0: c5665980 00000000 c51d7eec c51d7eb8 c0222c38 c0222a4c c51d7ee4 c51d7ec8 7ec0: 00000000 c016044c c51f7e00 c41d0180 c5665980 000000be 00002c01 c5665980 7ee0: c51d7f0c c51d7ef0 c00a8378 c0222be8 00000006 c5665980 00000006 c5665980 7f00: c51d7f7c c51d7f10 c00a8a28 c00a8310 c560ab40 00000003 00000000 c5665980 7f20: c51d7f5c 00000000 00000000 c51e31f0 00000000 c41d0180 00000020 c51e31f0 7f40: 00000000 c41d0180 00000020 c51e31f0 c51d7f94 00000006 000000be 00002c01 7f60: c5665980 c002c0e4 c51d6000 00000000 c51d7fa4 c51d7f80 c00a8ac4 c00a84a4 7f80: c51d6000 00000000 bed14c9c 0002dcfc 000000be 00000036 00000000 c51d7fa8 7fa0: c002bf60 c00a8a94 bed14c9c 0002dcfc 00000006 00002c01 000000be ffffffff 7fc0: bed14c9c 0002dcfc 000000be 00000036 0002caac 00000001 00000000 00000001 7fe0: 00000002 bed14c98 00012ce0 40de1aec 20000010 00000006 ffffffff ffffffff Backtrace: [<c0222a3c>] (I2C_create+0x0/0x19c) from [<c0222c38>] (I2C_devIoctl+0x60/0x2e0) r7:00000000 r6:c5665980 r5:00002c01 r4:000000be [<c0222bd8>] (I2C_devIoctl+0x0/0x2e0) from [<c00a8378>] (vfs_ioctl+0x78/0x94) r7:c5665980 r6:00002c01 r5:000000be r4:c5665980 [<c00a8300>] (vfs_ioctl+0x0/0x94) from [<c00a8a28>] (do_vfs_ioctl+0x594/0x5f0) r7:c5665980 r6:00000006 r5:c5665980 r4:00000006 [<c00a8494>] (do_vfs_ioctl+0x0/0x5f0) from [<c00a8ac4>] (sys_ioctl+0x40/0x64) [<c00a8a84>] (sys_ioctl+0x0/0x64) from [<c002bf60>] (ret_fast_syscall+0x0/0x28) r7:00000036 r6:000000be r5:0002dcfc r4:bed14c9c Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8) ---[ end trace a73651bc713a1399 ]--- Segmentation fault /examples #
I dont know where I2C_LG come from?I only have I2C_IG and I2C_JG.
Maybe i should not add
};because mcvip example board-dm365-evm.c has no this line.
Could you show me your board c file?
and if i run mcvip_test.out without slave i2c config,mcvip_test.out begin to run.but it can't find /dev/video0.Could you tell me your /dev/video0 device major number and minor number?
i try "mknod /dev/video0 c 81 0 " and i get error msg : MCVIP: Starting. Please wait !!! ---- CAPTURE_tskMain ----- port: 0 CAPTURE: Alloc info: numCh=2 numBuf=8, bufSize=847872, allocSize=6782976 MCVIP_v4l2Create(TVP5158_1) video0 ERROR (mcvip_v4l2.c|MCVIP_v4l2Create|82): Device does not support desired video input! ERROR (capture_tsk.c|CAPTURE_tskCreate|96): MCVIP_create() ERROR (main.c|UI_sysStart|90): CAPTURE_create() MCVIP: System Exiting !!! MCVIP: Bye Bye !!!
any comment,any light,any help would be appreciated greatly!
best regards
I am using DVSDK 4.02, so my board definition will likely have things that are of no value to you yet. However, I can give you some pointers!
Don't add the TVP5158 to the i2c_info structure. Having it in the vpfe_sub_devs[] structure should be enough:
static struct vpfe_subdev_info vpfe_sub_devs[] = {#ifdef CONFIG_VIDEO_TVP5158 { .module_name = "I2C_JG", .num_inputs = ARRAY_SIZE(tvp5158_inputs_2), .inputs = tvp5158_inputs_2, .board_info = { I2C_BOARD_INFO("tvp5158", 0x5F), .platform_data = &tvp5158_pdata, }, .can_route = 0, .ccdc_if_params = { .if_type = VPFE_BT656, .hdpol = VPFE_PINPOL_POSITIVE, .vdpol = VPFE_PINPOL_POSITIVE, }, }, { .module_name = "I2C_IG", .num_inputs = ARRAY_SIZE(tvp5158_inputs_1), .inputs = tvp5158_inputs_1, .board_info = { I2C_BOARD_INFO("tvp5158", 0x5B), .platform_data = &tvp5158_pdata, }, .can_route = 0, .ccdc_if_params = { .if_type = VPFE_BT656, .hdpol = VPFE_PINPOL_POSITIVE, .vdpol = VPFE_PINPOL_POSITIVE, }, },#endif};
Also, you will likely have to go through the code and find places where it expects the second tvp5158 to be placed, and correct the code. I'm pretty sure that you will get a kernel "oops" if these are not resolved. Thankfully, these will present themselves quite visibly.
Here is the info for my /dev/video0:
crw-rw---- 1 root video 81, 0 Jan 1 1970 /dev/video0
However, you should not have to mknod these; udev should take care of that for you.
I've been looking through your TVP5158 driver posts today, starting w/your initial post on 2 Feb 2012. It appears that you are developing on the DVSDK 4.02 with a DM36x Davinci processor. Can I ask what h/w platform you are using - the DM36xEVM, or a custom board?
Thanks for the great tips you've been leaving wrt the 5158. I have the driver loading and initializing under the DVSDK 4.02 on a Leopardboard 368, but apparently it's not capturing frames correctly. Your hint about the vpfe_sub_devs[] may the last piece of the puzzle, at least for video capture. Keep up the good work.
regards,gifford scottDST
gifford,
I'm using the UDWORKS dvr reference design. It is very similar to the DM36xEVM, except it is missing SD cards, has different nand flash and has 2x TVP5158 units attached. I'm sure that there are other differences, but I've not run into them yet or they are not critical.
In the future (hopefully very soon) I will be using our custom hardware. Also, a little birdy let me know that DVSDK 4.03 is going to be released for DM36x "real soon now".
Good luck!
Many thanks for sharing your experience w/this driver. It looks like you're using the same DM365_DVR_DVSDK3_00.02.00.00 driver release that I am. It's a big concern for me that you are having these difficulties integrating the driver onto a udworks DM36x DVR reference design, given that the release notes for version 00.02.00 state that it was validated for the 2.6.32 kernel on a "DM365 DVR."
I see that you've been updating the forum since the start of February, wrt the 5158 driver. Would you be kind enough to give an estimate of how many weeks it might take to fully integrate this driver into a DM36x udworks DVR?
Well, I think that I've stepped on most of the land mines for you. That should be immensely helpful since I spent, in some cases, a few days digesting how ASoC works, etc.
Also, keep in mind that I am using DVSDK4.02 and not DVSDK 3.x, which might be the cause of some of my troubles.