Re: [PATCH v2 3/4] drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Moving the pixel clock limits from an output-specific check to a global per-SoC limit drops the DPAD0 clock limit for RZ/G2L and prevents setting per-interface limits.
--

commit df71add63cd01bd86e697f0d293fcfc2d68de83e
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits

This commit shifts pixel clock validation from a hardcoded encoder output
check to per-SoC limits defined in rzg2l_du_device_info. It adds clock
bounds for RZ/G2UL and checks these limits against the display mode clock.

> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> index 5e6dd16705e60..2fb79d11ab151 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> @@ -50,8 +50,12 @@ rzg2l_du_encoder_mode_valid(struct drm_encoder *encoder,
>  			    const struct drm_display_mode *mode)
>  {
>  	struct rzg2l_du_encoder *renc = to_rzg2l_encoder(encoder);
> +	struct rzg2l_du_device *rcdu = to_rzg2l_du_device(renc->base.dev);
> +	const struct rzg2l_du_device_info *info = rcdu->info;
>  
> -	if (renc->output == RZG2L_DU_OUTPUT_DPAD0 && mode->clock > 83500)
> +	if (info->mode_clock_min && mode->clock < info->mode_clock_min)
> +		return MODE_CLOCK_LOW;
> +	if (info->mode_clock_max && mode->clock > info->mode_clock_max)
>  		return MODE_CLOCK_HIGH;

Does replacing the output-specific check with a global per-SoC limit
unintentionally drop the 83.5 MHz restriction for DPAD0 on SoCs with
multiple outputs?

Looking at rzg2l_du_r9a07g044_info in rzg2l_du_drv.c, the RZ/G2L SoC
supports both DSI0 and DPAD0 outputs, but no mode_clock_max is set for it
by this patch. This means DPAD0 on RZ/G2L loses its original 83.5 MHz
limit.

If a global mode_clock_max were added to the RZ/G2L info struct to restore
this limit, wouldn't it incorrectly throttle the DSI0 interface as well?

Should these limits be placed in struct rzg2l_du_output_routing instead
so that per-interface limits can still be enforced?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260508111744.771659-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=3