[RFC PATCH] phy: qcom-mipi-csi2: round the requested settle interval up

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] phy: qcom-mipi-csi2: ui_ps precision loss breaks DIV_ROUND_UP fix
--

commit e880e6c62291c5b55c478c5e10a255d82c92d9de
Author: Jizhou Tong <fqwqf at fqwqf.xyz>

phy: qcom-mipi-csi2: round the requested settle interval up

This commit updates the settling counter calculation to round up instead of
truncating when dividing by the timer period. This aims to ensure the
programmed ticks do not fall short of the required interval.

Link: https://lore.kernel.org/all/20260917-x1e-csi2-phy-v18-2-6515b5255fa9@linaro.org/

> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> index 966d79c98f9b2..ce1de1a689429 100644
> --- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> @@ -236,7 +236,8 @@ static u8 phy_qcom_mipi_csi2_settle_cnt_calc(s64 link_freq, u32 timer_clk_rate)
>  	if ((t_hs_settle_ps / timer_period_ps) < 6)
>  		return 0;
>  
> -	settle_cnt = t_hs_settle_ps / timer_period_ps - 6;
> +	/* Do not round the requested settling interval down. */
> +	settle_cnt = DIV_ROUND_UP(t_hs_settle_ps, timer_period_ps) - 6;

[Severity: Medium]
Does the intermediate truncation in the calculation of t_hs_settle_ps defeat
the purpose of this DIV_ROUND_UP fix?

Earlier in phy_qcom_mipi_csi2_settle_cnt_calc(), the unit interval is
calculated with two integer divisions:

        ui_ps = div64_u64(PSEC_PER_SEC, link_freq);
        ui_ps /= 2;

This underestimates the unit interval by up to ~1.5ps. Since
t_hs_prepare_max_ps multiplies this by 6, the truncation error is amplified
to ~9ps.

If the true maximum prepare time is just above a multiple of the timer
period (for example, 90,002ps), this 9ps error pushes the computed
t_hs_settle_ps just below that multiple (for example, 89,998ps).

In that scenario, DIV_ROUND_UP produces 1 tick less (9 ticks instead of 10),
causing the receiver window to open a full timer period too early. This
would violate the MIPI D-PHY T_HS-PREPARE max timing protocol on borderline
link frequencies.

Could this be avoided by using DIV_ROUND_UP_ULL(3 * PSEC_PER_SEC, link_freq)
to prevent the intermediate truncation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/010601a1251fbfb9-9afc4070-5194-4714-86b1-5358791e7770-000000@ap-northeast-1.amazonses.com?part=1