dm6467 Raw Mode (has anyone got this working?)

Nathan Jensen said:

    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.

I agree the documentation is a bit confusing here, my interpretation is that it is really always in ‘line_interrupt’ mode when in RAW mode practically speaking, and that you would get a ‘frame_interrupt’ only in the other non RAW modes, or by setting CH0_CTRL.INTERVAL_LINE_INT to the number of lines in your frame. This being said, I suspect your INTERVAL_LINE_INT value happens to be your frame height in your current configuration.

Nathan Jensen said:

   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.

Based on the documentation, I suspect you would have to change the CH0_CTRL.INTERVAL_LINE_INT value to the number of lines between interrupts you want; it seems like setting this to 1 would give you a true line by line interrupt.

Nathan Jensen said:

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.

For your observed problems, there are a few possibilities that you may want to consider, though it is hard to say what is actually happening here.

1.    At a hardware level it may be worth ensuring that the clocks and syncs are clean and at proper voltage levels for the DM6467, I suspect this is ok because you are actually getting an interrupt eventually, but this may be worth checking. Additionally for hardware you may want to double check your connections and ensure nothing else can be blocking the signals from hitting the right pins on the chip.
2.    Another possible explanation would be pin multiplexing, this seems unlikely but is worth double checking.
3.    At a software level it may be worth taking a look at any cache/buffering code to ensure you are actually seeing the data that the VPIF is dumping into memory, this should be handled by the capture driver out of the box however, so it also seems unlikely.

To dig into this further, it may be worth making a few dumps of the VPIF registers when running your test to see if anything jumps out as to a potential configuration problem (at a minimum we can verify your settings match what the registers contain), nothing immediately comes to mind as to what could cause a single value to be dumped into memory however.

Nathan Jensen said:

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.

I agree with your assessment of line 178 in vpif.c, that does look suspect, I am not sure how much the raw mode for the VPIF is tested with the Linux drivers, and it looks like this only gets hit when configuring for raw.

Nate/Bernie,

Thanks for your posts, they have been helpful in getting the raw capture mode working. Just in case anybody else is still having problems with this, here's what I had to do with respect to the Channel Control Registers (this is assuming that a mode has been created with the raw bit set as Nate describes above):

Nathan Jensen said:

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.

Agree - I changed this to 

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

Hi,Richard!

I had a preblem when I set the vpif register to recv raw data.Did you success it?I set it to recv a 12 bit data,normally ,like the spruer9d.pdf in Page 25,the data must be something like this:0x0x 0xxx,but what I recv data is something like this:0x58 00.What problem with it?Can you help me ?Thanks!