Need help for omap3 isp bt656 interface

The physical bt.656 interface is relatively simple, but in the case you are looking for a reference to verify that there are schematics for the Mistral Multimedia Daughter Card available here on the wiki that show the connections to a TVP5146. Along the lines of the physical interface, have you verified that PCLK is properly oscillating and that the data bus is transitioning properly?

From a software perspective, I assume you are using Linux? If so you may want to leverage the existing TVP5146 driver that is included with the current OMAP3 SDK 1.0.2 (OMAP35x_SDK_1.0.2\src\linux\kernel_org\2.6_kernel\drivers\media\video\tvp5146.c), as that should be configuring the ISP to take in a bt.656 stream and should be relatively easy to modify to work with the TVP5150, primarily just changes to the values written over I2C to the TVP5150 video decoder.

That's right, I use linux PSP 1.0.2, and adapted tvp5146.c to meet our needs. The 8 bits BT.656 go to cam_d[4-11], pclk goes to cam_pclk, I see the FLDSTAT(CCDC_SYN_MODE) bit toggles, but nothing else. I setup cam_d[4-11] and cam_pclk as GPIO, I do see the bits toggle, so they are correctly wired. Are there any special things I have to check regarding cam_d[4-11] and cam_pclk?

The multimedia daughtercard appears to have the data bus hooked up to cam_d 0:9 as opposed to 4:11, I have not done much digging into the video capture pins on the OMAP3 in this regard beyond the daughtercard schematic, but if your data bus was not aligned properly that could explain the trouble.

That's correct, however, PSP 1.0.2 set the ISP_CTRL.SHIFT = 2, it should shift 4 bits, in this case, the multimedia daughtercard should never work with PSP 1.0.2.

In the document OMAP34XX_ES2.0_ES2.1_TRM_V_D.pdf, section 12.1.1 Camera ISP features, page 1584, ITU mode: it supports only progressive image-sensor modules.

What it means? Our camera module works in interlace mode.

Hi,

I'm also working on this problem. I've conntected the TVP5150 to the omap3530 isp and now I could see a picture using the saMmapLoopback example. Unfortunately the application or v4l hangs after a few minutes. The working period differs between <1 and 45min.

I've found out that videobuf_waiton in drivers/media/video/videobuf-core.c is not returning from wait_event_interuptable. Any ideas how to solve this issue?

hi,

I read your reply and think that you may help me with my problem.

My situation is that I have none decoder chip such as 5146 or 5150 that you mentioned above. My video source is DM6467 BT656 output. I just connect the stream directly to omap3530 camera isp, including 8-bit data and a pclk which I believe to be 27MHz. What I mean is that DM6467 provide the pclk and the 8 bit data to omap3530 and omap3530 capture the video data and display it.

So I modify a driver according to tvp514x.c. This driver don't have to connect with any decoder chip. Right now, I can't  get video through the saMmapLoop example. The problem is that the BT656 input cause none interrupt.  I wonder how to configure the isp to take in bt.656 stream to fit my situation. 

I hope you can help. Thank you!!

Hi,

I wasn't able to make it work in ITU BT.656 mode. However, SYNC mode works nicely, in this mode, you have to setup cam_fld as input.

gook luck.

HI,

Thank you for your reply. So I want to know how to configure the isp to work in ITU656 mode. Can I configure it in the saMmapLoopback.c application??

Bernie Thompson said:

The multimedia daughtercard appears to have the data bus hooked up to cam_d 0:9 as opposed to 4:11, I have not done much digging into the video capture pins on the OMAP3 in this regard beyond the daughtercard schematic, but if your data bus was not aligned properly that could explain the trouble.

I have a question, should the 8-bit data bus be connected to cam_d[11:4], what if I connect them to 0:7?

I believe that I have finish the configuration, however, the BT656 data and the pclk cause none interrupts. What is my problem?[

what do you mean by saying " see the FLDSTAT bit toggles"? how do you check it?

By reading the register ISP_CCDC(0x480BC608) bit 15(FLDSTAT), its value toggles.

I see no toggles of this bit? do you know what's the possible reason?

Is your camera input in BT.656 mode or raw mode? DM6467 supports BT.656 and raw mode. If you setup the DM6467 in raw mode, the pin cam_fld as input, it should work.

Hi All,

I m working on omap3 and camera (tvp5150 ) too. but ı can not find a video driver for tvp5150 work with omap3530. there is a driver work on linux. how can ı make work tvp5150 with omap. there is a driver for tvp5150. how can ı active /dev/video0 with tvp5150.

Thank all

Hello Bernie,

I have a question regarding your statement from above: "If so you may want to leverage the existing TVP5146 driver that is included with the current OMAP3 SDK 1.0.2, as that should be configuring the ISP to take in a bt.656 stream". Are you sure the ISP on Mistral's is configured to take in ITU-656? OMAP TRM states that ITU-656 stream may only be input when scanned "progressive". Since the TVP5146 allows only interlaced output this seems wierd. For it to send ITU-656 formatted stream to OMAP, OMAP's ISP has to be able to accpet interlaced data. In order to receive interlaced data OMAP's ISP has to be configured in SYNC mode only and not ITU. Is this a mistake?

Thanks,

Matan

Matan Medalion said:

Are you sure the ISP on Mistral's is configured to take in ITU-656? OMAP TRM states that ITU-656 stream may only be input when scanned "progressive". Since the TVP5146 allows only interlaced output this seems wierd. For it to send ITU-656 formatted stream to OMAP, OMAP's ISP has to be able to accpet interlaced data. In order to receive interlaced data OMAP's ISP has to be configured in SYNC mode only and not ITU. Is this a mistake?

You make a good point, the OMAP is taking in BT.656 input, and it is interlaced, the problem here is the TRM which has that 'progressive only' statement which is a bug in the TRM which should be removed in a future version.

The ISP on the OMAP35x has been tested to capture interlaced video with embedded syncs (i.e. BT.656) with success.

Dear Wending,

When you say FLDSTAT bit "toggle", do you mean that the bit change its value between 0 and 1 in phase with the field change?

Because in BT.656 mode field 0 and 1 comes alternatively in the stream, and it seems that according to the document (you are using omap3? I am on a DaVinci 6437 EVM) FLDSTAT is the 15th bit of SYN_MODE, and according to the document (SPRU977a, 643x VPFE User's Guide, page 126, table 58 "Sync and Mode Set Register (SYN_MODE) Field Descriptions". Although it might be different from your OMAP ARM + DaVinci combination, I think this SYN_MODE should be similar)

Field Status. Indicates the status of the current field when in interlaced mode.
0        Odd field
1        Even field

So if we have an interrupt service routine being triggered by VD associated with the beginning of each field, we should be able to see the toggling between 0 and 1 every time we entering the interrupt service routine.

But in my experiment, although I do observe change in FLDSTAT, it is not regular. At most times it does NOT toggle regularly at new field (I am watching SYN_MODE in ISR, triggered by VDINT0), but could remain at either 1 or 0 for several fields before switching to another. For example, the observed pattern of FLDSTAT between consecutive fields could be like:

11110001111011101

Which is different from the document's description (SPRU977a).

What about your case? Did you eventually get this problem solved?

      
Sincerely,
Zheng

Dear Zheng,

I have never made it work in BT.656 mode, however, I managed to make it work in raw sync mode.

Wending

Dear Wending,

Wending Weng said:

By reading the register ISP_CCDC(0x480BC608) bit 15(FLDSTAT), its value toggles.

How did you read that? Did you

1. Like my case, check ISP_CCDC.FLDSTAT on your OMAP 3 in interrupt breakpoints, like in the picture I have attached?
2. Log its value into as an entry into an array in each execution of the interrupt service routine trigger by each VD, and examine it afterwards?

Could you let me know the exact method you used to "read" the value? There can be lots of unexpected behaviors when debugging a real-time system, and it might be that although our "reading", of which there are severl different methods, did not get the right value, the bit actually changes in the pattern as described  in the manual. Perhaps we need to ensure a sufficient delay time before VD and our reading attempt for the updated field ID to get latched on FLDSTAT bit after the VD (considerations include : VD length as specified by VDW, VD polarity as specified in VDPOL, etc.).

Sincerely,

Zheng