dm6467T EVM: Understanding VPIF - raw mode

Hi,

Below are answers to your questions

1, Bit0 is reserved bit, so only bit1 is used to indicate whether it is RAW mode or BT mode

2, Since it is video capture driver, it is based on V4L2 framwork. Driver takes care of updating VPIF registers, handling interrupts and buffer manangement, so applicaiton does not have to worry about it. You will have to enable support for the RAW capture mode, which is not supported in the current driver.

3a, For the RAW captuer mode, it has both the interrupts line interrupt and frame done interrupt.

3b, by header you mean VBI area?. If it is, you can have small VBI area.

4, as i said, you will just need to add RAW capture mode in the VPIF driver. It already supports BT capture mode.

Thx,

Brijesh Jadav

Hello Brijesh,

Thank you for the prompt response.

Regarding your answers:

1.  You mean bit0 of bits 1 and 2 of the register.  (I thought bit0 was the enable bit.)  To make you response more clear, you mean that bit1 is reserved and bit2 set to one would enable raw mode, bit2 set to zero enables BT mode.

2.  I realize there was a typo in my question so it might not have been clear.  Which driver do I need to add support to - the vpif driver or the v4l2 driver?  I meant to say that I don't think the v4l2 driver is needed to support raw mode. It seems to me that v4l2 is the portion of the driver that enables the capture and conversion of the analog signals to digital form (ycrcb etc.) For the vpif drivers though, I cannot not find support documentation with how to use the vpif driver itself.  What are the apis and controls?  The spruer9d is all I could find and this is merely a list of the registers.  Is there an ISR callback I need to set up to ensure I get the interrupt at end of frame? 

3a.  I see that there are two types of interrupts available, but what triggers each interrupt?  What causes an End of Frame interrupt to fire?

3b.  No, I would prefer not to complicate things by using the VBI since the extra data I want to send is only at the beginning of a frame not at the beginning of the line.  As I understand, enabling VBI will cause DMA actions during every raw_v_valid inactive point.  This will be a useless copy with the exception of the first line of the frame.  What I want to do is transfer say a 640*480+10 byte data stream.  Once the data is in SDRAM, I can use it how I see fit. 

3c. <NEW> Does the vpif do any conversion of data when it comes in as raw?  Or is it truly working as I understand and is just a data transfer device?

4.  I am not really experienced with drivers, how will I modify the current one to support raw mode?  Is there an example available somewhere?

Thanks again,

Brandy

Hello Brijesh,

is there any update on the questions above?

Thanks,
Brandy

Hi Brijesh,

You have been very helpful in clarifying, thank you!

Just one more question about point 3b:  I thought raw mode did not have SAV/EAV requirements.  In raw mode, I thought the only indicator about line/frame size was the raw_h_valid and raw_v_valid.  Please confirm.

Thank you also for looking for an example, any little bit will help.

Brandy

Brijesh,

I don't want to hijack this thread, but this seems like a good background to start this discussion:

1.  I am doing something very similar to what is being described above

2.  We have a custom built camera that is attaching to the VPIF, and we want to capture the raw data to the Linux filesystem

3.  We are now attempting the driver mods required to get everything working in raw mode:

    a. We have defined a new V4L2 standard that we call V4L2_STD_1080P_60_RAW and added it to appropriate places so it is recognized as a supported STD

    b.  Here is a code snipped from the modified vpif_capture.c

104    {
105       "1080P-60", 1920, 1080, 60, 1, 0, 272, 1920, 1, 42, 1122, 0,
106       0, 0, 1125, 0, 0, 1, V4L2_STD_1080P_60,
107    },
108    {
109       "1080P-60R", 1920, 1080, 60, 1, 0, 272, 1920, 1, 42, 1122, 0,
110       0, 0, 1125, 1, 0, 1, V4L2_STD_1080P_60_RAW,
111    },

    c.  I have included the 'normal' 1080p definition in the snippet above for comparison.  Note that little else has changed.  The one thing that has changed is the 16th parameter.  This parameter should put the VPIF into raw mode in the configuration register discussed in the above commentary.  This happens at approx line 162 in the config_vfpi_params function which resides in vpif.c.

    d.  The SPRUER9D data sheet has some abiguity about what interrupts are supported in raw mode. 

         From discussion of interrupts in raw mode on page 23:

        "Two kinds of interrupt support. One is asserted once per each configured line size (line_interrupt) and the other is asserted at the end of the capture area (frame_interrupt). See Figure 10. Note that line_interrupt is only supported in raw mode. In other modes (BT.656, BT.1120, and SMPTE 296M), line_interrupt is not supported."

        However, in the register description of field INTEN_FRAME_CH1 on pg 49, the documentation states:

        "In raw capture mode, this bit controls the line-level interrupt enable. It depends on the value of the CH0_FORMAT bit in CH0_CTRL, if CH0_FORMAT = 3h, this bit is prepared for line-level interrupt control, if CH0_FORMAT = 0, this bit is prepared for frame level interrupt.

        Since the CH0_FORMAT field determines if the device is in raw mode or not, (2h or 3h for raw mode), then it would appear that the interrupt can only be set for line mode.  How does this really behave?  Based on some initial evaluation of observed interrupts, it tend to think I am getting frame interrupts rather than line interrupts which isn't what I expected to see at all.

    e. In the chain above, your statements lead me to believe that something would have to change in the ISR to support the raw mode.  If we are getting frame interrupts hitting this ISR rather than line interrupts, what would need to be changed?  I would have guessed nothing, since the action the ISR should take is to return a single buffer for user space to consume and then to schedule another buffer for kernel space to store the next captured frame.

    f. My initial observations expose some problems along the way.  Here is what I see:

        i.  We verify that our camera is outputting valid data and control signals with a scope/logic analyzer.  This is measured between the mux and the processor on the back of the davinci evaluation board.  This leads me to believe the camera is doing the right thing.

        ii.  We connect the camera to the VPIF, and point it at a bright light and start the VPIF.  The first 46 or so lines come back as 0xFF; the rest of the lines come back as zero.

        iii.  We put our hand over the camera lens and execute the capture code once more.  The first 46 or so lines come back as some very small number, (the number is exactly the same

         iv.  We command the camera to display a test image, (ramp data), and execute the command once more.  We get zeros for the entire frame when there should have been consistently incrementing numbers.

        v.  My initial guess at what is happening is that the DMA controller is getting the first pixel/value and writing it to SDRAM many times, and then eventually quits or gives up without writing any new updated values.  Do you have any idea what could cause the VPIF to behave in this manner?  I have checked the values that are being set in the CH0_TOP_START_ADD_LUMA and it seems sane.  Same with the CH0_IMG_ADD_OFST register; it seems to be set correctly as well.  My understanding is that when in raw mode almost all other registers will be ignored.

4.  There is clearly a bug at ~line 178 in vpif.c in function config_vpif_params.  The line of code:

176          value &= ((~(unsigned int)(0x3)) <<
177                VPIF_CH_DATA_WIDTH_BIT);

The bitwise not should not be executed before the SLL.  This leads to the value being bitwise and'ed with something that has zeros after the bits of interest.  It ends up clobbering important configuration bits.

Thanks much for the help,

Nate Jensen

Space Dynamics Lab

Hi Brijesh,

I am facing big trouble in camera implementation on AM1808.

Sensor: OV3640 (still image camera connected over I2C Bus), This is the only device over I2C bus.OV3640 driver is available but work for OMAP34xxcam as said.

OS Kernel: Linux 2.6.32.

I am new to the V4L2 framework, First confuse which V4L2 framework to adopt( soc, int-device OR sub-device) for V4L2 driver development.

And how  V4L2 Driver, vpif.c,vpif_capture.c, vpif_display.c and Sensor are interfaced in software to function.

If  you will help me how these different-2 software module are interfaced with each other will be great help.

Regards,

Gajendra(Gajendra_Singh@mindtree.com)

Hi,

I would suggest to go with the sub-device frame works as it is generic and used by many devices. Once you write your slave device using the slave device framework, it could be used by others also. int-device is very specific framework and used by only OMAP drivers.

Sub-device framework is kind of master-slave framework, in which video port is master driver, which implements all V4L2 ioctls and decoder/encoder drivers are slave drivers, which will be called by the master driver when it is required. vpif_capture.c file implements the master driver for the VPIF capture and vpif_display.c implements master driver for the VPIF display. vpif.c file is used to configure VPIF hardware. The API's implemented in vpif.c file will be called by both capture and display driver to configure VPIF hardware. VPIF capture and VPIF display drivers calls slave drivers like decoder and encoder driver to configure them. There is standard interface between master and slave.

Let me know if you need more information on this.

Thanks,

Brijesh Jadav

Hi,

If i remember correctly,  in the raw capture mode, there are two kinds of interrupts supported in the VPIF , line interrupts, which comes after specified number of lines are captured and frame interrupt, which comes when a complete frame is captured in the memory. When VPIF is configured for the RAW capture mode, channel2 interrupt provides the frame interrupt and channel3 provides the line interrupt.

Why i said that the current driver requires some changes is because we have not tested the RAW capture mode on VPIF, it may have bugs and also may require some changes.

I am not sure why are not getting correct frame. I do not think DMA controller is writing first pixel all over frame. DMA controller writes what it gets from capture, ultimately from external source. Can you check if you have some test mode in your sensor? Are you seeing interrupt counter getting incremented? you can check this in /proc/interrupts. Can you also clear the frame before giving to the capture driver and see if something is captured in it after driver returns it back?

Thanks,

Brijesh Jadav

Brijesh,

We were able to get things working in RAW mode.  Eventually it came down to just getting the right combination of register settings.  I think the datasheet isn't super clear in a lot of places what the magic combination is.  All in all, there wasn't a huge amount of changes that had to be made to the driver to get it to work in RAW mode.  A few lines to define our new standard, and then a bit of effort to make sure that both channels are configured appropriately.

FWIW, the post below was a big help.  It doesn't name our part by name, but as i was looking through the site, this seemed to have all the right registers and what they needed to be set to in order to get the device working like we wanted it.  We translated the settings specified in the post into the Linux driver and all was well after that.  Thanks much for the help along the way!

http://e2e.ti.com/support/embedded/f/354/p/71581/259811.aspx#259811

-Nate

Hi Nate,

Can you please share the register settings you have used for RAW mode capture in VPIF?

Thanks,

Brijesh Jadav

Dear Brijesh,

Thanks a lot for your explanation about the different components in OMAP  V4L2.

I am adopting the sub-device framework as per your advice,and taking the vivi driver as a reference but in vivi hardware interface part is missing and even no comments how to access sensor from here.

This will be great help if you would explain me which data structure in sub-device framework will bridge the V4L2 master & Slave together and how.

Thanks & Regards,

Gajendra.

Hi Gajendra,

We have developed slave devices based on sub-dev frame work. These drivers are on dm6467. Please go through one of these drivers to get the idea about how to write a sub-device slave driver. These drivers are for the devices TVP7002, THS8200 and ADV7343. You can get the drivers for these devices on the Linux kernel. I would suggest to look into ths8200 driver as it is the simplest one, just few API's.

Let me know if you still have doubt about it.

Thanks,

Brijesh Jadav

I am using 12 bit raw mode, V4L2 driver seems not support this one, is there a way to have simple low level capture mechanism, if so, where is SDRAM address should use to get the data from 12 bit raw mode capture ?