Re: [PATCH RFC 07/10] drm/msm/dpu: describe SM6125 programmable-fetch delayed-start quirk

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional addition of `horiz_total` to `vfp_fetch_start_vsync_counter` can push the fetch trigger out of bounds, preventing it from firing.
--

commit 2270768f2936b4e384a8e10940ee1267f2738202
Author: YİĞİTCAN KAVAKLI <kavakliyigitcan@gmail.com>

drm/msm/dpu: describe SM6125 programmable-fetch delayed-start quirk

This commit introduces a workaround for the SM6125 DPU where the programmable
prefetch start counter evaluating on the active-video to vertical front porch
boundary causes FIFO overflows. It adds a has_prg_fetch_delay quirk to delay
the fetch start by one scanline by adding horiz_total to the counter.

> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> index ba810f26ea309..15445eaf9f3ba 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
[ ... ]
> @@ -237,10 +237,21 @@ static void programmable_fetch_config(struct dpu_encoder_phys *phys_enc,
>  
>  	vfp_fetch_lines = programmable_fetch_get_num_lines(phys_enc, timing);
>  	if (vfp_fetch_lines) {
> +		const struct dpu_mdss_cfg *catalog = phys_enc->dpu_kms->catalog;
> +
>  		vert_total = get_vertical_total(timing);
>  		horiz_total = get_horizontal_total(timing);
>  		vfp_fetch_start_vsync_counter =
>  		    (vert_total - vfp_fetch_lines) * horiz_total + 1;
> +
> +		/*
> +		 * SM6125 (DPU 5.4 / Trinket) quirk matching downstream
> +		 * delay_prg_fetch_start = true. Throttle fetch start
> +		 * to the second line after active video (VFP line 1).
> +		 */
> +		if (catalog && catalog->caps && catalog->caps->has_prg_fetch_delay)
> +			vfp_fetch_start_vsync_counter += horiz_total;

[Severity: High]
Could this unconditional addition push the fetch start counter out of bounds?

If a panel is configured such that vfp_fetch_lines evaluates to 1,
vfp_fetch_start_vsync_counter initially calculates to:
(vert_total - 1) * horiz_total + 1

Adding horiz_total then makes the counter evaluate to:
vert_total * horiz_total + 1

Since a full frame consists of exactly vert_total * horiz_total pixels, the
hardware vsync counter will wrap at the end of the frame before reaching this
new value. Will this prevent the programmable fetch trigger from ever firing
and result in a complete loss of pixel output?

> +
>  		f.enable = 1;
>  		f.fetch_start = vfp_fetch_start_vsync_counter;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-ginkgo-submission-final-v1-0-0e68e63a18d4@gmail.com?part=7