Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5354615rwb; Mon, 14 Nov 2022 03:28:45 -0800 (PST) X-Google-Smtp-Source: AA0mqf5QmvRbaCW9S2wv+wmxCigu58+q/CnzqXQf+sKYT8IHC/vwet6o88sMapmnI8FfhlKK6rLH X-Received: by 2002:a17:90a:a887:b0:20a:739b:9708 with SMTP id h7-20020a17090aa88700b0020a739b9708mr13321558pjq.140.1668425325807; Mon, 14 Nov 2022 03:28:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668425325; cv=none; d=google.com; s=arc-20160816; b=0OjC+qEiSKRM52DXkrIyaUY+Gm4WvDy8tmha+tb93dhRjA5KH9ljND7uj0u2JeHKno IuTUSB/aOIZ/gnVyc4yGAk08xtDyjMM3qQFr2inWT89mCNdbaov++/Zd0OBDfjCchCV0 Deb1/+D61iQPI9oh3nN/roVSmc6PufQcK7iIypZZV9vlTGvVZTbjb8NTjPJEasiJzkuX afWunZdipdsJpiJTZm/KKWDT2NLgEzUGT3EpcXUiNwPo41mJ48u6PiwP4HeK/4KlmnM5 ud2IQg6xMga1bMQFouCFMz9yO+lRf7RO9wb6aIbI+HLGN1Gqw8mz5Pw5wrUtPWGIXgrS wUiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=kvmm36TO4j/lYEpoVRRbLBCMnloq6Vtklw3iBFNkNHE=; b=C1qDPaT9qtQ1nKHyPy7qcPL4D14SopsOrrOfG9icpwGopf5QDbNKHJQR5yVjjVcMsN 8Uww159MYz/5Am6Tub0K12Ap/OetfG0jWoLLrgvp4EmCtnpGCv9wn+YQKPnYtTVmAsD1 iEerPoADYDFkrOkDN9u2G/owm3WiimTKFNCtet0AnyAz4gA+xnCh5EaLHAqQD/T+Y2Wf TNK/Vlkj4R9BarVaXNUtrDnk2KaznBEh1ADbJLbw4kGSJqTurSwiqRqHw0BmqEnLZiDk hpScUzifEdzhmILdjPf7ULVc/N6fvl1XesmtjDmuRwzBgvySiiqS2tekI4wZ87xjj6Br UesQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=oHySW+J8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b14-20020a17090a8c8e00b0020befc1a93asi8679365pjo.100.2022.11.14.03.28.34; Mon, 14 Nov 2022 03:28:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=oHySW+J8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236037AbiKNLMD (ORCPT + 89 others); Mon, 14 Nov 2022 06:12:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236619AbiKNLLg (ORCPT ); Mon, 14 Nov 2022 06:11:36 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52831248E3; Mon, 14 Nov 2022 03:08:45 -0800 (PST) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id A1066660035A; Mon, 14 Nov 2022 11:08:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1668424121; bh=WSZBBTuHZl7i5QeHJkZThtLqJACixahwu9l9LESefbA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=oHySW+J8hVuJ7x6PI24Y90yrAp822hL2yetyUUbeIhY1OmfW2+SXasFB0RzCVKCKk 4PEkbXvmLBOtcG3Ppj7ZAVn06lona6ffEshFTBBzX3QDkAU6qVoF3wcZaFqUGyQMKU zDk+gT7GhMcJTyWAZ+rjPCr1ZOP+PNAA8FvV3XWJZTTtLl8nBdOw5kZz1y0uw7mDjY VZrkoC12Yj9Wr+Y/09+zvKHs3mrjYwGk6rcgRyU4IZNkMsoJaln0F/0daKkFHBS/HE O6gCjOIJDdo/Vulo7AJGIkkCKdqUvmJpN5PE417zZI1ITorN9tzHbZWGuzMBwVxYBV XGIsXxzvo0s8w== Message-ID: Date: Mon, 14 Nov 2022 12:08:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH v2] media: mediatek: vcodec: fix h264 cavlc bitstream fail Content-Language: en-US To: Yunfei Dong , Chen-Yu Tsai , Nicolas Dufresne , Hans Verkuil , Benjamin Gaignard , Tiffany Lin Cc: Mauro Carvalho Chehab , Matthias Brugger , George Sun , Xiaoyong Lu , Hsin-Yi Wang , Fritz Koenig , Daniel Vetter , Steve Cho , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com References: <20221018114122.26785-1-yunfei.dong@mediatek.com> From: AngeloGioacchino Del Regno In-Reply-To: <20221018114122.26785-1-yunfei.dong@mediatek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 18/10/22 13:41, Yunfei Dong ha scritto: > Some cavlc bistream will decode fail when the frame size is small than s/small/smaller/g > 20 bytes. Need to add pending data at the end of the bitstream. > > For the minimum size of mapped memory is 256 bytes(16x16), adding four bytes data > won't lead to access unknown virtual memory. > > Fixes: 59fba9eed5a7 ("media: mediatek: vcodec: support stateless H.264 decoding for mt8192") > Signed-off-by: Yunfei Dong > --- > compared with v1: > - add detail comments for function: vdec_h264_insert_startcode. > - re-write commit message. > --- > .../vcodec/vdec/vdec_h264_req_multi_if.c | 32 +++++++++++++++++-- > 1 file changed, 29 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c > index 4cc92700692b..18e048755d11 100644 > --- a/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c > +++ b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c > @@ -539,6 +539,29 @@ static int vdec_h264_slice_core_decode(struct vdec_lat_buf *lat_buf) > return 0; > } > > +static void vdec_h264_insert_startcode(struct mtk_vcodec_dev *vcodec_dev, unsigned char *buf, > + size_t *bs_size, struct mtk_h264_pps_param *pps) > +{ > + struct device *dev = &vcodec_dev->plat_dev->dev; > + > + /* Need to add pending data at the end of bitstream when bs_sz is small than > + * 20 bytes for cavlc bitstream, or lat will decode fail. This pending data is > + * useful for mt8192 and mt8195 platform. What is the reason why other SoCs don't need this? > + * > + * cavlc bitstream when entropy_coding_mode_flag is false. > + */ > + if (pps->entropy_coding_mode_flag || *bs_size > 20 || > + !(of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec") || > + of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec"))) I'm not comfortable seeing of_device_is_compatible... this list will grow whenever a new SoC needing this appears. Please think about a good name for a flag/quirk, or a bool, in the platform data for these two SoCs and use it. Regards, Angelo