From patchwork Mon May 19 12:32:57 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arun Kumar K X-Patchwork-Id: 4201761 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 2711D9F1CD for ; Mon, 19 May 2014 12:33:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 58466200DC for ; Mon, 19 May 2014 12:33:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A26C200E6 for ; Mon, 19 May 2014 12:33:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754527AbaESMdQ (ORCPT ); Mon, 19 May 2014 08:33:16 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:50112 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754306AbaESMdP (ORCPT ); Mon, 19 May 2014 08:33:15 -0400 Received: by mail-pa0-f45.google.com with SMTP id ey11so5734364pad.32 for ; Mon, 19 May 2014 05:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=44qcUwLPxM2n6QWjdiPdlXdkVUnhjrx2ffF8C1mL6dQ=; b=JmLHUaeF42kLSQ39U8mPGizcEXJ1rFZ+I3HTVO2Wx9FPq33z9/FsIjSkEp2uZGmoNk ialDH5nlzuRr4K1JNjDY4GIpoM50r7kC5VCs6dwrqbcx3TcdSa6RQWqn2OGyl+070rZu Q8RU7RafA2Fpv94J9xuHu8FK0u2sV9HXnAasCsG9lsi9O9yMmENcYYBtxMxihc+0spfa smCvZLhXnu5U9zjBulflOHXbG52HVoFS7Gyg2xW8LMRRWy+l/pJLcKswYO9cLPMgu2H/ tQ4/BcR5FyWNRt6NM04KTQ/v2u/p6A4+oGjBurdibApHLyR9hI3oPUA6Mv2Qyn6dz6g0 QNrw== X-Received: by 10.66.240.197 with SMTP id wc5mr42702906pac.78.1400502794784; Mon, 19 May 2014 05:33:14 -0700 (PDT) Received: from localhost.localdomain ([14.140.216.146]) by mx.google.com with ESMTPSA id bz4sm29931786pbb.12.2014.05.19.05.33.11 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 05:33:14 -0700 (PDT) From: Arun Kumar K To: linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org Cc: k.debski@samsung.com, posciak@chromium.org, avnd.kiran@samsung.com, arunkk.samsung@gmail.com Subject: [PATCH 01/10] [media] s5p-mfc: Copy timestamps only when a frame is produced. Date: Mon, 19 May 2014 18:02:57 +0530 Message-Id: <1400502786-4826-2-git-send-email-arun.kk@samsung.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1400502786-4826-1-git-send-email-arun.kk@samsung.com> References: <1400502786-4826-1-git-send-email-arun.kk@samsung.com> Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable 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 From: Pawel Osciak Timestamps for destination buffers are assigned by copying them from corresponding source buffers when the decode operation results in a frame being outputted to a destination buffer. But the decision when to do this, i.e. whether the decode operation on current source buffer produced a destination frame, is wrongly based on "display status". Display status reflects the status of the destination buffer, not source. This used to work for firmwares version <= 6, because in addition to the above, we'd check the decoded frame type register, which was set to "skipped" if a destination frame was not produced, exiting early from s5p_mfc_handle_frame_new(). Firmware >=7 does not set the frame type register for frames that were not decoded anymore though, which results in us wrongly overwriting timestamps of previously decoded buffers (firmware reports the same destination buffer address as previously decoded one if a frame wasn't decoded during current operation). To do it properly, we should be basing our decision to copy the timestamp on the status of the source buffer, i.e. "decode status". The decode status register values are confusing, because in its case "display" means "a frame has been outputted to a destination buffer". We should copy if "decode and display" is returned in it. This also works on <= v6 firmware, which behaves in the same way with regards to decode status register. Signed-off-by: Pawel Osciak Signed-off-by: Arun Kumar K --- drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 89356ae..6ef6bd1 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -309,12 +309,15 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx, { struct s5p_mfc_dev *dev = ctx->dev; unsigned int dst_frame_status; + unsigned int dec_frame_status; struct s5p_mfc_buf *src_buf; unsigned long flags; unsigned int res_change; dst_frame_status = s5p_mfc_hw_call(dev->mfc_ops, get_dspl_status, dev) & S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK; + dec_frame_status = s5p_mfc_hw_call(dev->mfc_ops, get_dec_status, dev) + & S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK; res_change = (s5p_mfc_hw_call(dev->mfc_ops, get_dspl_status, dev) & S5P_FIMV_DEC_STATUS_RESOLUTION_MASK) >> S5P_FIMV_DEC_STATUS_RESOLUTION_SHIFT; @@ -347,8 +350,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx, } } - if (dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_DISPLAY || - dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_ONLY) + if (dec_frame_status == S5P_FIMV_DEC_STATUS_DECODING_DISPLAY) s5p_mfc_handle_frame_copy_time(ctx); /* A frame has been decoded and is in the buffer */