Message ID | CAGGh5h0-MKY9ZzkktoCbkfgrC_1u5Pp2i11xE8uEP2sjALQJ2Q@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hi Jean-Philippe, On Thu, Sep 26, 2013 at 03:52:37PM +0200, jean-philippe francois wrote: > Hi Laurent, > > I was able to reliably get corrupted image when placing the pipeline in underrun > condition. The pipeline looks like this : > YUYV sensor -> CCDC -> Resizer -> V4L output > > It seems that triggering 'frame sync event' before last line leads to > possible corrupted images > when using the resizer. I think this was rather understood to be somewhat unoptimal way to trigger the interrupt at the end of the frame. > With current code, ISP resizer is always configured in oneshot, and > must be restarted after > each frame. However, has stated by a comment in ispresizer.c, > restarting the resizer while > a frame is sent to the ccdc leads to corrupted images. > > The current resizer code takes care of this restart in two places : > > - in normal situation, when the 'resizer done' IRQ is triggered, a > buffer is available > and the resizer is restarted in the resizer_isr_buffer function > > - in underrun situation, no buffer is available when the resizer done > irq triggers. After a buffer > has eventually been queued, the resizer is restarted on the following > frame sync. > > However, the frame sync event is not generated by the hardware frame sync, > but by the VD0 interrupt of the CCDC. But VD0 event is triggered a > bit early, since it is > configured to trigger after height - 1 lines. It is therefore possible > to restart the resizer while a frame's > last line is being sent. I guess one should then wait for the CCDC to become idle as well. Currently this is not being done --- i.e. ccdc_sbl_wait_idle() should then be called first. > The following patch configures VD0 to trigger after the last line, and > solves the image > corruption issue. However, the previous value does not look like an > off by one error. > What are the reasons to configure VD0 before the last line ? What are > the possible issues > triggered by a change like this ? The VD counter is incremented by the hsync singal. Depending on the polarity, the value of the VD counter at the beginning of last line is either height - 2 or height - 1, and this should be reflected in the configuration as well. Which one do you have?
Index: b/drivers/media/platform/omap3isp/ispccdc.c =================================================================== --- a/drivers/media/platform/omap3isp/ispccdc.c +++ b/drivers/media/platform/omap3isp/ispccdc.c @@ -1196,7 +1196,7 @@ /* Generate VD0 on the last line of the image and VD1 on the * 2/3 height line. */ - isp_reg_writel(isp, ((format->height - 2) << ISPCCDC_VDINT_0_SHIFT) | + isp_reg_writel(isp, ((format->height - 1) << ISPCCDC_VDINT_0_SHIFT) | ((format->height * 2 / 3) << ISPCCDC_VDINT_1_SHIFT), OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT); -- To unsubscribe from this list: send the line "unsubscribe linux-media" in