From patchwork Tue Mar 18 08:52:39 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: 3852701 Return-Path: X-Original-To: patchwork-linux-media@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 8AC2B9F44E for ; Wed, 19 Mar 2014 17:39:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9A49A2011B for ; Wed, 19 Mar 2014 17:39:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C954E2017B for ; Wed, 19 Mar 2014 17:39:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753784AbaCRIwy (ORCPT ); Tue, 18 Mar 2014 04:52:54 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:52162 "EHLO mail-pb0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753741AbaCRIwv (ORCPT ); Tue, 18 Mar 2014 04:52:51 -0400 Received: by mail-pb0-f44.google.com with SMTP id rp16so6950111pbb.31 for ; Tue, 18 Mar 2014 01:52:50 -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; bh=o6HaqKitRViX8bUmOkRZmNU/HSSFCPZhfQAhC4bWVss=; b=dcpVbEsRdAUc1NsP+LpPgyehSr5z4KkLGDUSPJ9DlijK1o+43GdPfd+LT0OJVOsYGw 50Ew0ZZexlwyfBACmtmLkyG9FmxLiyQji6tYtMgmPK/SFSy8K4nLjKOTFv7OFz4R2YR5 DrRxH/fbtW64p8fV7fj8mz31sihf56+kfayiQYi4Mz06Dzmf6gPt2tbpfv+dOBUOu5MT H46kIx8RTUMYwt+yjR9ijvg+ay1tLiQfStnjATAn9xwAiT2dLhP6wOSNkpfBUtZkvIyH nqlWLabGxKlVFj0O94Wkif93wU1sI/D+Sz+msLxK6msQcoNOTv/EIzgjbvPLRiDxcwgt zzKQ== X-Received: by 10.66.136.103 with SMTP id pz7mr9231338pab.140.1395132770433; Tue, 18 Mar 2014 01:52:50 -0700 (PDT) Received: from localhost.localdomain ([115.113.119.130]) by mx.google.com with ESMTPSA id pp5sm50460590pbb.33.2014.03.18.01.52.47 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 01:52:49 -0700 (PDT) From: Arun Kumar K To: linux-media@vger.kernel.org Cc: k.debski@samsung.com, s.nawrocki@samsung.com, posciak@chromium.org, arunkk.samsung@gmail.com Subject: [PATCH] [media] s5p-mfc: Copy timestamps only when a frame is produced. Date: Tue, 18 Mar 2014 14:22:39 +0530 Message-Id: <1395132760-5529-1-git-send-email-arun.kk@samsung.com> X-Mailer: git-send-email 1.7.9.5 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,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 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 66c1775..d636789 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -304,12 +304,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; @@ -342,8 +345,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 */