Messages in this thread | | | Date | Tue, 15 Nov 2022 09:48:38 +0100 | Subject | Re: [PATCH v2] media: mediatek: vcodec: fix h264 cavlc bitstream fail | From | AngeloGioacchino Del Regno <> |
| |
Il 15/11/22 03:00, Yunfei Dong (董云飞) ha scritto: > Hi AngeloGioacchino, > > Thanks for your detail suggestion. > On Mon, 2022-11-14 at 12:08 +0100, AngeloGioacchino Del Regno wrote: >> 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 > > Will fix in next patch. >> >>> 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 <yunfei.dong@mediatek.com> >>> --- >>> 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_i >>> f.c >>> b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_i >>> f.c >>> index 4cc92700692b..18e048755d11 100644 >>> --- >>> a/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_i >>> f.c >>> +++ >>> b/drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_i >>> f.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? >> > For the hardware not add this feature, and will add in the future Soc. >>> + * >>> + * 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. >> > For this feature only need to add in these two Socs, and won't grow > anymore. So just want to use compatible to separate, not add one flags. > > So you think that using one flag to separate much better? >
A flag is better: please remember that calls to of_device_is_compatible() will perform a string comparison which, as you know, as much optimized as it can be, it's always going to be slower than a simple integer/bool/flag check.
This means that even for functional (not just cosmetic) reasons we should not use of_device_is_compatible() here :-)
Cheers, Angelo
| |