Re: [PATCH 2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Calling usleep_range() inside a clk_ops->enable callback will trigger a 'scheduling while atomic' BUG.
- [Medium] The PLL rate is clamped to a maximum of 1.6 GHz, rendering the new high-speed voltage logic for rates >= 2.0 GHz completely unreachable.
--

commit af99b6688956e76bb38344e38d2af3b56056ec47
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

phy: mediatek: Add support for MT8196 MIPI DSI PHY

Add support for the MIPI DSI PHY found in the MediaTek MT8196 SoC
and its variants. This initial driver only adds support for basic
functionality that is necessary to drive MIPI DSI displays as a D-PHY.

> diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c
> new file mode 100644
> index 0000000000000..273f236fa7e9e
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c

[ ... ]

> +static int mtk_mipi_tx_pll_enable(struct clk_hw *hw)
> +{
> +	struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
> +	void __iomem *base = mipi_tx->regs;
> +	u32 voltage = RG_DSI_PRD_REF_MINI;
> +	u32 pres = MIPITX_PRESERVED_MINI;
> +	unsigned long long pcw_calc;
> +	unsigned int txdiv, txdiv0;
> +	u32 pcw;
> +
> +	dev_dbg(mipi_tx->dev, "enable: %u bps\n", mipi_tx->data_rate);
> +
> +	if (mipi_tx->data_rate >= 2000000000) {
> +		/* Select higher signaling voltage for fast data rates */

[Severity: Medium]
Will this condition ever be met?

Further down in this patch, mtk_mipi_tx_pll_determine_rate() unconditionally
clamps the requested rate to a maximum of 1.6 GHz.

Since the framework passes this clamped rate to the set_rate callback, won't
this high-speed logic for 2.0 GHz become unreachable dead code?

> +		voltage = RG_DSI_PRD_REF_DEF;
> +		pres = MIPITX_PRESERVED_DEF;
> +		txdiv = 1;
> +		txdiv0 = 0;
> +	} else if (mipi_tx->data_rate >= 1000000000) {

[ ... ]

> +	mtk_phy_update_field(base + MIPITX_VOLTAGE_SEL, RG_DSI_PRD_REF_SEL, voltage);
> +	writel(pres, base + MIPITX_PRESERVED);
> +
> +	mtk_phy_set_bits(base + MIPITX_PLL_PWR, AD_DSI_PLL_SDM_PWR_ON);
> +	mtk_phy_clear_bits(base + MIPITX_PLL_CON1, RG_DSI_PLL_EN);
> +	usleep_range(30, 60);

[Severity: High]
Is it safe to sleep here?

The Common Clock Framework invokes clk_ops->enable callbacks with the
enable_lock spinlock held and local interrupts disabled.

Because mtk_mipi_tx_pll_enable() is registered as the .enable callback,
won't calling usleep_range() here in an atomic context trigger a
scheduling while atomic BUG?

Should this use udelay() instead, or could this logic be moved to the
.prepare callback where sleeping is permitted?

> +
> +	mtk_phy_clear_bits(base + MIPITX_PLL_PWR, AD_DSI_PLL_SDM_ISO_EN);
> +	writel(pcw, base + MIPITX_PLL_CON0);
> +	mtk_phy_update_field(base + MIPITX_PLL_CON1, RG_DSI_PLL_POSDIV, txdiv0);
> +	usleep_range(30, 60);
> +
> +	mtk_phy_set_bits(base + MIPITX_PLL_CON1, RG_DSI_PLL_EN);
> +	usleep_range(30, 60);
> +
> +	return 0;
> +}

[ ... ]

> +static int mtk_mipi_tx_pll_determine_rate(struct clk_hw *hw,
> +					  struct clk_rate_request *req)
> +{
> +	req->rate = clamp_val(req->rate, 125000000, 1600000000);

[Severity: Medium]
Is this maximum rate intentional for the MT8196?

This limits the rate to 1.6 GHz, which prevents the 2.0 GHz signaling
voltage logic in mtk_mipi_tx_pll_enable() from ever executing.

> +
> +	return 0;
> +}
> +
> +static const struct clk_ops mtk_mipi_tx_pll_ops = {
> +	.enable = mtk_mipi_tx_pll_enable,
> +	.disable = mtk_mipi_tx_pll_disable,
> +	.determine_rate = mtk_mipi_tx_pll_determine_rate,
> +	.set_rate = mtk_mipi_tx_pll_set_rate,
> +	.recalc_rate = mtk_mipi_tx_pll_recalc_rate,
> +};

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701121943.19430-1-angelogioacchino.delregno@collabora.com?part=2