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

[Vikash Garodia <quic_vgarodia@quicinc.com>]

On 8/21/2025 2:14 PM, Neil Armstrong wrote:
> Hi,
> 
> On 21/08/2025 09:56, Vikash Garodia wrote:
>>
>> 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.
> 
> I don't understand your point, encoding is already enabled with this patchset and
> works fine with _old_ firmwares, it just completely fail to encode anything with
> the firmware sent on linux-firmware yesterday.

IIUC, the patch looks to increase the size of line buffer, and it worked with
the firmware could be due to increased size meeting the firmware need. I was
trying to say that if there is an increase in size (in MBs), it is not a good
idea to increase in common which increases for all enabled SOCs.
> 
> But yes I can provide a fixup patch for vpu33 on top of this serie to be merged
> in the same
> time based on your pseudo code.

Shared with you on a way to abstract the line buffer calculation for iris33 soc.
> 
> Neil
> 
>>
>> Regards,
>> Vikash
>