dm368 resize 阻塞解决办法

转自：http://e2e.ti.com/support/embedded/linux/f/354/t/132038.aspx

[This post was split from this thread V4L2 Capture buffers with old data DM368 ]

I'm seeing the same, or a similar issue using the resizer in single-shot mode on the DM365 with DVSDK 2.0.  When the ARM CPU has over 50% load, and there's lots of DMA transfers going on, occasionally the Resizer_execute function will return early, and the resized output frames will be incomplete.  Normally resizing my 720x480 NTSC source image takes 9ms, but sometimes it would take only 1-2ms.  Based on the advice in this thread, I checked the RSZ_EN register in the imp_common_isr and occasionally the resizer is still enabled when the interrupt arrives with RSZ_INT_DMA flag set in INTSTAT [1].  The interrupt doesn't fire again if I keep waiting. If I try to run the resizer again immediately after the early return, it never gets an interrupt, effectively locking up as described in that other thread.  Can anyone explain what causes the VPSS interrupt to be triggered early with RSZ_INT_DMA set?

My workaround is to poll the RSZ_EN register until clear after getting the completion event from the interrupt.  Here's the code change for DVSDK 2.0:

In drivers/char/imp_common.c:imp_common_start():

    wait_for_completion_interruptible(&(imp_serializer_info.sem_isr));

    if (!prev && cpu_is_davinci_dm365()) {
            /* under rare conditions the resizer may complete early,
             * and if we try to run it again too soon, it may lock up
             */
        while (davinci_readl(0x1c70400)) /* poll RSZ_EN until clear */
            msleep(1);
    }

Also add: #include <linux/delay.h>

[1] The SPRUFG8 document shows RSZ_INT_DMA to be bit 15 in the INTSTAT register, but the field descriptions incorrectly show bit 15 to be Reserved.