Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp759554ybj; Tue, 5 May 2020 07:11:06 -0700 (PDT) X-Google-Smtp-Source: APiQypJa8cNtuIIU18qeZlYuKePfgPoQNzNXfu3/Uzv4pf75zsqyx+s7omZpk7feFr3TuJpGbX8s X-Received: by 2002:a05:6402:749:: with SMTP id p9mr2646908edy.75.1588687866596; Tue, 05 May 2020 07:11:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588687866; cv=none; d=google.com; s=arc-20160816; b=FdiZiIEAQAavaL+KYZeaqduVAnz2HLvFtoEIse2Wzw71VqLx++tzi6yv10nB1JFxLo vC1Nxp8Kww3RgcxIj+cl7gE4uQUAyJqi5TsgfE0prrHPj7ttvYvOGLmMNwoErquQGaoG xz37lH7usPDVAKgp8Kd5TMpLk8vNrBbEoKz/sQDejW9QedP2aFl9ph865DG9vD9XzxYM juzJvF+njpVkCp7xuf6RrTfbMpW8xtTgRA6Zt4xP33V/NdsEBTuwKX+vVSFsogUryM3N FMCI9LGmmiEfBzm84T1EjSVuT+qrLaF0IqMpAOkaw7wvvi/fhnofw9YC2YwEY3PmOxKQ rXUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=DQhPVNzCwxODV9jjVycfNahbwJl6DrUIjQ9AnoCrWCs=; b=Z5jeOMmaIdxUcX16UOVW3z5wBBERkYo+GEe1hIrQ0m7sYLmbMlSZdQeFyuA2mm+HqA I1DFhEkmBpzE1PFyNUf8EnF+gkYWiRpDMggPfFxkm3oHhJU2lAidus9oeNMJ7zVNDJ5Z ZXYcT8agn+avggp/Fg4qmcsRRePEJrSgzGLYgbYNMP/lMbgxQpp1JsQQnfGXuPQeOP/O ihSL4Nx5bnSFzf6bo+QaN6Ipr8oNYI+4c+iwEcb2698tG613PxYVoyVLS0/JjUQnAyW3 +/mmhQLoxrwVHyBaT2PGvB9FEc9o47zghTXYEujlaILEAJh5DkV4PSehL99/nVAZrUB6 sVMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YU+6u86+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q13si1420940edn.307.2020.05.05.07.10.41; Tue, 05 May 2020 07:11:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YU+6u86+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729274AbgEEOFg (ORCPT + 99 others); Tue, 5 May 2020 10:05:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727785AbgEEOFg (ORCPT ); Tue, 5 May 2020 10:05:36 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1351C061A0F for ; Tue, 5 May 2020 07:05:35 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id t12so1953210edw.3 for ; Tue, 05 May 2020 07:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DQhPVNzCwxODV9jjVycfNahbwJl6DrUIjQ9AnoCrWCs=; b=YU+6u86++6VWtYwNPHyc1ME4CNkzeonYAyS/jdldZueht1JjMExBXKZ2fwCZZnMaZI ZhkNfG4Iq7Wa8TgqlSCI9rUl8C2Q7X0XofiEN2if0Co5+gwFJU/5PxOH4YrwKBPJ5sGz zyiacbV9r11JC/U44S4xnE/s0Ymar0Oax5aJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DQhPVNzCwxODV9jjVycfNahbwJl6DrUIjQ9AnoCrWCs=; b=l2kpgnuaxdUih4SKRNq637HdzUpSZKJ4NtYz6wQQxe1eAJ7av+jbeY82WArRPzABX3 Yh+PFvujqB2fHoLWMZ+hh8fmXLdbtpEQt1yLfPt6yHducQs3ysMwFhXEO4MlMZT0ysGU K9lUyYfE5QOc/DSbJ1ZvcFdlbGOL8Cj9QImJsJUrjFlWOrWguiSvSa+rjsbIC9Lb5BsL Dma+5iMIahy9Z5ad54pDGEFloOpAf7dXAceDQFwsk9NFHGn1YCpo4cR59IPYkmh4fAKn sxPztQVQjT6yTvMgFa6HDCCoAelJhIplJu+v/VjBwkwBYRj3Ml64SNrLO06u//7m9S1P TkxA== X-Gm-Message-State: AGi0PuYC8Kj5WQynKh8mv6T6Ag2SAMfokkyLqfMpW2WUDjkLDj/NzEO+ owFqi2FojaXhXJ0Bxo1f/88pDpMDRK3q/g== X-Received: by 2002:a05:6402:22cd:: with SMTP id dm13mr2890372edb.56.1588687534319; Tue, 05 May 2020 07:05:34 -0700 (PDT) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com. [209.85.221.53]) by smtp.gmail.com with ESMTPSA id k24sm326357ejv.15.2020.05.05.07.05.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2020 07:05:33 -0700 (PDT) Received: by mail-wr1-f53.google.com with SMTP id f13so2866221wrm.13 for ; Tue, 05 May 2020 07:05:33 -0700 (PDT) X-Received: by 2002:adf:fc4f:: with SMTP id e15mr3926804wrs.415.1588687532834; Tue, 05 May 2020 07:05:32 -0700 (PDT) MIME-Version: 1.0 References: <20200505134110.3435-1-ezequiel@collabora.com> <20200505134110.3435-2-ezequiel@collabora.com> In-Reply-To: From: Tomasz Figa Date: Tue, 5 May 2020 16:05:19 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/3] media: rkvdec: Fix .buf_prepare To: Ezequiel Garcia 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Best regards, Tomasz