1. Patchew
  2. linux
  3. [PATCH v2 0/7] media: iris: add support for kaanapali platform
  4. View patch

[PATCH v2 6/7] media: iris: add iris4 specific H265 line buffer calculation

Vikash Garodia posted 7 patches 1 month, 1 week ago
There is a newer version of this series
[PATCH v2 6/7] media: iris: add iris4 specific H265 line buffer calculation
Posted by Vikash Garodia 1 month, 1 week ago 
The H265 decoder line buffer size calculation for iris4 (VPU4) was
previously reusing the iris3 formula. While this works for most
resolutions, certain configurations require a larger buffer size on
iris4, causing firmware errors during decode. This resolves firmware
failures seen with specific test vectors on kaanapali (iris4), and fixes
the following failing fluster tests
- PICSIZE_C_Bossen_1
- WPP_E_ericsson_MAIN_2

Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 51 +++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
index 9270422c16019ba658ee8813940cb9110ad030a1..a4d599c49ce9052b609b9cedf65f669ba78b5407 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
+++ b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
@@ -1755,6 +1755,55 @@ static u32 hfi_vpu4x_buffer_line_vp9d(u32 frame_width, u32 frame_height, u32 _yu
 	return lb_size + dpb_obp_size;
 }
 
+static u32 hfi_vpu4x_buffer_line_h265d(u32 frame_width, u32 frame_height, bool is_opb,
+				       u32 num_vpp_pipes)
+{
+	u32 num_lcu_per_pipe, fe_left_lb, se_left_lb, vsp_left_lb, top_lb, qp_size,
+	    dpb_obp = 0, lcu_size = 16;
+
+	num_lcu_per_pipe = (DIV_ROUND_UP(frame_height, lcu_size) / num_vpp_pipes) +
+			   (DIV_ROUND_UP(frame_height, lcu_size) % num_vpp_pipes);
+
+	fe_left_lb = ALIGN((DMA_ALIGNMENT * num_lcu_per_pipe), DMA_ALIGNMENT) *
+				FE_LFT_CTRL_LINE_NUMBERS;
+	fe_left_lb += ALIGN((DMA_ALIGNMENT * 2 * num_lcu_per_pipe), DMA_ALIGNMENT) *
+				FE_LFT_DB_DATA_LINE_NUMBERS;
+	fe_left_lb += ALIGN((DMA_ALIGNMENT * num_lcu_per_pipe), DMA_ALIGNMENT);
+	fe_left_lb += ALIGN((DMA_ALIGNMENT * 2 * num_lcu_per_pipe), DMA_ALIGNMENT);
+	fe_left_lb += ALIGN((DMA_ALIGNMENT * 8 * num_lcu_per_pipe), DMA_ALIGNMENT) *
+				FE_LFT_LR_DATA_LINE_NUMBERS;
+
+	if (is_opb)
+		dpb_obp = size_dpb_opb(frame_height, lcu_size) * num_vpp_pipes;
+
+	se_left_lb = max_t(u32, (ALIGN(frame_height, BUFFER_ALIGNMENT_16_BYTES) >> 3) *
+				MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE,
+				max_t(u32, (ALIGN(frame_height, BUFFER_ALIGNMENT_32_BYTES) >> 3) *
+				MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE,
+				(ALIGN(frame_height, BUFFER_ALIGNMENT_64_BYTES) >> 3) *
+				MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE));
+
+	vsp_left_lb = ALIGN(DIV_ROUND_UP(frame_height, BUFFER_ALIGNMENT_64_BYTES) *
+				H265_NUM_TILE_ROW, DMA_ALIGNMENT);
+
+	top_lb = ALIGN((DMA_ALIGNMENT * DIV_ROUND_UP(frame_width, lcu_size)), DMA_ALIGNMENT) *
+				FE_TOP_CTRL_LINE_NUMBERS;
+	top_lb += ALIGN(DMA_ALIGNMENT * 2 * DIV_ROUND_UP(frame_width, lcu_size), DMA_ALIGNMENT) *
+				FE_TOP_DATA_LUMA_LINE_NUMBERS;
+	top_lb += ALIGN(DMA_ALIGNMENT * 2 * (DIV_ROUND_UP(frame_width, lcu_size) + 1),
+			DMA_ALIGNMENT) * FE_TOP_DATA_CHROMA_LINE_NUMBERS;
+	top_lb += ALIGN(ALIGN(frame_width, BUFFER_ALIGNMENT_64_BYTES) * 2, DMA_ALIGNMENT);
+	top_lb += ALIGN(ALIGN(frame_width, BUFFER_ALIGNMENT_64_BYTES) * 6, DMA_ALIGNMENT);
+	top_lb += size_h265d_lb_vsp_top(frame_width, frame_height);
+
+	qp_size = size_h265d_qp(frame_width, frame_height);
+
+	return ((ALIGN(dpb_obp, DMA_ALIGNMENT) + ALIGN(se_left_lb, DMA_ALIGNMENT) +
+		ALIGN(vsp_left_lb, DMA_ALIGNMENT)) * num_vpp_pipes) +
+		ALIGN(fe_left_lb, DMA_ALIGNMENT) + ALIGN(top_lb, DMA_ALIGNMENT) +
+		ALIGN(qp_size, DMA_ALIGNMENT);
+}
+
 static u32 iris_vpu4x_dec_line_size(struct iris_inst *inst)
 {
 	u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
@@ -1770,7 +1819,7 @@ static u32 iris_vpu4x_dec_line_size(struct iris_inst *inst)
 	if (inst->codec == V4L2_PIX_FMT_H264)
 		return hfi_buffer_line_h264d(width, height, is_opb, num_vpp_pipes);
 	else if (inst->codec == V4L2_PIX_FMT_HEVC)
-		return hfi_buffer_line_h265d(width, height, is_opb, num_vpp_pipes);
+		return hfi_vpu4x_buffer_line_h265d(width, height, is_opb, num_vpp_pipes);
 	else if (inst->codec == V4L2_PIX_FMT_VP9)
 		return hfi_vpu4x_buffer_line_vp9d(width, height, out_min_count, is_opb,
 						  num_vpp_pipes);

-- 
2.34.1
Re: [PATCH v2 6/7] media: iris: add iris4 specific H265 line buffer calculation
Posted by Dmitry Baryshkov 1 month, 1 week ago 
On Fri, Feb 27, 2026 at 07:41:22PM +0530, Vikash Garodia wrote:
> The H265 decoder line buffer size calculation for iris4 (VPU4) was
> previously reusing the iris3 formula. While this works for most
> resolutions, certain configurations require a larger buffer size on
> iris4, causing firmware errors during decode. This resolves firmware
> failures seen with specific test vectors on kaanapali (iris4), and fixes
> the following failing fluster tests
> - PICSIZE_C_Bossen_1
> - WPP_E_ericsson_MAIN_2

This reminds me of the commit fixing SC7280 support. Should SC7280 or
all VPU2.0 platforms also use separate formula?

> 
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>  drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 51 +++++++++++++++++++++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> index 9270422c16019ba658ee8813940cb9110ad030a1..a4d599c49ce9052b609b9cedf65f669ba78b5407 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> @@ -1755,6 +1755,55 @@ static u32 hfi_vpu4x_buffer_line_vp9d(u32 frame_width, u32 frame_height, u32 _yu
>  	return lb_size + dpb_obp_size;
>  }
>  
> +static u32 hfi_vpu4x_buffer_line_h265d(u32 frame_width, u32 frame_height, bool is_opb,
> +				       u32 num_vpp_pipes)
> +{
> +	u32 num_lcu_per_pipe, fe_left_lb, se_left_lb, vsp_left_lb, top_lb, qp_size,
> +	    dpb_obp = 0, lcu_size = 16;
> +
> +	num_lcu_per_pipe = (DIV_ROUND_UP(frame_height, lcu_size) / num_vpp_pipes) +
> +			   (DIV_ROUND_UP(frame_height, lcu_size) % num_vpp_pipes);
> +
> +	fe_left_lb = ALIGN((DMA_ALIGNMENT * num_lcu_per_pipe), DMA_ALIGNMENT) *
> +				FE_LFT_CTRL_LINE_NUMBERS;
> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * 2 * num_lcu_per_pipe), DMA_ALIGNMENT) *
> +				FE_LFT_DB_DATA_LINE_NUMBERS;
> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * num_lcu_per_pipe), DMA_ALIGNMENT);
> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * 2 * num_lcu_per_pipe), DMA_ALIGNMENT);
> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * 8 * num_lcu_per_pipe), DMA_ALIGNMENT) *
> +				FE_LFT_LR_DATA_LINE_NUMBERS;
> +
> +	if (is_opb)
> +		dpb_obp = size_dpb_opb(frame_height, lcu_size) * num_vpp_pipes;
> +
> +	se_left_lb = max_t(u32, (ALIGN(frame_height, BUFFER_ALIGNMENT_16_BYTES) >> 3) *
> +				MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE,
> +				max_t(u32, (ALIGN(frame_height, BUFFER_ALIGNMENT_32_BYTES) >> 3) *
> +				MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE,
> +				(ALIGN(frame_height, BUFFER_ALIGNMENT_64_BYTES) >> 3) *
> +				MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE));
> +
> +	vsp_left_lb = ALIGN(DIV_ROUND_UP(frame_height, BUFFER_ALIGNMENT_64_BYTES) *
> +				H265_NUM_TILE_ROW, DMA_ALIGNMENT);
> +
> +	top_lb = ALIGN((DMA_ALIGNMENT * DIV_ROUND_UP(frame_width, lcu_size)), DMA_ALIGNMENT) *
> +				FE_TOP_CTRL_LINE_NUMBERS;
> +	top_lb += ALIGN(DMA_ALIGNMENT * 2 * DIV_ROUND_UP(frame_width, lcu_size), DMA_ALIGNMENT) *
> +				FE_TOP_DATA_LUMA_LINE_NUMBERS;
> +	top_lb += ALIGN(DMA_ALIGNMENT * 2 * (DIV_ROUND_UP(frame_width, lcu_size) + 1),
> +			DMA_ALIGNMENT) * FE_TOP_DATA_CHROMA_LINE_NUMBERS;
> +	top_lb += ALIGN(ALIGN(frame_width, BUFFER_ALIGNMENT_64_BYTES) * 2, DMA_ALIGNMENT);
> +	top_lb += ALIGN(ALIGN(frame_width, BUFFER_ALIGNMENT_64_BYTES) * 6, DMA_ALIGNMENT);
> +	top_lb += size_h265d_lb_vsp_top(frame_width, frame_height);
> +
> +	qp_size = size_h265d_qp(frame_width, frame_height);
> +
> +	return ((ALIGN(dpb_obp, DMA_ALIGNMENT) + ALIGN(se_left_lb, DMA_ALIGNMENT) +
> +		ALIGN(vsp_left_lb, DMA_ALIGNMENT)) * num_vpp_pipes) +
> +		ALIGN(fe_left_lb, DMA_ALIGNMENT) + ALIGN(top_lb, DMA_ALIGNMENT) +
> +		ALIGN(qp_size, DMA_ALIGNMENT);
> +}
> +
>  static u32 iris_vpu4x_dec_line_size(struct iris_inst *inst)
>  {
>  	u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
> @@ -1770,7 +1819,7 @@ static u32 iris_vpu4x_dec_line_size(struct iris_inst *inst)
>  	if (inst->codec == V4L2_PIX_FMT_H264)
>  		return hfi_buffer_line_h264d(width, height, is_opb, num_vpp_pipes);
>  	else if (inst->codec == V4L2_PIX_FMT_HEVC)
> -		return hfi_buffer_line_h265d(width, height, is_opb, num_vpp_pipes);
> +		return hfi_vpu4x_buffer_line_h265d(width, height, is_opb, num_vpp_pipes);
>  	else if (inst->codec == V4L2_PIX_FMT_VP9)
>  		return hfi_vpu4x_buffer_line_vp9d(width, height, out_min_count, is_opb,
>  						  num_vpp_pipes);
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry
Re: [PATCH v2 6/7] media: iris: add iris4 specific H265 line buffer calculation
Posted by Vikash Garodia 1 month ago 
On 2/28/2026 1:58 AM, Dmitry Baryshkov wrote:
> On Fri, Feb 27, 2026 at 07:41:22PM +0530, Vikash Garodia wrote:
>> The H265 decoder line buffer size calculation for iris4 (VPU4) was
>> previously reusing the iris3 formula. While this works for most
>> resolutions, certain configurations require a larger buffer size on
>> iris4, causing firmware errors during decode. This resolves firmware
>> failures seen with specific test vectors on kaanapali (iris4), and fixes
>> the following failing fluster tests
>> - PICSIZE_C_Bossen_1
>> - WPP_E_ericsson_MAIN_2
> 
> This reminds me of the commit fixing SC7280 support. Should SC7280 or
> all VPU2.0 platforms also use separate formula?
> 
for vpu2, there is already a separate formula

>>
>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 51 +++++++++++++++++++++-
>>   1 file changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
>> index 9270422c16019ba658ee8813940cb9110ad030a1..a4d599c49ce9052b609b9cedf65f669ba78b5407 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
>> @@ -1755,6 +1755,55 @@ static u32 hfi_vpu4x_buffer_line_vp9d(u32 frame_width, u32 frame_height, u32 _yu
>>   	return lb_size + dpb_obp_size;
>>   }
>>   
>> +static u32 hfi_vpu4x_buffer_line_h265d(u32 frame_width, u32 frame_height, bool is_opb,
>> +				       u32 num_vpp_pipes)
>> +{
>> +	u32 num_lcu_per_pipe, fe_left_lb, se_left_lb, vsp_left_lb, top_lb, qp_size,
>> +	    dpb_obp = 0, lcu_size = 16;
>> +
>> +	num_lcu_per_pipe = (DIV_ROUND_UP(frame_height, lcu_size) / num_vpp_pipes) +
>> +			   (DIV_ROUND_UP(frame_height, lcu_size) % num_vpp_pipes);
>> +
>> +	fe_left_lb = ALIGN((DMA_ALIGNMENT * num_lcu_per_pipe), DMA_ALIGNMENT) *
>> +				FE_LFT_CTRL_LINE_NUMBERS;
>> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * 2 * num_lcu_per_pipe), DMA_ALIGNMENT) *
>> +				FE_LFT_DB_DATA_LINE_NUMBERS;
>> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * num_lcu_per_pipe), DMA_ALIGNMENT);
>> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * 2 * num_lcu_per_pipe), DMA_ALIGNMENT);
>> +	fe_left_lb += ALIGN((DMA_ALIGNMENT * 8 * num_lcu_per_pipe), DMA_ALIGNMENT) *
>> +				FE_LFT_LR_DATA_LINE_NUMBERS;
>> +
>> +	if (is_opb)
>> +		dpb_obp = size_dpb_opb(frame_height, lcu_size) * num_vpp_pipes;
>> +
>> +	se_left_lb = max_t(u32, (ALIGN(frame_height, BUFFER_ALIGNMENT_16_BYTES) >> 3) *
>> +				MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE,
>> +				max_t(u32, (ALIGN(frame_height, BUFFER_ALIGNMENT_32_BYTES) >> 3) *
>> +				MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE,
>> +				(ALIGN(frame_height, BUFFER_ALIGNMENT_64_BYTES) >> 3) *
>> +				MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE));
>> +
>> +	vsp_left_lb = ALIGN(DIV_ROUND_UP(frame_height, BUFFER_ALIGNMENT_64_BYTES) *
>> +				H265_NUM_TILE_ROW, DMA_ALIGNMENT);
>> +
>> +	top_lb = ALIGN((DMA_ALIGNMENT * DIV_ROUND_UP(frame_width, lcu_size)), DMA_ALIGNMENT) *
>> +				FE_TOP_CTRL_LINE_NUMBERS;
>> +	top_lb += ALIGN(DMA_ALIGNMENT * 2 * DIV_ROUND_UP(frame_width, lcu_size), DMA_ALIGNMENT) *
>> +				FE_TOP_DATA_LUMA_LINE_NUMBERS;
>> +	top_lb += ALIGN(DMA_ALIGNMENT * 2 * (DIV_ROUND_UP(frame_width, lcu_size) + 1),
>> +			DMA_ALIGNMENT) * FE_TOP_DATA_CHROMA_LINE_NUMBERS;
>> +	top_lb += ALIGN(ALIGN(frame_width, BUFFER_ALIGNMENT_64_BYTES) * 2, DMA_ALIGNMENT);
>> +	top_lb += ALIGN(ALIGN(frame_width, BUFFER_ALIGNMENT_64_BYTES) * 6, DMA_ALIGNMENT);
>> +	top_lb += size_h265d_lb_vsp_top(frame_width, frame_height);
>> +
>> +	qp_size = size_h265d_qp(frame_width, frame_height);
>> +
>> +	return ((ALIGN(dpb_obp, DMA_ALIGNMENT) + ALIGN(se_left_lb, DMA_ALIGNMENT) +
>> +		ALIGN(vsp_left_lb, DMA_ALIGNMENT)) * num_vpp_pipes) +
>> +		ALIGN(fe_left_lb, DMA_ALIGNMENT) + ALIGN(top_lb, DMA_ALIGNMENT) +
>> +		ALIGN(qp_size, DMA_ALIGNMENT);
>> +}
>> +
>>   static u32 iris_vpu4x_dec_line_size(struct iris_inst *inst)
>>   {
>>   	u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
>> @@ -1770,7 +1819,7 @@ static u32 iris_vpu4x_dec_line_size(struct iris_inst *inst)
>>   	if (inst->codec == V4L2_PIX_FMT_H264)
>>   		return hfi_buffer_line_h264d(width, height, is_opb, num_vpp_pipes);
>>   	else if (inst->codec == V4L2_PIX_FMT_HEVC)
>> -		return hfi_buffer_line_h265d(width, height, is_opb, num_vpp_pipes);
>> +		return hfi_vpu4x_buffer_line_h265d(width, height, is_opb, num_vpp_pipes);
>>   	else if (inst->codec == V4L2_PIX_FMT_VP9)
>>   		return hfi_vpu4x_buffer_line_vp9d(width, height, out_min_count, is_opb,
>>   						  num_vpp_pipes);
>>
>> -- 
>> 2.34.1
>>
>
Re: [PATCH v2 6/7] media: iris: add iris4 specific H265 line buffer calculation
Posted by Dmitry Baryshkov 1 month ago 
On Wed, Mar 04, 2026 at 12:18:58AM +0530, Vikash Garodia wrote:
> 
> On 2/28/2026 1:58 AM, Dmitry Baryshkov wrote:
> > On Fri, Feb 27, 2026 at 07:41:22PM +0530, Vikash Garodia wrote:
> > > The H265 decoder line buffer size calculation for iris4 (VPU4) was
> > > previously reusing the iris3 formula. While this works for most
> > > resolutions, certain configurations require a larger buffer size on
> > > iris4, causing firmware errors during decode. This resolves firmware
> > > failures seen with specific test vectors on kaanapali (iris4), and fixes
> > > the following failing fluster tests
> > > - PICSIZE_C_Bossen_1
> > > - WPP_E_ericsson_MAIN_2
> > 
> > This reminds me of the commit fixing SC7280 support. Should SC7280 or
> > all VPU2.0 platforms also use separate formula?
> > 
> for vpu2, there is already a separate formula

It was more of "do we need separate formulas within vpu2".

> 
> > > 
> > > Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> > > Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > > ---
> > >   drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 51 +++++++++++++++++++++-
> > >   1 file changed, 50 insertions(+), 1 deletion(-)
> > > 

-- 
With best wishes
Dmitry
Re: [PATCH v2 6/7] media: iris: add iris4 specific H265 line buffer calculation
Posted by Vikash Garodia 1 month ago 
On 3/4/2026 3:58 AM, Dmitry Baryshkov wrote:
> On Wed, Mar 04, 2026 at 12:18:58AM +0530, Vikash Garodia wrote:
>>
>> On 2/28/2026 1:58 AM, Dmitry Baryshkov wrote:
>>> On Fri, Feb 27, 2026 at 07:41:22PM +0530, Vikash Garodia wrote:
>>>> The H265 decoder line buffer size calculation for iris4 (VPU4) was
>>>> previously reusing the iris3 formula. While this works for most
>>>> resolutions, certain configurations require a larger buffer size on
>>>> iris4, causing firmware errors during decode. This resolves firmware
>>>> failures seen with specific test vectors on kaanapali (iris4), and fixes
>>>> the following failing fluster tests
>>>> - PICSIZE_C_Bossen_1
>>>> - WPP_E_ericsson_MAIN_2
>>>
>>> This reminds me of the commit fixing SC7280 support. Should SC7280 or
>>> all VPU2.0 platforms also use separate formula?
>>>
>> for vpu2, there is already a separate formula
> 
> It was more of "do we need separate formulas within vpu2".

vpu2/3 uses the same one currently here [1].

vpu4 seems to be using quite a different formula to consider it within 
vpu2/3.

[1]https://elixir.bootlin.com/linux/v6.19.3/source/drivers/media/platform/qcom/iris/iris_vpu_buffer.c#L313

> 
>>
>>>>
>>>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>>>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>> ---
>>>>    drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 51 +++++++++++++++++++++-
>>>>    1 file changed, 50 insertions(+), 1 deletion(-)
>>>>
>
Re: [PATCH v2 6/7] media: iris: add iris4 specific H265 line buffer calculation
Posted by Dmitry Baryshkov 1 month ago 
On Wed, Mar 04, 2026 at 09:10:33PM +0530, Vikash Garodia wrote:
> 
> On 3/4/2026 3:58 AM, Dmitry Baryshkov wrote:
> > On Wed, Mar 04, 2026 at 12:18:58AM +0530, Vikash Garodia wrote:
> > > 
> > > On 2/28/2026 1:58 AM, Dmitry Baryshkov wrote:
> > > > On Fri, Feb 27, 2026 at 07:41:22PM +0530, Vikash Garodia wrote:
> > > > > The H265 decoder line buffer size calculation for iris4 (VPU4) was
> > > > > previously reusing the iris3 formula. While this works for most
> > > > > resolutions, certain configurations require a larger buffer size on
> > > > > iris4, causing firmware errors during decode. This resolves firmware
> > > > > failures seen with specific test vectors on kaanapali (iris4), and fixes
> > > > > the following failing fluster tests
> > > > > - PICSIZE_C_Bossen_1
> > > > > - WPP_E_ericsson_MAIN_2
> > > > 
> > > > This reminds me of the commit fixing SC7280 support. Should SC7280 or
> > > > all VPU2.0 platforms also use separate formula?
> > > > 
> > > for vpu2, there is already a separate formula
> > 
> > It was more of "do we need separate formulas within vpu2".
> 
> vpu2/3 uses the same one currently here [1].
> 
> vpu4 seems to be using quite a different formula to consider it within
> vpu2/3.
> 
> [1]https://elixir.bootlin.com/linux/v6.19.3/source/drivers/media/platform/qcom/iris/iris_vpu_buffer.c#L313

Ack

-- 
With best wishes
Dmitry

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.