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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BE02C433F5 for ; Fri, 25 Feb 2022 09:24:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239085AbiBYJZR (ORCPT ); Fri, 25 Feb 2022 04:25:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239083AbiBYJZO (ORCPT ); Fri, 25 Feb 2022 04:25:14 -0500 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67895182D87; Fri, 25 Feb 2022 01:24:23 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: kholk11) with ESMTPSA id EF4A81F45AF2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1645781062; bh=u9idag57rvmc8+kE2xwXHO4QSmwf2cUfuVZYpVWwzno=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HHWrpRKDWWODvpKgHH2FJgoYRczWBTVoDmcsJ+U2u8Xqo6LJt2XZnraOXJYYETihN hg3T7TC/JSIXJjq1Z314B3P/rZ/SkucOhzZtf3qRY4kVe6BOebMcswRYwEsD5oKJGb SUlO7LNPCnyG/O1XvC9dESgyC1ZcYSXHF1vM0piUlEGYLVFjWub+tOFcqqilkm1CWL yqsipCrQwrnh3Icd1weux1eKwl5VO7wKVc1uIhcdfU00QzeoFbT6S3bMGUyCRiOSoD QOr0dW+2w6ppmynj2Qhb4dkptB4Sj6YEGP2Lxf2VC6/uj6wVnhObM1FwrS/FG2ziV7 R2W5gl8OWHw6g== Message-ID: <5d87e367-4ca8-9f61-bc17-e1998be0ed6c@collabora.com> Date: Fri, 25 Feb 2022 10:24:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH v7, 11/15] media: mtk-vcodec: record capture queue format type Content-Language: en-US To: Yunfei Dong , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Benjamin Gaignard , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa Cc: George Sun , Xiaoyong Lu , Hsin-Yi Wang , Fritz Koenig , Daniel Vetter , dri-devel , Irui Wang , Steve Cho , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com References: <20220223034008.15781-1-yunfei.dong@mediatek.com> <20220223034008.15781-12-yunfei.dong@mediatek.com> From: AngeloGioacchino Del Regno In-Reply-To: <20220223034008.15781-12-yunfei.dong@mediatek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Il 23/02/22 04:40, Yunfei Dong ha scritto: > Capture queue format type is difference for different platform, > need to calculate capture buffer size according to capture queue > format type in scp. > > Signed-off-by: Yunfei Dong This change is ok, but the commit message should be changed to advertise that this is preparation for the new stateless H264 decoding driver. Besides, I suggest to reorder the commits sequence, so that this commit goes in between "Extract H264 common code" and "support stateless H.264 decoding for mt8192", as this last one is the actual real user of this change. Anyway, this is my commit message proposal: The capture queue format type may be differ depending on platform: for stateless decoder drivers, we need to calculate the capture buffer size according to the capture queue format type in SCP. As a preparation for introducing drivers for stateless decoding, save the current capture queue type on a per vcodec context basis. After fixing, Reviewed-by: AngeloGioacchino Del Regno