DMA usage in VPFE usage examples

Hi Steve,

I am also previewing the paper SPRUFG8. Did you read the part of H3A statistic collection part ?

There are some puzzles in the packet data Sub Sample Accum[1], Sub Sample Accum[0],

Sub Sample Accum[3], Sub Sample Accum[2] when I analyze the statistics coming from AE/AWB engine.

How did those data gotten in detail? Could you give me some explanation, thank you very much.

Best Regards,

Giant

Thanks, Anshuman,  for the response.  Now I understand why I've not been able to find any setup for the edma.  Thanks for clarifying.

You asked "Are you using DVSDK demo in chained mode capture driver or are you using it in non-chained single shot mode?" 

I am using the do_preview_resize program from the examples-r37 of the DVSDK3.10.  This program puts the previewer and resizer both in SINGLE-SHOT mode and they are chained.    I'm using a new sensor for which I've developed the driver.   It is a 10 megapixel MT9J003 from Aptina/Micron.   It is similar in character to some of the other Aptina/Micron sensors.  Differences include approx 3664x2748 pixels (Bayer pattern of course) and most of the registers are 16-bits in width.  There are mroe than 256 registers (far more) so the sensor uses 16-bit register addresses as well.   I had to do some work to add the 16-bit register access (with optional 8- or 16-bit data width) routines to the I2C part of the driver.  That all works well at this point.

I think my main confusion (and this is probably what is hanging the resizer) is that I don't know what width and height to set in the sensor so that there is enough (but not too many) pixels emerging from the sensor and entering the capture pipeline.  I've tried a *lot* of combinations and it still isn't working though I've seen streaming video work once or twice).  I shoudl mention that for streaming video I use a modified version of the capture_prev_rsz_onthefly_bayer program from the examples.   That one puts the previewer and resizer into CONTINUOUS MODE and they re chained.  Neither the continuous nor the single-shot mode are reliably working for me.

Some specific info:  In the do_preview_resize test program I've made almost zero changes.  In fact, my changes have only been to correct typos and add some printf statements.  I don'

t think I've changed anything meaningful .... and since that program doesn't use the sensor at all my problems certainly have nothing do with my new sensor driver(!).   I'm running on a Leopard camera board from their EUCDK with a changed sensor.  One thing I did have to do was make the board configuration file since Leopard's setup was for a much older kernel.  This configuration was not made without issues.  I found it quite challenging to do this and probably my issues lie there.   I started with the DM365 EVM board's configuration and made changes off that.  The Leopard board has no video decoders on it and no CPLD, for example.   Whatever I did, it seems very nearly right because I do get images from my sensor every once in awhile during the development.   I just need to know for example what the settings mean and where they go.

A short excerpt from the capture_prev_rsz_onthe_fly_bayer.c source follows.  I'd very much like to know your advice on the proper values for .scan_width, .scan_height, .crop, and .image_width, .image_helght.   Are the .scan_width and .scan_height the *exact* width and height emerging from the sensor?   Is the image_width, image_height the final size that is desired *after* the resizer?    These sort of questions are what I'm struggling with.

struct capt_std_params mt9j003_std_params[MAX_STDS] = {
    {   
        //.std = V4L2_STD_MT9J003_VGA_30FPS,
        .scan_width = 672,     // must be multiple of 32 (?)
        .scan_height = 496,    // must be multiple of 32 (?)
        .crop = { 1464, 1136, 640, 480},       
        .image_width = 640,
        .image_height = 480,
        .name = "V4L2_STD_MT9J003_VGA_30FPS",
    },
    {
        //.std = V4L2_STD_MT9J003_720p_30FPS,
        .scan_width = 1280,
        .scan_height = 720,
        .crop = { 0 , 0, 1280, 720},
        .image_width = 1280,
        .image_height = 720,
        .name = "V4L2_STD_MT9J003_720p_30FPS",
    },
};

 Finally you asked "is your VIDIOC_DQBUF call not returning the captured buffers and hanging forever?"  

Yes, that's exactly what's happening.   I've put in some timeouts (actually they are retry counts) that amount to about 2 seconds.  After the timeout I try somethings like changing the width and/or height emerging from the sensor.   I know that the previewer/resizer does not support changes to width or height on the fly but I've put in a special ioctl to my sensor driver that allows such changes.  The previewer and resizer do not know that such changes are happening.   And, they would not be happening unless there was a stall in the first place.    In past runs I've actually had the system spring into correct operation due to these changes.  So, I'm quite confident that the changes in width/height are the right thing to do.   if I could only get them correct in the beginning!!!!

Thanks for any help or insight on these issues.

One more bit of followup that I forgot to mention.   In trying to track down the reason for the stall in the do_preview_resize example I have discovered that it is IRQ 5 (IPIPE_INT_LAST_PIX) that is expected.   This IRQ has the symbol  IRQ_PRVUINT and it is delivered to the caller by the routine ipipe_get_irq() whenever called.  This routine's address is in both the .get_rsz_irq and .get_preview_irq fields of the struct imp_hw_interface dm365_ipipe_interface in the file dm365_ipipe.c.   With this IRQ being used as the one we are waiting for I was surprised to see that the INTSEL1, INTSEL2, and INTSEL3 registers do not (according to the way I understand it) permit the VPSS to cause as interrupt!  Thus, I don't see how this program (nor *any* chained single-shot prviewer/resizer setup) could ever work.   Is there something else I'm missing?

The INTSEL* registers captured during the hang are shown below.   Note that there is no "05" anywhere and thus IRQ 5 is not "armed" as an interrupt-producing output of the VPSS subsystem.   Also note that in the INTSTAT register one can see that bit 5 is set ...... demonstrating that, in fact, the ipipe has finished.   Interesting.

INTSEL1                                                                                                              
Value at address 0x1c70010: 0x0b1f0100                                                                                
                                                                                                                     
INTSEL2                                                                                                              
Value at address 0x1c70014: 0x1f0a0f1f                                                                               
                                                                                                                     
INTSEL3                                                                                                              
Value at address 0x1c70018: 0x00000015                                                                                     
                                                                                                                     
EVTSEL                                                                                                               
Value at address 0x1c7001c: 0x00000000                                                                                      
                                                                                                                     
INTSTAT                                                                                                              
Value at address 0x1c7000c: 0x00306236 

Comments?

Hi Steve,

Steve B13705 said:

The INTSEL* registers captured during the hang are shown below.   Note that there is no "05" anywhere and thus IRQ 5 is not "armed" as an interrupt-producing output of the VPSS subsystem.   Also note that in the INTSTAT register one can see that bit 5 is set ...... demonstrating that, in fact, the ipipe has finished.   Interesting.

This confused me too at first - in fact the interrupts for the VPSS subsystem are multiplexed, so the configuration for IRQ 5 (named PRVUINT in that header file) is determined by the value of INTSEL2 bits[12:8], as shown in Table 6-304 and Table 3-3 of the document sprufg8b. 

You have:

Steve B13705 said:

INTSEL2                                                                                                               
Value at address 0x1c70014: 0x1f0a0f1f

Steve B13705 said:

INTSTAT                                                                                                               
Value at address 0x1c7000c: 0x00306236 

where INTSEL2[12:8] == 0x0f, indicating that Event no. 15 from Table 3-2 is multiplexed to IRQ 5.  According to the documentation, Event 15 is Reserved, however it seems to be in fact the RSZ_INT_DMA event which is supposed to fire when a Resizer SDRAM DMA transfer is completed.  Bit 15 of your INTSTAT register is 0, which I believe means that it has in fact not finished.

What brought me here is that I am also encountering a problem with this particular interrupt.  I am using DM365 + TVP5146m2 on a custom board to capture a composite PAL video stream, which is working pretty well except that occasionally something goes horribly wrong.  The symptom is that the DVSDK encode demo (I'm using DVSDK 4.02) will run but it reports 0fps and then fails to terminate (presumably because no frames have been encoded).  I did a "cat /proc/interrupts" and saw this:

  0:     100954       AINTC  vpfe_capture0

  3:          0       AINTC  dm365_h3a_af

  5:          0       AINTC  Imp_Sdram_Irq

  6:          0       AINTC  dm365_h3a_aew

  8:     256229       AINTC  davinci_osd

  9:        100       AINTC  IRQK_Handler

After rebooting (via the CPU's Reset pin - a simple OS reboot didn't help) this shows the interrupts when the encode demo is running successfully:

  0:       1037       AINTC  vpfe_capture0

  3:          0       AINTC  dm365_h3a_af

  5:       1050       AINTC  Imp_Sdram_Irq

  6:          0       AINTC  dm365_h3a_aew

  8:      13978       AINTC  davinci_osd

  9:        516       AINTC  IRQK_Handler

So for some reason the Imp_Sdram_Irq (which should be RSZ_IRQ_DMA as far as I can tell from the driver code) interrupt is not being triggered.  I have no idea what could be causing this :(  With an oscilloscope I can see that there is an analogue video signal at the TVP's input, and that there is activity on it's Y and C output buses going to the DM365's digital video inputs.  What I'm trying to figure out is where exactly this DMA transfer gets set up so I can then try to see whether it's being set up incorrectly, or not at all, or does it just break sometimes, or is the problem somewhere further up the pipe...  Anyone have any suggestions?

Anshuman Saxena said:

In continuous (chained mode) operation, the dma completion interrupt might not be enbled at all.

D: Why would that be?  At any rate, it is being enabled when the encode demo works for me, so if it isn't being enabled when I see this failure, then why?

Anshuman Saxena said:

If you have changed the settings, specifically frame configurations, in your sensor or TVP driver, then it is possible that your interrupt might not come, if the VPSS capture module is not configured correctly.

I haven't changed any of that.  Since the video capture works on a cold boot and then eventually sometimes will break, what I imagine is happening is some register or static variable is getting set up correctly at first, then getting messed up in some way (how?) and then not getting reconfigured with correct data after that.