Re: [PATCH v4 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Strict inequality check for maximum lane bit rate incorrectly rejects exact boundary values, causing valid display modes to fail.
--

--- Patch [1]: [PATCH v4 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation ---
commit c849fa328462e27e823555ae008f52416cbc0bb9
Author: Chaoyi Chen <chaoyi.chen@rock-chips.com>

drm/rockchip: dsi: Add maximum per lane bit rate calculation

This commit introduces chip-specific maximum lane bit rate boundaries for the
Rockchip DW MIPI DSI driver. This allows varying maximums per platform rather
than using a hardcoded 1500 Mbps default.

> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 268d4993a04fd..fd91343d0f6d5 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c

[ ... ]

> @@ -572,6 +573,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>  	unsigned long _fbdiv, best_fbdiv;
>  	unsigned long min_delta = ULONG_MAX;
>  
> +	max_mbps = dsi->cdata->max_bit_rate_per_lane / USEC_PER_SEC;

[Severity: Medium]
Will this cause display modes that exactly match the new lower max_mbps
to fail?

In dw_mipi_dsi_get_lane_mbps(), there is a strict inequality check shortly
after this assignment:

        /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
        tmp = DIV_ROUND_UP(mpclk * bpp * 10, lanes * 9);
        if (tmp < max_mbps)
                target_mbps = tmp;
        else
                DRM_DEV_ERROR(dsi->dev, "DPHY clock frequency is out of range\n");

Because this patch lowers the boundary to 1000 Mbps or 1200 Mbps for several
chips, display modes that yield a bandwidth exactly matching the chip's
maximum will now be rejected.

For example, a mode needing exactly 1000 Mbps would have previously passed
because 1000 < 1500, but will now fail since 1000 is not < 1000. Should the
check be updated to allow exact boundary values by using <= max_mbps?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812073002.328-1-kernel@airkyi.com?part=1