Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp18796imu; Mon, 26 Nov 2018 07:25:24 -0800 (PST) X-Google-Smtp-Source: AFSGD/WTwlU64J0o3gPmADxPJWCmgYGk6OtPoQGIRbOIakW9Ohlm+rzCVzZwy5FmdFF9UPQ90zYK X-Received: by 2002:a17:902:7443:: with SMTP id e3mr25304384plt.304.1543245924085; Mon, 26 Nov 2018 07:25:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543245924; cv=none; d=google.com; s=arc-20160816; b=fcDKaH/t+8My7NYTi2ne40bK4cK8Q8ZaaqTHJ2AXqNM+61+qCNFt6ktea0cMrrCVw2 Jqaga11sj+VBBztWSAQ1JKTolRdxntawzUaG0LZto2wJKeFxx7aaxOU+cLh7VCfi2Ixx Nl8zUiYRzXdJFdnsC+gjX5M0RAnFM/OcRzx4s6VkDWvKph82LtSvr3CYHHgP80wixwBH p03g3fC1kgbak7qdHmSwL7etU19B2JcGFJj1tmyc9rX2Ap+Y+1kJHGSzZW8MZsFlBsT2 YeT6+dHfWsC1frMyaErxOVYP8tJ2hrNJWdE3mBayzOYuNRNgZ64oeIE+Gn/WkLMw7mal 6e4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=GgyUOBOosoWSDCwHStIJK0cKj/2zKqXYrlc1g0a/K34=; b=trM+ef2VJqhjtRfl4TezDNTb3qfajMla+EaujbxD3nZx7Iv3Fgb9GxSHT2+oOxUOkh LFLJLk9Zk+3hDA7jJhGrdxFvjA+9QO+FcotydMqGs06cGSqO9OapFWRNi9GppI42cT5c Cj6ERWPSiJ/3D/no6VVDTEq9XUvWLzjWSEMOpL1FK0QFcH0ai6p/PsdQp7rhfkH0J22w jxglUvkHlMwK/Tu7rb1n75/bELBK8pt+PwEAUO8WZOUBbLOKgutoFw8mSdNfpNgmbRft 2dFB/7diSMql0fPDMXe8to1UEqq+3up+flFvw1O/+Q7jz8FAiUXZv318tDmDfjlHg4wf MbSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v14si622871pfc.76.2018.11.26.07.24.48; Mon, 26 Nov 2018 07:25:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726315AbeK0CSZ (ORCPT + 99 others); Mon, 26 Nov 2018 21:18:25 -0500 Received: from lb3-smtp-cloud8.xs4all.net ([194.109.24.29]:36144 "EHLO lb3-smtp-cloud8.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726167AbeK0CSY (ORCPT ); Mon, 26 Nov 2018 21:18:24 -0500 Received: from [192.168.2.10] ([212.251.195.8]) by smtp-cloud8.xs4all.net with ESMTPA id RIjogDaI4IGBARIjrgfcWc; Mon, 26 Nov 2018 16:23:57 +0100 Subject: Re: [PATCH v3] media: venus: amend buffer size for bitstream plane To: Stanimir Varbanov , Malathi Gottam , mchehab@kernel.org Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, acourbot@chromium.org, vgarodia@codeaurora.org, Tomasz Figa References: <1543227173-2160-1-git-send-email-mgottam@codeaurora.org> From: Hans Verkuil Message-ID: <57b28a7f-8c5c-22d2-2f89-e6d6ebdcb8a2@xs4all.nl> Date: Mon, 26 Nov 2018 16:23:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfISXF+eRkpVnhf4Z/3F84PafkCHgnu7bRH9AxzaGgryI+PKf0Q0gTNJFhaWRQF0cG+Bj1fLo7O8hUmHjfDsgUBgeMdyEv4D42EMEY/WtNd6mCElAqqCc LOPaENOqU8I+IlL3DwtlFLB58B64jVQtqaLWeR6iLN7mZBvHfo0VJVeLXi9atm59f9MSQaUDkQ6w5UQeXuwyIEDdQYfggHIZCnNKjq+bxgfTi2H17noAkc1t oyJo9w8OrBVq4+DSaPRnArWmKaYfoTxsEldDyrSIMHLlThvWNAXmHaUKt2JRC2T7zct15xI720/1CRH9CtVMLoqsZpEdOBB2iKQdqbHOzumKB/nnFXS6sSjF qemA2qkiOKXFn4P8gpSn32oRrtGoVZRK1tevZgSk1ih2FabtCDHbKRSvez7LT4l58hlA3BWPgVUFvXZ9C+nLtm4tXLivkAQb8m4qllEG87bQbk5senk= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/26/2018 03:57 PM, Stanimir Varbanov wrote: > Hi Hans, > > On 11/26/18 3:37 PM, Hans Verkuil wrote: >> On 11/26/2018 11:12 AM, Malathi Gottam wrote: >>> Accept the buffer size requested by client and compare it >>> against driver calculated size and set the maximum to >>> bitstream plane. >>> >>> Signed-off-by: Malathi Gottam >> >> Sorry, this isn't allowed. It is the driver that sets the sizeimage value, >> never the other way around. > > I think for decoders (OUTPUT queue) and encoders (CAPTURE queue) we > allowed userspace to set sizeimage for buffers. See [1] Initialization > paragraph point 2: > > ``sizeimage`` > desired size of ``CAPTURE`` buffers; the encoder may adjust it to > match hardware requirements > > Similar patch we be needed for decoder as well. I may have missed that change since it wasn't present in v1 of the stateful encoder spec. Tomasz, what was the reason for this change? I vaguely remember some thread about this, but I forgot the details. Since this would be a departure of the current API this should be explained in more detail. I don't really see the point of requiring userspace to fill this in. For stateful codecs it can just return some reasonable size. Possibly calculated using the provided width/height values or (if those are 0) some default value. Ditto for decoders. Stanimir, I certainly cannot merge this until this has been fully nailed down as it would be a departure from the current API. And looking at the venus patch I do not see how it helps userspace. Regards, Hans > >> >> If you need to allocate larger buffers, then use VIDIOC_CREATE_BUFS instead >> of VIDIOC_REQBUFS. >> >> What problem are you trying to solve with this patch? >> >> Regards, >> >> Hans >> >