From patchwork Mon May 12 10:16:44 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: 4158231 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 D0E239F3AE for ; Mon, 12 May 2014 10:16:59 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0A28820219 for ; Mon, 12 May 2014 10:16:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 338AC201BA for ; Mon, 12 May 2014 10:16:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756252AbaELKQy (ORCPT ); Mon, 12 May 2014 06:16:54 -0400 Received: from mail-pa0-f44.google.com ([209.85.220.44]:52909 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756217AbaELKQx (ORCPT ); Mon, 12 May 2014 06:16:53 -0400 Received: by mail-pa0-f44.google.com with SMTP id ld10so8337436pab.3 for ; Mon, 12 May 2014 03:16:52 -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=P/XiJy9RSdZ2lOypgtOg6sGch6bWHnPrt6ITcxhPkZs=; b=ZbXd9SSueWaVA6Hkgc82+VxHkbcIDkWrjjYJxq/haXGHssU1OVm+Ry3pf9ybDUV+Oi nF34YX/BD6+WXPPphS8mqD6O9exPccwKx/l9L/kVbWHXMQjQa1kc8DQI2mL+KoL4oWeO L74Gu9Pw4Tmxf5Pv2QMnSnKgK4bBQqt49klJgQR4qlsvm9BjujN8Im6le5Y1hAD0W0kb 0dzIDfWJSE3SaYVV8ql6pVZhmY4wX1LKuVCqku2iPW/hv4JaUHvkuPca1qFuO9A5LbXN 0GAOOdj3xNHWX9UZ9NUvxPuhPFTBRLj/bkXw9uCZxBRtTCS8Q2d61VxUBYVDaNwGVvPu fCjg== X-Received: by 10.66.148.197 with SMTP id tu5mr53980149pab.108.1399889812845; Mon, 12 May 2014 03:16:52 -0700 (PDT) Received: from localhost.localdomain ([14.140.216.146]) by mx.google.com with ESMTPSA id qh2sm46730982pab.13.2014.05.12.03.16.49 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 03:16:52 -0700 (PDT) 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 v2] [media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode. Date: Mon, 12 May 2014 15:46:44 +0530 Message-Id: <1399889804-4225-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=-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 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. So adding VP8 also along with H264 to disallow re-submitting of buffer back to hardware for decode. Signed-off-by: Pawel Osciak Signed-off-by: Arun Kumar K --- Changes from v1 - Made the condition to specifically add VP8 case only suggested by Kamil. --- drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 0f796ad..2d7d1ae 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -382,6 +382,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx, ctx->consumed_stream += s5p_mfc_hw_call(dev->mfc_ops, get_consumed_stream, dev); if (ctx->codec_mode != S5P_MFC_CODEC_H264_DEC && + ctx->codec_mode != S5P_MFC_CODEC_VP8_DEC && ctx->consumed_stream + STUFF_BYTE < src_buf->b->v4l2_planes[0].bytesused) { /* Run MFC again on the same buffer */