Re: [PATCH v4 7/8] media: qcom: iris: split firmware_data from raw platform data

[Dmitry Baryshkov]

On Fri, Mar 13, 2026 at 02:26:12PM +0530, Dikshita Agarwal wrote:
> 
> > diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> > index d1daef2d874b..1a870fec4f31 100644
> > --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> > +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> > @@ -201,45 +201,16 @@ 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);
> > -	const struct vpu_ops *vpu_ops;
> > -	const struct icc_info *icc_tbl;
> > -	unsigned int icc_tbl_size;
> > -	const struct bw_info *bw_tbl_dec;
> > -	unsigned int bw_tbl_dec_size;
> > -	const char * const *pmdomain_tbl;
> > -	unsigned int pmdomain_tbl_size;
> > -	const char * const *opp_pd_tbl;
> > -	unsigned int opp_pd_tbl_size;
> > -	const struct platform_clk_data *clk_tbl;
> > -	const char * const *opp_clk_tbl;
> > -	unsigned int clk_tbl_size;
> > -	const char * const *clk_rst_tbl;
> > -	unsigned int clk_rst_tbl_size;
> > -	const char * const *controller_rst_tbl;
> > -	unsigned int controller_rst_tbl_size;
> > -	u64 dma_mask;
> > -	const char *fwname;
> > -	struct iris_fmt *inst_iris_fmts;
> > -	u32 inst_iris_fmts_size;
> > -	struct platform_inst_caps *inst_caps;
> > +
> >  	const struct platform_inst_fw_cap *inst_fw_caps_dec;
> >  	u32 inst_fw_caps_dec_size;
> >  	const struct platform_inst_fw_cap *inst_fw_caps_enc;
> 
> Thinking further about this split, I see another potential issue here.
> Some of the inst_fw_caps are not purely HFI dependent, but also vary with
> the VPU architecture. For example, on AR50LT (Agatti), certain capabilities
> such as rotation/flip are not supported, even though these platforms still
> use HFI Gen2.
> 
> With the current approach, handling this would likely require having the
> structure in lets say iris_plaform_agatti.h which would be included in both
> iris_hfi_gen2.c and iris_platform_ar50lt.c which would lead to duplicate
> inclusion, the same concern you raised in kodiak gen2 patches.
> 
> How do we tackle this problem?

With the current proposal it would be iris_hfi_gen2_ar50lt, a part of
the corresponding iris_hfi_gen2.c. I have no issue with duplicating some
bits of generic structures. Also, currently I can't see a clear pattern,
how to split this data, so I'm simply pushing it away from the per-SoC
data.

Maybe we will reconsider this during / while working on AR50LT. I hope
to have time to bring up Iris 1.xx (SM8150, SC8180X), which would use
Gen1, but it might have different caps or different params (I haven't
checked, sorry). Likewise I hope to have time for SM8450, which is also
Iris 2 but using Gen2 interface. Last, but not least, after we bring up
AR50LT in the iris driver, I'm tempted to look at SM6115 support (it's
another AR50LT platform, there is the Qualcomm Robotics RB2 device using
it).

-- 
With best wishes
Dmitry