Re: [PATCH v2 10/11] media: qcom: iris: split firmware_data from raw platform data

[Dikshita Agarwal]

On 3/11/2026 5:53 AM, Dmitry Baryshkov wrote:
> On Fri, Mar 06, 2026 at 04:28:48PM +0530, Dikshita Agarwal wrote:
>>
>>
>> On 2/28/2026 8:56 PM, Dmitry Baryshkov wrote:
>>
>>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
>>> index a936ab2aedaf..be3449861993 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>>> @@ -201,9 +201,32 @@ enum platform_pm_domain_type {
>>>  	IRIS_APV_HW_POWER_DOMAIN,
>>>  };
>>>  
>>> -struct iris_platform_data {
>>> +struct iris_firmware_data {
>>>  	void (*init_hfi_ops)(struct iris_core *core);
>>> +
>>>  	u32 (*get_vpu_buffer_size)(struct iris_inst *inst, enum iris_buffer_type buffer_type);
>>
>> Makes sense to split firmware-related data out of iris_platform_data into a
>> dedicated iris_firmware_data, one comment though, get_vpu_buffer_size
>> should be in iris_platform_data since it describes the VPU’s buffer
>> requirements independent of whether the SoC runs gen1/gen2 HFI firmware.
> 
> Not really... Your patchset to bringup Gen2 on Kodiak points out that
> this callback depends on the firmware: we currently use
> iris_vpu_buf_size() for Gen1, your patch have used iris_vpu33_buf_size()
> with an explicit comment that it requires a bigger buffer.

Agreed. However, that case is somewhat unique because the firmware code
changed significantly between the Gen1 and Gen2 releases. In general, the
buffer size is determined primarily by the VPU architecture, as well as by
the features being supported—especially when specific features require
updated buffer allocations.

Thanks,
Dikshita

> 
>