Re: [PATCH v6 05/12] media: iris: Route buffers to the matching context bank device

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: iris: BUF_SCRATCH_1 routed to pixel device in iris_get_cb_dev()
--

commit fb84105c9d23a8b5f8ddb71200e875eab85392ac
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

media: iris: Route buffers to the matching context bank device

This commit introduces iris_get_cb_dev() to route VPU buffers to either the
pixel or non-pixel SMMU context bank device based on buffer type and codec
domain, falling back to core->dev when context bank devices are absent. It
updates internal buffer allocation, HFI queue initialization, and V4L2 M2M
queue setup to use the corresponding context bank device.

[ ... ]

> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
> index 883ef7e752915..9dbf209e3d4c0 100644
> --- a/drivers/media/platform/qcom/iris/iris_resources.c
> +++ b/drivers/media/platform/qcom/iris/iris_resources.c

[ ... ]

> @@ -140,3 +141,43 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
>  
>  	return 0;
>  }
> +
> +struct device *iris_get_cb_dev(struct iris_inst *inst, enum iris_buffer_type buffer_type)
> +{
> +	struct iris_core *core = inst->core;
> +	struct device *dev = NULL;
> +
> +	switch (buffer_type) {
> +	case BUF_INPUT:
> +		if (inst->domain == DECODER)
> +			dev = core->np_dev;
> +		else
> +			dev = core->p_dev;
> +		break;
> +	case BUF_OUTPUT:
> +		if (inst->domain == DECODER)
> +			dev = core->p_dev;
> +		else
> +			dev = core->np_dev;
> +		break;
> +	case BUF_DPB:
> +	case BUF_PARTIAL:
> +	case BUF_SCRATCH_1:
> +	case BUF_SCRATCH_2:
> +	case BUF_VPSS:
> +		dev = core->p_dev;
> +		break;

[Severity: Medium]
Should BUF_SCRATCH_1 be routed to core->np_dev instead of core->p_dev in
iris_get_cb_dev()?

In drivers/media/platform/qcom/iris/iris_vpu_buffer.c, BUF_SCRATCH_1 is
defined as the combined internal buffer holding the COMV, NON_COMV, and LINE
buffers for HFI Gen1 platforms:

static u32 iris_vpu_dec_scratch1_size(struct iris_inst *inst)
{
	return iris_vpu_dec_comv_size(inst) +
		iris_vpu_dec_non_comv_size(inst) +
		iris_vpu_dec_line_size(inst);
}

Similarly, iris_vpu_ar50lt_dec_scratch1_size() and hfi_buffer_scratch1_enc()
combine the COMV, NON_COMV, and LINE buffers into BUF_SCRATCH_1, whereas
BUF_SCRATCH_2 holds the reconstructed reference frames.

When iris_create_internal_buffer() and iris_destroy_internal_buffer() call
iris_get_cb_dev() for HFI Gen1 internal buffer tables (such as
sm8250_dec_ip_int_buf_tbl, sm8250_enc_ip_int_buf_tbl, and
iris_hfi_gen1_ar50lt_dec_ip_int_buf_tbl in
drivers/media/platform/qcom/iris/iris_hfi_gen1.c), routing BUF_SCRATCH_1 to
core->p_dev maps it into the pixel context bank rather than the non-pixel
context bank used by BUF_COMV, BUF_NON_COMV, and BUF_LINE. Can this cause
SMMU faults on HFI Gen1 platforms when context bank devices are present?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103-vpu_iommu_iova_handling-v6-0-e4b6ad864f8f@oss.qualcomm.com?part=5