Re: [PATCH v3 2/3] media: iris: Add support for Milos (VPU v2.0)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Incorrect VPU capacity initialization in `platform_inst_cap_milos` missing `mb_cycles_vsp`.
--

commit 9ae4cf8b25a90957e77a00cd4a1116d4be3f9fae
Author: Alexander Koskovich <akoskovich@pm.me>

    media: iris: Add support for Milos (VPU v2.0)
    
Add support for the Milos Iris codec variant found on the SM7635-AB.

> diff --git a/drivers/media/platform/qcom/iris/iris_platform_milos.h b/drivers/media/platform/qcom/iris/iris_platform_milos.h
> new file mode 100644
> index 0000000000000..3b6feeda76cbd
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_platform_milos.h
> @@ -0,0 +1,28 @@

[ ... ]

> +static struct platform_inst_caps platform_inst_cap_milos = {
> +	.min_frame_width = 96,
> +	.max_frame_width = 4096,
> +	.min_frame_height = 96,
> +	.max_frame_height = 4096,
> +	.max_mbpf = (4096 * 2176) / 256,
> +	.mb_cycles_vpp = 200,
> +	.mb_cycles_fw = 326389,
> +	.mb_cycles_fw_vpp = 44156,

[Severity: Low]
Does this code mistakenly initialize VPU3 fields instead of the required
VPU2 field (mb_cycles_vsp) for the Milos platform?

Because mb_cycles_vsp is missing, it defaults to 0, which causes the
macroblock-dependent component to evaluate to 0 in:

drivers/media/platform/qcom/iris/iris_vpu2.c:iris_vpu2_calc_freq() {
    ...
    vsp_freq = mbs_per_second * caps->mb_cycles_vsp;
    ...
}

While vpp_freq (calculated from mb_cycles_vpp = 200) typically dwarfs
the missing VSP component in almost all practical scenarios, making this
unlikely to cause a severe bottleneck, shouldn't we still provide the
correct mb_cycles_vsp value here and remove the unused VPU3 fields?

> +	.max_frame_rate = MILOS_MAXIMUM_FPS,
> +	.max_operating_rate = MILOS_MAXIMUM_FPS,
> +};
> +
> +#endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705-milos-iris-v3-0-8c1353530f24@pm.me?part=2