From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F050FC47254 for ; Tue, 5 May 2020 14:27:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D13AB20675 for ; Tue, 5 May 2020 14:27:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729427AbgEEO1l (ORCPT ); Tue, 5 May 2020 10:27:41 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:42808 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729123AbgEEO1k (ORCPT ); Tue, 5 May 2020 10:27:40 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 84EAE2A1EA1 Message-ID: Subject: Re: [PATCH v3 1/3] media: rkvdec: Fix .buf_prepare From: Ezequiel Garcia To: Tomasz Figa Cc: Linux Media Mailing List , "open list:ARM/Rockchip SoC..." , Linux Kernel Mailing List , kernel@collabora.com, Jonas Karlman , Heiko Stuebner , Hans Verkuil , Alexandre Courbot , Jeffrey Kardatzke , Gustavo Padovan Date: Tue, 05 May 2020 11:27:30 -0300 In-Reply-To: References: <20200505134110.3435-1-ezequiel@collabora.com> <20200505134110.3435-2-ezequiel@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.0-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-05-05 at 16:05 +0200, Tomasz Figa wrote: > On Tue, May 5, 2020 at 3:59 PM Ezequiel Garcia wrote: > > On Tue, 2020-05-05 at 15:56 +0200, Tomasz Figa wrote: > > > Hi Ezequiel, > > > > > > On Tue, May 5, 2020 at 3:41 PM Ezequiel Garcia wrote: > > > > The driver should only set the payload on .buf_prepare > > > > if the buffer is CAPTURE type, or if an OUTPUT buffer > > > > has a zeroed payload. > > > > > > Thanks for the patch. Just one question below. > > > > > > Where does the requirement to set OUTPUT buffer bytesused to sizeimage > > > if the original bytesused is 0 come from? > > > > > > > If I'm reading english correctly, it's here: > > > > https://www.kernel.org/doc/html/latest/media/uapi/v4l/buffer.html > > > > """ > > The number of bytes occupied by the data in the buffer. It depends on the negotiated data format and may change with each buffer for compressed > > variable size data like JPEG images. Drivers must set this field when type refers to a capture stream, applications when it refers to an output > > stream. If the application sets this to 0 for an output stream, then bytesused will be set to the size of the buffer (see the length field of this > > struct) by the driver. For multiplanar formats this field is ignored and the planes pointer is used instead. > > """ > > Okay, thanks. I wonder if this shouldn't be handled by the core, > though. Especially given that the document refers to the length field > specifically and not the sizeimage set in the format. > Yes, either core or helper, this definitely calls for a generic solution. Ezequiel