From patchwork Fri Mar 7 08:25:52 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: 3788411 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 AFDD2BF540 for ; Fri, 7 Mar 2014 08:26:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D829120279 for ; Fri, 7 Mar 2014 08:26:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F080320268 for ; Fri, 7 Mar 2014 08:26:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750926AbaCGI0I (ORCPT ); Fri, 7 Mar 2014 03:26:08 -0500 Received: from mail-pd0-f175.google.com ([209.85.192.175]:64535 "EHLO mail-pd0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751027AbaCGI0F (ORCPT ); Fri, 7 Mar 2014 03:26:05 -0500 Received: by mail-pd0-f175.google.com with SMTP id x10so3737803pdj.20 for ; Fri, 07 Mar 2014 00:26:05 -0800 (PST) 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=OPaLyMJygM63mrqBxTwoaj9b23ePocY+5A40M+KgLVg=; b=srOmxwb+uaa+fQ7tERM1HkmYgrKW38Oq1EOVqO5SfZMLspLFECzf3Pql2tXkzpiShz lFMmYYP7Fy1Yaeu9GlcDW3lygVvUVg2ijPut9bHT5HlAValmfph/6s7xoAiiLY+NAXlb 6t3rdoQ2rQlGkn0YVtwG4W+vtJqQj10tLgOBh2XpD8o6woi/o9ZsEr9pRdwcH9+WDZJJ Ze6AueaO//kwU7hs56a3lHrqce2HeV+x3galqkIFmLIyRZxg3gJm62viq/Kwv3WkorcK DygAvT6zp42Hbd4nTPKot3uJg5Ya0PScDX9IszRclantwWehBhjSTYKb61Tl8EjCFlTC mbxw== X-Received: by 10.68.193.130 with SMTP id ho2mr19852673pbc.141.1394180765008; Fri, 07 Mar 2014 00:26:05 -0800 (PST) Received: from localhost.localdomain ([115.113.119.130]) by mx.google.com with ESMTPSA id gg3sm30696357pbc.34.2014.03.07.00.25.56 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 00:26:04 -0800 (PST) From: Arun Kumar K To: linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org Cc: k.debski@samsung.com, s.nawrocki@samsung.com, posciak@chromium.org, arunkk.samsung@gmail.com Subject: [PATCH] [media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode. Date: Fri, 7 Mar 2014 13:55:52 +0530 Message-Id: <1394180752-16348-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=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 Currently, for formats that are not H264, MFC driver will check the consumed stream size returned by the firmware and, based on that, will try to decide whether the bitstream buffer contained more than one frame. If the size of the buffer is larger than the consumed stream, it assumes that there are more frames in the buffer and that the buffer should be resubmitted for decode. This rarely works though and actually introduces problems, because: - v7 firmware will always return consumed stream size equal to whatever the driver passed to it when running decode (which is the size of the whole buffer), which means we will never try to resubmit, because the firmware will always tell us that it consumed all the data we passed to it; - v6 firmware will return the number of consumed bytes, but will not include the padding ("stuffing") bytes that are allowed after the frame in VP8. Since there is no way of figuring out how many of those bytes follow the frame without getting the frame size from IVF headers (or somewhere else, but not from the stream itself), the driver tries to guess that padding size is not larger than 4 bytes, which is not always true; The only way to make it work is to queue only one frame per buffer from userspace and the check in the kernel is useless and wrong for VP8. MPEG4 still seems to require it, so keep it only for that format. Signed-off-by: Pawel Osciak Signed-off-by: Arun Kumar K --- drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index e2aac59..66c1775 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -360,7 +360,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx, list); ctx->consumed_stream += s5p_mfc_hw_call(dev->mfc_ops, get_consumed_stream, dev); - if (ctx->codec_mode != S5P_MFC_CODEC_H264_DEC && + if (ctx->codec_mode == S5P_MFC_CODEC_MPEG4_DEC && ctx->consumed_stream + STUFF_BYTE < src_buf->b->v4l2_planes[0].bytesused) { /* Run MFC again on the same buffer */