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;
> +}
> +
next prev parent 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