From patchwork Thu Sep 26 13:52:37 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Jean-Philippe_Fran=C3=83=C2=A7ois?= X-Patchwork-Id: 2948331 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 08DE4BFF05 for ; Thu, 26 Sep 2013 13:52:55 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E841F20320 for ; Thu, 26 Sep 2013 13:52:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1CF412031A for ; Thu, 26 Sep 2013 13:52:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751023Ab3IZNwr (ORCPT ); Thu, 26 Sep 2013 09:52:47 -0400 Received: from mail-we0-f171.google.com ([74.125.82.171]:52420 "EHLO mail-we0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750895Ab3IZNwj convert rfc822-to-8bit (ORCPT ); Thu, 26 Sep 2013 09:52:39 -0400 Received: by mail-we0-f171.google.com with SMTP id t61so1198459wes.30 for ; Thu, 26 Sep 2013 06:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/BokUFVqijrRvpTu1gIenHeClglhNaHtEhPPOeAc9Eo=; b=oyO8IiNPn8DlUgoB1zVgnQvjUZnxjA5U483XzwaNN1Us2le1zOxAWzRF+smVlLqsQ6 0dWU8AvJqJTSEDOxcHqVnc5AVMfLSnpalc89jnrBulO6BlSw536pIxaRVQob15CyavnH qPBigdtM9r9ISojQkuYHB3d4at2GjbfNf8gxz0XJZ5BM40Mm9uYmuhJ9JpdtUrsN3b/i axNsVyMODGSYH5yMRQWz9vvh1ePgyOvZ0sTlSi6roZz1l7xGh2mFZijhXZqeAACr5njB p3lglTjToH9AXV2s3XMk6tRC5AiRrfxVakvK7ivjpvWoj1MEbe4VEM1EVp04IS0EUcKG 8BVQ== MIME-Version: 1.0 X-Received: by 10.180.99.3 with SMTP id em3mr23022594wib.4.1380203557919; Thu, 26 Sep 2013 06:52:37 -0700 (PDT) Received: by 10.194.164.2 with HTTP; Thu, 26 Sep 2013 06:52:37 -0700 (PDT) Date: Thu, 26 Sep 2013 15:52:37 +0200 X-Google-Sender-Auth: NmBku83RpsiMhtQ2V4SAzgGGJUg Message-ID: Subject: [RFC] omap3isp : fix image corruption after underrun when using resizer From: jean-philippe francois To: linux-media Cc: Laurent Pinchart Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. 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. 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 ? Thank you for your comments, Jean-Philippe François the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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