U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Lechner <dlechner@baylibre.com>
To: Julien Stephan <jstephan@baylibre.com>,
	u-boot@lists.u-boot-project.org,
	GSS_MTK_Uboot_upstream <GSS_MTK_Uboot_upstream@mediatek.com>
Cc: Tom Rini <trini@konsulko.com>,
	"Lucien.Jheng" <lucienzx159@gmail.com>,
	Ryder Lee <ryder.lee@mediatek.com>,
	Weijie Gao <weijie.gao@mediatek.com>,
	Chunfeng Yun <chunfeng.yun@mediatek.com>,
	Igor Belwon <igor.belwon@mentallysanemainliners.org>,
	Pavlo Yadvychuk <pyadvychuk@baylibre.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Mattijs Korpershoek <mkorpershoek@kernel.org>
Subject: Re: [PATCH 3/3] phy: phy-mtk-mipi-dsi: add new driver
Date: Wed, 23 Sep 2026 10:50:42 -0500	[thread overview]
Message-ID: <eded0ea7-a3ee-4735-b520-c0e2beccdd63@baylibre.com> (raw)
In-Reply-To: <20260915-mt8365-add-phy-mtk-mipi-dsi-driver-v1-3-83707ed5242a@baylibre.com>

On 9/15/26 10:00 AM, Julien Stephan wrote:
> Add a new driver for the MIPI DSI PHY. The driver supports MT8183
> compatible SoCs. The driver is base on the corresponding kernel driver

s/base/based/

> commit 2ec9c210c1f9 ("phy: mediatek: Add support for MT8196 MIPI DSI PHY")
> 
> Few notes about the port from kernel:

s/Few/A few/

> - tested on Genio-350 which does not have nvmem-cells, so keep rt_code[]
>   zeroed and fallback to 0x210 has kernel does when no cell available.

s/has/as the/

>   Can be implemented later.
> - PLL is not registered as a clock provider:
>     - configure() = determine_rate+set_rate
>     - power_on() = clk_prepare_enable
>   configure() takes a struct phy_configure_opts_mipi_dphy and uses its
>   hs_clk_rate member, which carries the per-lane data rate the kernel
>   would have set on the "hs" clock.
> 

...

> +static int mtk_mipi_tx_pll_enable(struct mtk_mipi_tx *mipi_tx)
> +{
> +	void __iomem *base = mipi_tx->regs;
> +	unsigned int txdiv, txdiv0;
> +	u64 pcw;
> +
> +	dev_dbg(mipi_tx->dev, "enable: %llu bps\n", mipi_tx->data_rate);
> +
> +	if (mipi_tx->data_rate >= 2000000000) {
> +		txdiv = 1;
> +		txdiv0 = 0;
> +	} else if (mipi_tx->data_rate >= 1000000000) {
> +		txdiv = 2;
> +		txdiv0 = 1;
> +	} else if (mipi_tx->data_rate >= 500000000) {
> +		txdiv = 4;
> +		txdiv0 = 2;
> +	} else if (mipi_tx->data_rate > 250000000) {
> +		txdiv = 8;
> +		txdiv0 = 3;
> +	} else if (mipi_tx->data_rate >= 125000000) {
> +		txdiv = 16;
> +		txdiv0 = 4;
> +	} else {
> +		return -EINVAL;
> +	}
> +
> +	mtk_phy_clear_bits(base + MIPITX_PLL_CON4, RG_DSI_PLL_IBIAS);
> +
> +	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);
> +	udelay(1);
> +	mtk_phy_clear_bits(base + MIPITX_PLL_PWR, AD_DSI_PLL_SDM_ISO_EN);
> +	pcw = div_u64(mipi_tx->data_rate * txdiv << 24, MIPITX_PLL_REF_RATE);

(mipi_tx->data_rate * txdiv) << 24

For those of us that can't remember order of operations.

> +	writel(pcw, base + MIPITX_PLL_CON0);
> +	mtk_phy_update_field(base + MIPITX_PLL_CON1, RG_DSI_PLL_POSDIV, txdiv0);
> +	mtk_phy_set_bits(base + MIPITX_PLL_CON1, RG_DSI_PLL_EN);
> +
> +	return 0;
> +}
> +

...

> +static void mtk_mipi_tx_power_on_signal(struct mtk_mipi_tx *mipi_tx)
> +{
> +	void __iomem *base = mipi_tx->regs;
> +
> +	/* BG_LPF_EN / BG_CORE_EN */
> +	writel(RG_DSI_PAD_TIEL_SEL | RG_DSI_BG_CORE_EN, base + MIPITX_LANE_CON);
> +	udelay(30);
> +	writel(RG_DSI_BG_CORE_EN | RG_DSI_BG_LPF_EN, base + MIPITX_LANE_CON);
> +
> +	/* Switch OFF each Lane */
> +	mtk_phy_clear_bits(base + MIPITX_D0_SW_CTL_EN, DSI_SW_CTL_EN);
> +	mtk_phy_clear_bits(base + MIPITX_D1_SW_CTL_EN, DSI_SW_CTL_EN);
> +	mtk_phy_clear_bits(base + MIPITX_D2_SW_CTL_EN, DSI_SW_CTL_EN);
> +	mtk_phy_clear_bits(base + MIPITX_D3_SW_CTL_EN, DSI_SW_CTL_EN);
> +	mtk_phy_clear_bits(base + MIPITX_CK_SW_CTL_EN, DSI_SW_CTL_EN);
> +
> +	mtk_phy_update_field(base + MIPITX_VOLTAGE_SEL, RG_DSI_HSTX_LDO_REF_SEL,
> +			     (mipi_tx->mipitx_drive - 3000) / 200);

Is this 3000 supposed to be MIPITX_DRIVE_MIN_UA?

> +
> +	mtk_mipi_tx_config_calibration_data(mipi_tx);
> +
> +	mtk_phy_set_bits(base + MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
> +}
> +

...

> +	/*
> +	 * The kernel reads the per-lane impedance trim codes from the
> +	 * "calibration-data" nvmem cell. No MediaTek board describes that cell

Technically, mipi_tx0: dsi-phy@11e50000 does in mt8183.dtsi

Not saying we need to implement it right now though. Just the comment isn't
100% accurate.

> +	 * in its device tree yet, so rt_code[] is left zeroed here and the
> +	 * SoC layer substitutes the same mid-scale default the kernel uses
> +	 * when the cell is absent.
> +	 */
> +
> +	return 0;
> +}
> +

  reply	other threads:[~2026-09-23 15:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 15:00 [PATCH 0/3] phy: mediatek: add MIPI DSI PHY driver Julien Stephan
2026-09-15 15:00 ` [PATCH 1/3] phy: sort vendor subdirectory lists alphabetically Julien Stephan
2026-09-15 15:00 ` [PATCH 2/3] phy: mediatek: move MediaTek PHY drivers to their own subdirectory Julien Stephan
2026-09-23 15:50   ` David Lechner
2026-09-15 15:00 ` [PATCH 3/3] phy: phy-mtk-mipi-dsi: add new driver Julien Stephan
2026-09-23 15:50   ` David Lechner [this message]
2026-09-29  8:55     ` Julien Stephan
2026-09-23 15:52 ` [PATCH 0/3] phy: mediatek: add MIPI DSI PHY driver David Lechner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eded0ea7-a3ee-4735-b520-c0e2beccdd63@baylibre.com \
    --to=dlechner@baylibre.com \
    --cc=GSS_MTK_Uboot_upstream@mediatek.com \
    --cc=chunfeng.yun@mediatek.com \
    --cc=igor.belwon@mentallysanemainliners.org \
    --cc=jstephan@baylibre.com \
    --cc=lucienzx159@gmail.com \
    --cc=mkorpershoek@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=pyadvychuk@baylibre.com \
    --cc=ryder.lee@mediatek.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.u-boot-project.org \
    --cc=weijie.gao@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox