linux-kernel - Re: [PATCH v3 00/26] Enable H.264/H.265 encoder support and fixes in iris driver common code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f104c9d8-16ae-64c6-4494-49981ef950ea@quicinc.com>
Date: Thu, 21 Aug 2025 13:26:31 +0530
From: Vikash Garodia <quic_vgarodia@...cinc.com>
To: Dikshita Agarwal <quic_dikshita@...cinc.com>,
        Neil Armstrong
	<neil.armstrong@...aro.org>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        "Bryan
 O'Donoghue" <bryan.odonoghue@...aro.org>,
        Mauro Carvalho Chehab
	<mchehab@...nel.org>,
        Stefan Schmidt <stefan.schmidt@...aro.org>,
        "Vedang
 Nagar" <quic_vnagar@...cinc.com>,
        Hans Verkuil <hverkuil@...nel.org>
CC: <linux-media@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Renjiang Han <quic_renjiang@...cinc.com>,
        Wangao Wang <quic_wangaow@...cinc.com>
Subject: Re: [PATCH v3 00/26] Enable H.264/H.265 encoder support and fixes in
 iris driver common code


On 8/21/2025 12:51 PM, Dikshita Agarwal wrote:
>> The change occurs around Aug 14 2024, So I checked the downstream driver
>> and I found that fixes the encoding:
>> ===========================><=================================================
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
>> @@ -863,9 +863,18 @@ static inline
>>  u32 size_vpss_line_buf(u32 num_vpp_pipes_enc, u32 frame_height_coded,
>>                        u32 frame_width_coded)
>>  {
>> -       return ALIGN(((((((8192) >> 2) << 5) * (num_vpp_pipes_enc)) + 64) +
>> -                     (((((max_t(u32, (frame_width_coded),
>> -                                (frame_height_coded)) + 3) >> 2) << 5) +
>> 256) * 16)), 256);
>> +       u32 vpss_4tap_top = 0, vpss_4tap_left = 0, vpss_div2_top = 0,
>> vpss_div2_left = 0, vpss_top_lb = 0, vpss_left_lb = 0, size_left = 0,
>> size_top = 0;
>> +
>> +       vpss_4tap_top = ((((max_t(u32, frame_width_coded,
>> frame_height_coded) * 2) + 3) >> 2) << 4) + 256;
>> +       vpss_4tap_left = (((8192 + 3) >> 2) << 5) + 64;
>> +       vpss_div2_top = (((max_t(u32,frame_width_coded, frame_height_coded)
>> + 3) >> 2) << 4) + 256;
>> +       vpss_div2_left = ((((max_t(u32, frame_width_coded,
>> frame_height_coded)* 2) + 3) >> 2) << 5) + 64;
>> +       vpss_top_lb = (frame_width_coded + 1) << 3;
>> +       vpss_left_lb = (frame_height_coded << 3) * num_vpp_pipes_enc;
>> +       size_left = (vpss_4tap_left + vpss_div2_left) * 2 * num_vpp_pipes_enc;
>> +       size_top = (vpss_4tap_top + vpss_div2_top) * 2;
>> +
>> +       return ALIGN(size_left + size_top + vpss_top_lb + vpss_left_lb,
>> DMA_ALIGNMENT);
>>  }
> Seems this calculation is different for iris3 and iris33, hence you see
> this issue on SM8650.
> 
> Updating this calculation in common code will increase the buffer size with
> from ~400KB to ~2.2 MBs (for 640x480) and even more for higher resolution.
> 
> @vikash, pls comment if we should update in common code or have this
> implemented specific for iris33 separately using some ops.

increasing 1.8 MBs for VGA and assuming it grows further for higher resolution,
i would recommend to separate it out for line buffer alone.

Neil,
We are doing something similar as a preparation for enabling an upcoming SOC,
maybe let me share the pseudo code offline with you. When you add encode support
for SM8650, you can raise that change to extend the line buffer calculation for
iris33.

Regards,
Vikash