* Re: [PATCH v2 4/4] arm64: dts: qcom: x1-dell-thena: bump linux,cma to 256 MiB
From: Bjorn Andersson @ 2026-07-11 18:24 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Michael Scott, linux-arm-msm, vkoul, neil.armstrong,
dmitry.baryshkov, wesley.cheng, abelvesa, faisal.hassan,
linux-phy, konradybcio, robh, krzk+dt, conor+dt, devicetree, val,
laurentiu.tudor1, alex.vinarskis, linux-kernel
In-Reply-To: <a03fa27c-57ad-48e3-9223-b4d30978ded5@linaro.org>
On Fri, May 22, 2026 at 10:33:45PM +0100, Bryan O'Donoghue wrote:
> On 22/05/2026 18:16, Michael Scott wrote:
> > > └─[$] <git:(0.7.0-multipass-v0*)>
> >
> > Good point about the libcamera version. I debugged this on Ubuntu 26.04
> > (v0.7.0+patches). I tried testing v0.7.1, but it caused a crash due to
> > API changes with other parts of the subsystem. I checked the diff of
> > upstream between v0.7.0 and v0.7.1 for the dma allocator code and I
> > didn't see any changes, but I wasn't looking at the software ISP
> > changes.
> >
> > This highlights that "I'm doing this wrong". I'll move to a cleaner
> > rolling distro where staying current is a lot easier.
> >
> > The GPUISP support looks great!
> >
> > Dropping this patch as I'm not understanding the full allocator story.
> > Sorry for the noise.
>
> The whole make CMA bigger thing is an error I was pushing myself.
>
> CMA is required for some systems like say Hantro on i.MX where - the encoder
> doesn't know how to deal with non PHYS contig memory so when you are passing
> framebuffers around from once hw block to another, you need to make them
> physically contiguous.
>
> Not a problem for us on Qcom hw though. Like Rob said, I'm actually not sure
> why we need a CMA block on Qcom hardware at all.
>
&pcie_smmu { status = "reserved" }; means that typical Makena and Hamoa
machines need CMA. Which should be unrelated...
Regards,
Bjorn
> GPU or WiFi I think but not for Camera anymore anyway.
>
> ---
> bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH 0/8] SM8450 QoL changes
From: Bjorn Andersson @ 2026-07-11 19:49 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rob Clark,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Vinod Koul,
Neil Armstrong, Esteban Urrutia
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-0-37e2ee8df9da@proton.me>
On Mon, 22 Jun 2026 20:54:21 -0400, Esteban Urrutia wrote:
> I've been mainlining an SM8475 based device for quite some time now and
> I feel now's the proper time to start submitting patches.
> I'm starting with the smallest part which are mostly modifications
> regarding the current support for the SM8450 SoC.
>
> Regards,
> Esteban
>
> [...]
Applied, thanks!
[4/8] arm64: dts: qcom: sm8450: Add missing PCM_OUT port
commit: 9c510bde799765bf1d28004b0e6555e05565f464
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v2 0/4] phy: qcom: qmp-combo fixes + x1-dell-thena DT maintenance
From: Bjorn Andersson @ 2026-07-11 19:49 UTC (permalink / raw)
To: linux-arm-msm, Michael Scott
Cc: vkoul, neil.armstrong, dmitry.baryshkov, wesley.cheng, abelvesa,
faisal.hassan, linux-phy, konradybcio, robh, krzk+dt, conor+dt,
devicetree, val, bryan.odonoghue, laurentiu.tudor1,
alex.vinarskis, linux-kernel
In-Reply-To: <20260521010935.1333494-1-mike.scott@oss.qualcomm.com>
On Wed, 20 May 2026 18:09:31 -0700, Michael Scott wrote:
> Four patches:
>
> * Two pre-existing bug fixes in phy-qcom-qmp-combo that are reachable
> today on any board which registers a usb_role_switch on this PHY,
> and will become reachable on more X1E boards as their Type-C
> support matures (patches 1-2).
>
> [...]
Applied, thanks!
[3/4] arm64: dts: qcom: x1-dell-thena: mark l12b and l15b always-on
commit: e505fc5f96661f3e3afa4267ac9415d8559cf2bd
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 4/7] phy: cpcap-usb: add DCP detection and make UART idle mode optional
From: sashiko-bot @ 2026-07-11 20:54 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: vkoul, robh, neil.armstrong, devicetree, linux-phy, conor+dt,
olteanv
In-Reply-To: <20260711204210.197144-5-ivo.g.dimitrov.75@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The new charger detection logic introduces an infinite connect/disconnect flapping loop for active USB peripheral connections and an infinite polling loop for proprietary chargers.
- [High] Transitioning from idle mode to USB mode leaves the PHY transceiver improperly suspended because CPCAP_BIT_USBSUSPEND is not cleared.
--
--- Patch [4]: [PATCH v5 4/7] phy: cpcap-usb: add DCP detection and make UART idle mode optional ---
commit a10ef479eac91f75ee1175abda606fb7eaa3fb70
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
phy: cpcap-usb: add DCP detection and make UART idle mode optional
Handle DCP separately from USB host connections using CPCAP charger
detection status. Make the existing idle UART mode optional via the
"enable_uart" module parameter. Initialize the PHY into the baseline
configuration required for reliable charger detection during probe.
> diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/phy-cpcap-usb.c
> index 741145c89e5bb..2d770ff19e934 100644
> --- a/drivers/phy/motorola/phy-cpcap-usb.c
> +++ b/drivers/phy/motorola/phy-cpcap-usb.c
[ ... ]
> @@ -292,38 +301,74 @@ static void cpcap_usb_detect(struct work_struct *work)
[ ... ]
> - /* Otherwise assume we're connected to a USB host */
> - if (vbus) {
> - dev_dbg(ddata->dev, "connected to USB host\n");
> - error = cpcap_usb_set_usb_mode(ddata);
> + /* Check if we're connected to a USB host or charger */
> + if (vbus && ddata->mode != CPCAP_USB_HOST) {
> + enum cpcap_mode new_mode;
> +
> + if (s.se1)
> + new_mode = CPCAP_CHARGER;
> + else if (!s.dm && !s.dp)
> + new_mode = CPCAP_USB;
> + else {
> + error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC2,
> + CPCAP_BIT_USBXCVREN |
> + CPCAP_BIT_UARTMUX0 |
> + CPCAP_BIT_EMUMODE0, 0);
> + if (error)
> + goto out_err;
> +
> + schedule_delayed_work(&ddata->detect_work,
> + msecs_to_jiffies(100));
> + return;
> + }
[Severity: High]
Does this else block create a regression with an infinite connect/disconnect
flapping loop for active USB peripheral connections?
When the device successfully enters CPCAP_USB mode, normal USB pull-ups or
traffic will assert D+ high (s.dp == 1). Any subsequent interrupt triggers
detect_work(), and if s.se1 is false, it falls into this else block. It then
disables the transceiver (USBXCVREN = 0) and reschedules itself in 100ms,
repeatedly dropping standard PC connections or proprietary chargers.
[ ... ]
> @@ -424,43 +469,84 @@ static int cpcap_usb_gpio_set_mode(struct cpcap_phy_ddata *ddata,
[ ... ]
> +static int cpcap_usb_set_idle_mode(struct cpcap_phy_ddata *ddata)
> +{
[ ... ]
> + val = CPCAP_BIT_USBSUSPEND;
> +
> + if (enable_uart)
> + val |= (CPCAP_BIT_UARTMUX0 | CPCAP_BIT_EMUMODE0);
> +
> + error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC2, 0xffff, val);
> + if (error)
> + goto out_err;
[ ... ]
> @@ -503,11 +578,23 @@ static int cpcap_usb_set_usb_mode(struct cpcap_phy_ddata *ddata)
> goto out_err;
>
> error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC2,
> - CPCAP_BIT_USBXCVREN,
> + CPCAP_BIT_USBXCVREN |
> + CPCAP_BIT_UARTMUX0 |
> + CPCAP_BIT_EMUMODE0,
> CPCAP_BIT_USBXCVREN);
[Severity: High]
When transitioning back to USB mode, does this cause a regression where the
PHY transceiver is left improperly suspended?
In cpcap_usb_set_idle_mode(), CPCAP_REG_USBC2 is updated with a 0xffff mask to
explicitly set CPCAP_BIT_USBSUSPEND. When returning to USB mode here, the mask
is limited to CPCAP_BIT_USBXCVREN | CPCAP_BIT_UARTMUX0 | CPCAP_BIT_EMUMODE0.
Since this mask does not include CPCAP_BIT_USBSUSPEND, it looks like it fails
to clear the suspension state, which could cause communication failures.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711204210.197144-1-ivo.g.dimitrov.75@gmail.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 1/2] phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs
From: Esteban Urrutia via B4 Relay @ 2026-07-12 3:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Dmitry Baryshkov, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, phone-devel,
Esteban Urrutia
In-Reply-To: <20260711-sm8450-qol-qmp-v2-0-d14353bd6ff4@proton.me>
From: Esteban Urrutia <esteuwu@proton.me>
Comparing sm8350 and sm8450 tables, this seems to be a typo.
Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support")
Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index cdcfad2e86b1..a72c3b9654ec 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -2108,7 +2108,7 @@ static const u8 qmp_dp_v4_pre_emphasis_hbr3_hbr2[4][4] = {
static const u8 qmp_dp_v4_pre_emphasis_hbr_rbr[4][4] = {
{ 0x00, 0x0d, 0x14, 0x1a },
{ 0x00, 0x0e, 0x15, 0xff },
- { 0x00, 0x0d, 0xff, 0xff },
+ { 0x00, 0x0e, 0xff, 0xff },
{ 0x03, 0xff, 0xff, 0xff }
};
--
2.55.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/2] SM8450 QoL changes (qmp)
From: Esteban Urrutia via B4 Relay @ 2026-07-12 3:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Dmitry Baryshkov, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, phone-devel,
Esteban Urrutia, Dmitry Baryshkov
These two patches drop qmp_v4_calibrate_dp_phy() and modify a pre-emphasis
table for v4 DP PHYs to match downstream behavior.
Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
Changes in v2:
- Split series in subseries (dispcc, dts, qmp, smmu)
- Link to v1: https://patch.msgid.link/20260622-sm8450-qol-v1-0-37e2ee8df9da@proton.me
---
Esteban Urrutia (2):
phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs
phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 33 +------------------------------
1 file changed, 1 insertion(+), 32 deletions(-)
---
base-commit: 96615101b3caf73612f80a217abb9a0da0effbc7
change-id: 20260711-sm8450-qol-qmp-53fbec9b92e8
Best regards,
--
Esteban Urrutia <esteuwu@proton.me>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 2/2] phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy
From: Esteban Urrutia via B4 Relay @ 2026-07-12 3:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Dmitry Baryshkov, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, phone-devel,
Esteban Urrutia, Dmitry Baryshkov
In-Reply-To: <20260711-sm8450-qol-qmp-v2-0-d14353bd6ff4@proton.me>
From: Esteban Urrutia <esteuwu@proton.me>
There are no downstream device trees that specify five values in the
qcom,aux-cfg1-settings array.
Plus, after cross referencing both downstream device trees and entries
which refer this function, only 0x13 is specified.
Since 0x13 is written at initialization time, drop this function as a
whole, and remove now unused variable assignations.
Fixes: aff188feb5e1 ("phy: qcom-qmp: add support for sm8250-usb3-dp phy")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 31 -------------------------------
1 file changed, 31 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index a72c3b9654ec..5b278fd54a16 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -2325,7 +2325,6 @@ static int qmp_v3_calibrate_dp_phy(struct qmp_combo *qmp);
static void qmp_v4_dp_aux_init(struct qmp_combo *qmp);
static void qmp_v4_configure_dp_tx(struct qmp_combo *qmp);
static int qmp_v4_configure_dp_phy(struct qmp_combo *qmp);
-static int qmp_v4_calibrate_dp_phy(struct qmp_combo *qmp);
static void qmp_v8_dp_aux_init(struct qmp_combo *qmp);
static int qmp_v8_configure_dp_clocks(struct qmp_combo *qmp);
@@ -2466,7 +2465,6 @@ static const struct qmp_phy_cfg sar2130p_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.regs = qmp_v6_usb3phy_regs_layout,
.reset_list = msm8996_usb3phy_reset_l,
@@ -2603,7 +2601,6 @@ static const struct qmp_phy_cfg sc8180x_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
@@ -2650,7 +2647,6 @@ static const struct qmp_phy_cfg sc8280xp_usb43dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
@@ -2696,7 +2692,6 @@ static const struct qmp_phy_cfg x1e80100_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
@@ -2785,7 +2780,6 @@ static const struct qmp_phy_cfg sm8250_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
@@ -2834,7 +2828,6 @@ static const struct qmp_phy_cfg sm8350_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
@@ -2882,7 +2875,6 @@ static const struct qmp_phy_cfg sm8550_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.regs = qmp_v6_usb3phy_regs_layout,
.reset_list = msm8996_usb3phy_reset_l,
@@ -2928,7 +2920,6 @@ static const struct qmp_phy_cfg sm8650_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.regs = qmp_v6_usb3phy_regs_layout,
.reset_list = msm8996_usb3phy_reset_l,
@@ -2974,7 +2965,6 @@ static const struct qmp_phy_cfg sm8750_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v3_configure_dp_clocks,
.configure_dp_phy = qmp_v4_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.regs = qmp_v8_usb3phy_regs_layout,
.reset_list = msm8996_usb3phy_reset_l,
@@ -3020,7 +3010,6 @@ static const struct qmp_phy_cfg glymur_usb3dpphy_cfg = {
.configure_dp_tx = qmp_v4_configure_dp_tx,
.configure_dp_clocks = qmp_v8_configure_dp_clocks,
.configure_dp_phy = qmp_v8_configure_dp_phy,
- .calibrate_dp_phy = qmp_v4_calibrate_dp_phy,
.regs = qmp_v8_n3_usb43dpphy_regs_layout,
.reset_list = msm8996_usb3phy_reset_l,
@@ -3316,7 +3305,6 @@ static void qmp_v4_dp_aux_init(struct qmp_combo *qmp)
writel(0x03, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG7);
writel(0xb7, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG8);
writel(0x03, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG9);
- qmp->dp_aux_cfg = 0;
writel(PHY_AUX_STOP_ERR_MASK | PHY_AUX_DEC_ERR_MASK |
PHY_AUX_SYNC_ERR_MASK | PHY_AUX_ALIGN_ERR_MASK |
@@ -3345,7 +3333,6 @@ static void qmp_v8_dp_aux_init(struct qmp_combo *qmp)
writel(0x03, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG7);
writel(0xb7, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG8);
writel(0x03, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG9);
- qmp->dp_aux_cfg = 0;
writel(PHY_AUX_STOP_ERR_MASK | PHY_AUX_DEC_ERR_MASK |
PHY_AUX_SYNC_ERR_MASK | PHY_AUX_ALIGN_ERR_MASK |
@@ -3605,24 +3592,6 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
return 0;
}
-/*
- * We need to calibrate the aux setting here as many times
- * as the caller tries
- */
-static int qmp_v4_calibrate_dp_phy(struct qmp_combo *qmp)
-{
- static const u8 cfg1_settings[] = { 0x20, 0x13, 0x23, 0x1d };
- u8 val;
-
- qmp->dp_aux_cfg++;
- qmp->dp_aux_cfg %= ARRAY_SIZE(cfg1_settings);
- val = cfg1_settings[qmp->dp_aux_cfg];
-
- writel(val, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG1);
-
- return 0;
-}
-
static int qmp_combo_dp_configure(struct phy *phy, union phy_configure_opts *opts)
{
const struct phy_configure_opts_dp *dp_opts = &opts->dp;
--
2.55.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v5 2/4] dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
From: Krzysztof Kozlowski @ 2026-07-12 12:21 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <20260711-shikra-usbphy-v5-v5-2-229ba3602737@oss.qualcomm.com>
On Sat, Jul 11, 2026 at 10:39:51PM +0530, Krishna Kurapati wrote:
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,shikra-qmp-usb3-dp-phy
> + then:
> + properties:
> + resets:
> + minItems: 3
> + reset-names:
Same feedback. minItems
> + items:
> + - const: phy_phy
> + - const: dp_phy
> + - const: phy
Drop
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,qcs615-qmp-usb3-dp-phy
> + then:
> + properties:
> + resets:
> + maxItems: 2
> + reset-names:
same feedback, maxItems.
> + items:
> + - const: phy_phy
> + - const: dp_phy
Drop
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 02/10] m68k/coldfire: replace linux/gpio.h inclusions
From: Greg Ungerer @ 2026-07-12 12:27 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio, Linus Walleij, Bartosz Golaszewski
Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
Thomas Bogendoerfer, Hauke Mehrtens, Rafał Miłecki,
Yoshinori Sato, John Paul Adrian Glaubitz, Dmitry Torokhov,
Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-sunxi, linux-phy, linux-rockchip, linux-sound,
Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-3-arnd@kernel.org>
Hi Arnd,
On 11/7/26 07:19, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for coldfire.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I have applied this one to the for-next branch of the m68knommu git tree.
Thanks
Greg
> ---
> arch/m68k/coldfire/device.c | 2 +-
> arch/m68k/include/asm/mcfgpio.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
> index 1420bae0964f..9a0258acd998 100644
> --- a/arch/m68k/coldfire/device.c
> +++ b/arch/m68k/coldfire/device.c
> @@ -12,7 +12,7 @@
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/spi/spi.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
> #include <linux/fec.h>
> #include <linux/dmaengine.h>
> #include <asm/traps.h>
> diff --git a/arch/m68k/include/asm/mcfgpio.h b/arch/m68k/include/asm/mcfgpio.h
> index 7103cfa4edb6..29726aa40eb6 100644
> --- a/arch/m68k/include/asm/mcfgpio.h
> +++ b/arch/m68k/include/asm/mcfgpio.h
> @@ -16,7 +16,7 @@ int __mcfgpio_request(unsigned gpio);
> void __mcfgpio_free(unsigned gpio);
>
> #ifdef CONFIG_GPIOLIB
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
> #else
>
> /* our alternate 'gpiolib' functions */
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: mediatek,dsi-phy: Add support for MT8196
From: Krzysztof Kozlowski @ 2026-07-12 15:22 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: chunfeng.yun, vkoul, neil.armstrong, robh, krzk+dt, conor+dt,
chunkuang.hu, p.zabel, matthias.bgg, justin.yeh, linux-arm-kernel,
linux-mediatek, linux-phy, devicetree, linux-kernel, dri-devel,
kernel
In-Reply-To: <20260701121943.19430-2-angelogioacchino.delregno@collabora.com>
On Wed, Jul 01, 2026 at 02:19:42PM +0200, AngeloGioacchino Del Regno wrote:
> Add support for the MediaTek Kompanio Ultra (MT8196) SoC: this
> chip features a DSI PHY that is similar to the one found in the
> MT8183 SoC, but is a new (incremental) revision with a different
> register layout.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v6 0/4] Add USB Phy driver and binding changes for Qualcomm Shikra SoC
From: Krishna Kurapati @ 2026-07-12 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Krzysztof Kozlowski, Dmitry Baryshkov
This series adds Driver and binding changes for USB Phys on Shikra.
There are two USB controllers - One of them is SS capable and other is
highspeed only capable.
Changes in v6:
- Fix the minItems and maxItems for reset-names in qmp phy yaml
Link to v5:
https://lore.kernel.org/all/20260711-shikra-usbphy-v5-v5-0-229ba3602737@oss.qualcomm.com/
Changes in v5:
- Fixed shikra specific minItems property for qmp bindings
- Rebased qusb2 driver changes on top of Dmitry's change [1]
Link to v4:
https://lore.kernel.org/all/20260701165051.4122259-1-krishna.kurapati@oss.qualcomm.com/
Changes in v4:
- Moved to using qcs615-usb3-dp-phy and added resets specific to shikra
- Updated bindings to reflect that there are 3 resets used in qmp phy
- Add remote endpoints and orientation-switch for Type-c handling
Link to v3:
https://lore.kernel.org/all/20260526184401.3959717-1-pratham.pratap@oss.qualcomm.com/
Changes in v3:
- Moved to using qcs615-usb3-dp-phy since the DP Phy is present although
not operational.
- Using Talos as a fallback for shikra in qmp driver
- Add required "phy" reset in qmp usbc driver since its needed on Shikra
Link to v2:
https://lore.kernel.org/all/20260504170659.282532-1-krishna.kurapati@oss.qualcomm.com/
Changes in v2:
- Separated the usb controller binding changes
- Updated commit texts.
Link to v1:
https://lore.kernel.org/all/20260430-shikra-usb-v1-0-c9c108536fdc@oss.qualcomm.com/
[1]: https://lore.kernel.org/all/20260706-fix-qusb2-v2-0-8d9cd73b1db7@oss.qualcomm.com/
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
Krishna Kurapati (4):
dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
phy: qcom-qusb2: Add support for Shikra
phy: qcom: qmp-usbc: Add qmp configuration for Shikra
.../bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml | 49 +++++++++++++++++++-
.../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 53 ++++++++++++++++++++--
drivers/phy/qualcomm/phy-qcom-qusb2.c | 14 ++++++
4 files changed, 113 insertions(+), 4 deletions(-)
---
base-commit: 716471df03105a6abdf02727f8a6f096b70aaf98
change-id: 20260712-usb-shikra-phy-v6-2c581e79656d
Best regards,
--
Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v6 1/4] dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
From: Krishna Kurapati @ 2026-07-12 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Krzysztof Kozlowski
In-Reply-To: <20260712-usb-shikra-phy-v6-v6-0-1b3e51bf1541@oss.qualcomm.com>
Update dt-bindings to add Shikra to QUSB2 Phy list. Shikra SoC
has two High Speed QUSB2 Phys.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 449c2a7e5fec..001fd0ccc985 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -28,6 +28,7 @@ properties:
- qcom,qcm2290-qusb2-phy
- qcom,qcs615-qusb2-phy
- qcom,sdm660-qusb2-phy
+ - qcom,shikra-qusb2-phy
- qcom,sm4250-qusb2-phy
- qcom,sm6115-qusb2-phy
- items:
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 2/4] dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
From: Krishna Kurapati @ 2026-07-12 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260712-usb-shikra-phy-v6-v6-0-1b3e51bf1541@oss.qualcomm.com>
Declare the USB-C QMP PHY present on the Qualcomm Shikra SoC. Shikra uses
3 resets to be programmed before initialising the phy. As per the hardware
documentation, the third reset is PHY_PRIM_SP0_BCR, hence naming it "phy".
Also, add remote endpoints and orientation switch support for getting
Type-C orientation information.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
.../bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml | 49 +++++++++++++++++++++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
index efb465c71c1b..98397006fa62 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- qcom,qcs615-qmp-usb3-dp-phy
+ - qcom,shikra-qmp-usb3-dp-phy
reg:
maxItems: 1
@@ -33,12 +34,15 @@ properties:
- const: pipe
resets:
- maxItems: 2
+ minItems: 2
+ maxItems: 3
reset-names:
+ minItems: 2
items:
- const: phy_phy
- const: dp_phy
+ - const: phy
vdda-phy-supply: true
@@ -63,6 +67,22 @@ properties:
- description: offset of the PHY mode register
description: Clamp and PHY mode register present in the TCSR
+ orientation-switch:
+ description:
+ Flag the PHY as possible handler of USB Type-C orientation switching
+ type: boolean
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output endpoint of the PHY
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
required:
- compatible
- reg
@@ -78,6 +98,33 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,shikra-qmp-usb3-dp-phy
+ then:
+ properties:
+ resets:
+ minItems: 3
+ reset-names:
+ minItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs615-qmp-usb3-dp-phy
+ then:
+ properties:
+ resets:
+ maxItems: 2
+ reset-names:
+ maxItems: 2
+
examples:
- |
#include <dt-bindings/clock/qcom,qcs615-gcc.h>
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 3/4] phy: qcom-qusb2: Add support for Shikra
From: Krishna Kurapati @ 2026-07-12 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Dmitry Baryshkov
In-Reply-To: <20260712-usb-shikra-phy-v6-v6-0-1b3e51bf1541@oss.qualcomm.com>
Add init sequence and phy configuration for Shikra. Since the init
sequence is same as that of QCS615, reuse the existing init table in
Shikra.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index b22b3c6adfd3..101c0820023d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -377,6 +377,17 @@ static const struct qusb2_phy_cfg sdm660_phy_cfg = {
.mask_core_ready = PLL_LOCKED,
};
+static const struct qusb2_phy_cfg shikra_phy_cfg = {
+ .tbl = qcs615_init_tbl,
+ .tbl_num = ARRAY_SIZE(qcs615_init_tbl),
+ .regs = msm8996_regs_layout,
+
+ .has_pll_test = true,
+ .se_clk_scheme_default = true,
+ .disable_ctrl = CLAMP_N_EN | FREEZIO_N | POWER_DOWN,
+ .mask_core_ready = PLL_LOCKED,
+};
+
static const struct qusb2_phy_cfg sm6115_phy_cfg = {
.tbl = sm6115_init_tbl,
.tbl_num = ARRAY_SIZE(sm6115_init_tbl),
@@ -953,6 +964,9 @@ static const struct of_device_id qusb2_phy_of_match_table[] = {
}, {
.compatible = "qcom,sdm660-qusb2-phy",
.data = &sdm660_phy_cfg,
+ }, {
+ .compatible = "qcom,shikra-qusb2-phy",
+ .data = &shikra_phy_cfg,
}, {
.compatible = "qcom,sm4250-qusb2-phy",
.data = &sm6115_phy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 4/4] phy: qcom: qmp-usbc: Add qmp configuration for Shikra
From: Krishna Kurapati @ 2026-07-12 15:28 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Dmitry Baryshkov
In-Reply-To: <20260712-usb-shikra-phy-v6-v6-0-1b3e51bf1541@oss.qualcomm.com>
Add init sequence and phy configuration for the Super Speed port on Shikra
SoC. Also since Shikra uses 3 resets, add support for the third reset and
configure Shikra platform data to use 3 resets.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 53 ++++++++++++++++++++++++++++++--
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
index ab3055bb5b0c..fa8492b487d7 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
@@ -512,10 +512,14 @@ static const char * const usb3phy_reset_l[] = {
"phy_phy", "phy",
};
-static const char * const usb3dpphy_reset_l[] = {
+static const char * const qcs615_usb3dpphy_reset_l[] = {
"phy_phy", "dp_phy",
};
+static const char * const shikra_usb3dpphy_reset_l[] = {
+ "phy_phy", "dp_phy", "phy",
+};
+
static const struct regulator_bulk_data qmp_phy_msm8998_vreg_l[] = {
{ .supply = "vdda-phy", .init_load_uA = 68600 },
{ .supply = "vdda-pll", .init_load_uA = 14200 },
@@ -680,8 +684,48 @@ static const struct qmp_phy_cfg qcs615_usb3dp_phy_cfg = {
.configure_dp_phy = qcs615_qmp_configure_dp_phy,
.calibrate_dp_phy = qcs615_qmp_calibrate_dp_phy,
- .reset_list = usb3dpphy_reset_l,
- .num_resets = ARRAY_SIZE(usb3dpphy_reset_l),
+ .reset_list = qcs615_usb3dpphy_reset_l,
+ .num_resets = ARRAY_SIZE(qcs615_usb3dpphy_reset_l),
+ .vreg_list = qmp_phy_qcs615_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_qcs615_vreg_l),
+};
+
+static const struct qmp_phy_cfg shikra_usb3dp_phy_cfg = {
+ .offsets = &qmp_usbc_usb3dp_offsets_qcs615,
+
+ .serdes_tbl = qcm2290_usb3_serdes_tbl,
+ .serdes_tbl_num = ARRAY_SIZE(qcm2290_usb3_serdes_tbl),
+ .tx_tbl = qcm2290_usb3_tx_tbl,
+ .tx_tbl_num = ARRAY_SIZE(qcm2290_usb3_tx_tbl),
+ .rx_tbl = qcm2290_usb3_rx_tbl,
+ .rx_tbl_num = ARRAY_SIZE(qcm2290_usb3_rx_tbl),
+ .pcs_tbl = qcm2290_usb3_pcs_tbl,
+ .pcs_tbl_num = ARRAY_SIZE(qcm2290_usb3_pcs_tbl),
+
+ .regs = qmp_v3_usb3phy_regs_layout_qcm2290,
+
+ .dp_serdes_tbl = qcs615_dp_serdes_tbl,
+ .dp_serdes_tbl_num = ARRAY_SIZE(qcs615_dp_serdes_tbl),
+ .dp_tx_tbl = qcs615_dp_tx_tbl,
+ .dp_tx_tbl_num = ARRAY_SIZE(qcs615_dp_tx_tbl),
+
+ .serdes_tbl_rbr = qcs615_dp_serdes_tbl_rbr,
+ .serdes_tbl_rbr_num = ARRAY_SIZE(qcs615_dp_serdes_tbl_rbr),
+ .serdes_tbl_hbr = qcs615_dp_serdes_tbl_hbr,
+ .serdes_tbl_hbr_num = ARRAY_SIZE(qcs615_dp_serdes_tbl_hbr),
+ .serdes_tbl_hbr2 = qcs615_dp_serdes_tbl_hbr2,
+ .serdes_tbl_hbr2_num = ARRAY_SIZE(qcs615_dp_serdes_tbl_hbr2),
+
+ .swing_tbl = &qcs615_dp_voltage_swing_hbr2_rbr,
+ .pre_emphasis_tbl = &qcs615_dp_pre_emphasis_hbr2_rbr,
+
+ .dp_aux_init = qcs615_qmp_dp_aux_init,
+ .configure_dp_tx = qcs615_qmp_configure_dp_tx,
+ .configure_dp_phy = qcs615_qmp_configure_dp_phy,
+ .calibrate_dp_phy = qcs615_qmp_calibrate_dp_phy,
+
+ .reset_list = shikra_usb3dpphy_reset_l,
+ .num_resets = ARRAY_SIZE(shikra_usb3dpphy_reset_l),
.vreg_list = qmp_phy_qcs615_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_qcs615_vreg_l),
};
@@ -2019,6 +2063,9 @@ static const struct of_device_id qmp_usbc_of_match_table[] = {
}, {
.compatible = "qcom,sdm660-qmp-usb3-phy",
.data = &sdm660_usb3phy_cfg,
+ }, {
+ .compatible = "qcom,shikra-qmp-usb3-dp-phy",
+ .data = &shikra_usb3dp_phy_cfg,
}, {
.compatible = "qcom,sm6115-qmp-usb3-phy",
.data = &qcm2290_usb3phy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v9 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-07-12 23:18 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <b834e9a0-a61c-4912-b57c-36d571938b75@linaro.org>
On 09/07/2026 08:40, Vladimir Zapolskiy wrote:
>> As explained in the cover letter: I'm following guidance from Rob on that.
> Pehaps you've misread a given review comment, because Rob's guidance is
> to remove 'phy-type' property,
I'll just quote verbatim "Perhaps putting this in phy cells would be
better because the consumer decides on the mode."
That is not "remove phy-type" - it's "move the mode into the cell". I'm
shifting this back to the DT schema maintainers since, I take their
feedback literally, seriously and canonically.
Any of the triumvirate will do, Rob, Krzysztof or Conor.
Absent a different answer from the DT schema guys, v10 ships with the
consumer deciding the mode as per Rob's original guidance.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/4] PCI: qcom: Add link retention support
From: Manivannan Sadhasivam @ 2026-07-13 4:50 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Qiang Yu
In-Reply-To: <20260709-link_retain-v3-3-81a9d187bb61@oss.qualcomm.com>
On Thu, Jul 09, 2026 at 12:05:18PM +0530, Krishna Chaitanya Chundru wrote:
> Some platforms keep the PCIe link active across bootloader and kernel
> handoff. Reinitializing the controller and toggling PERST# in such cases is
> unnecessary when the driver does not need to retrain the link.
>
> Introduce link_retain in both qcom_pcie_cfg and qcom_pcie to indicate when
> link retention is supported. During initialization, check the LTSSM state;
> if the link is already in L0 or L1 idle and LTSSM is enabled, set
> link_retain and skip controller reset, PERST# toggling, and other post-
> init steps.
>
> The max-link-speed and num-lanes properties in Device Tree cap the link's
> maximum capability. Retrain the link if the controller's max link speed or
> width exceeds the Device Tree cap, unless the currently negotiated speed
> or width is already within that cap, in which case the existing link can
> still be retained.
>
> Configure the DBI and ATU base addresses in the retention path, since the
> bootloader may use different base addresses than those provided by the
> device tree.
>
Where is this base address change?
> Set l1ss_support in the retention path as well, since it is otherwise only
> set later in the normal init flow which is skipped when the link is
> retained.
>
> Tested-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
> drivers/pci/controller/dwc/pcie-qcom.c | 68 ++++++++++++++++++++++++++--
> 2 files changed, 66 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index de4b245b1758..0c98b914eb52 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -471,6 +471,7 @@ struct dw_pcie_rp {
> bool native_ecam;
> bool skip_l23_ready;
> bool skip_pwrctrl_off;
> + bool link_retain;
> };
>
> struct dw_pcie_ep_ops {
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 9ca620d4746a..77d2d989e9da 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -260,12 +260,14 @@ struct qcom_pcie_ops {
> * @override_no_snoop: Override NO_SNOOP attribute in TLP to enable cache
> * snooping
> * @firmware_managed: Set if the Root Complex is firmware managed
> + * @link_retain: Set if controller supports retaining link from bootloader
> */
> struct qcom_pcie_cfg {
> const struct qcom_pcie_ops *ops;
> bool override_no_snoop;
> bool firmware_managed;
> bool no_l0s;
> + bool link_retain;
> };
>
> struct qcom_pcie_perst {
> @@ -996,6 +998,50 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie)
> return 0;
> }
>
> +/*
> + * Determine whether the link established by the bootloader can be reused.
> + *
> + * The max-link-speed and num-lanes specified in Device Tree are meant to cap
> + * the link's maximum capability. Retrain the link if the controller's max
> + * link speed/width exceeds the Device Tree cap, unless the currently
> + * negotiated speed/width is already within that cap, in which case the
> + * existing link can be retained as-is.
> + */
> +static bool qcom_pcie_check_link_retain(struct qcom_pcie *pcie)
> +{
> + u32 cap, speed, cur_speed, val, ltssm, width, cur_width;
> + struct dw_pcie *pci = pcie->pci;
> + u8 offset;
> +
> + val = readl(pcie->parf + PARF_LTSSM);
> + ltssm = val & 0x1f;
> + if ((val & LTSSM_EN) &&
> + (ltssm == DW_PCIE_LTSSM_L0 || ltssm == DW_PCIE_LTSSM_L1_IDLE)) {
> + qcom_pcie_configure_dbi_atu_base(pcie);
> +
> + offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> + cap = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCAP);
> + speed = FIELD_GET(PCI_EXP_LNKCAP_SLS, cap);
> + width = dw_pcie_link_get_max_link_width(pci);
> +
> + val = dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKSTA);
> + cur_speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, val);
> + cur_width = FIELD_GET(PCI_EXP_LNKSTA_NLW, val);
> +
> + if (pci->max_link_speed > 0 && speed > pci->max_link_speed &&
> + cur_speed > pci->max_link_speed)
> + return false;
> +
> + if (pci->num_lanes > 0 && width > pci->num_lanes &&
> + cur_width > pci->num_lanes)
> + return false;
> +
> + return true;
> + }
> +
> + return false;
> +}
> +
> static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie)
> {
> struct qcom_pcie_resources_2_7_0 *res = &pcie->res.v2_7_0;
> @@ -1014,6 +1060,15 @@ static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie)
> if (ret < 0)
> goto err_disable_regulators;
>
> + if (pcie->cfg->link_retain) {
> + pci->pp.link_retain = qcom_pcie_check_link_retain(pcie);
> + pci->l1ss_support = true;
> + if (pci->pp.link_retain) {
> + dev_info(dev, "Retaining PCIe link\n");
> + return 0;
> + }
> + }
> +
> ret = reset_control_assert(res->rst);
> if (ret) {
> dev_err(dev, "reset assert failed (%d)\n", ret);
> @@ -1074,6 +1129,9 @@ static int qcom_pcie_post_init_2_7_0(struct qcom_pcie *pcie)
> {
> const struct qcom_pcie_cfg *pcie_cfg = pcie->cfg;
>
> + if (pcie->pci->pp.link_retain)
> + return 0;
> +
> if (pcie_cfg->override_no_snoop)
> writel(WR_NO_SNOOP_OVERRIDE_EN | RD_NO_SNOOP_OVERRIDE_EN,
> pcie->parf + PARF_NO_SNOOP_OVERRIDE);
> @@ -1364,12 +1422,13 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
> struct qcom_pcie *pcie = to_qcom_pcie(pci);
> int ret;
>
> - qcom_pcie_perst_assert(pcie);
> -
This is problematic. Most of the init callbacks do operations like reset the
PHY, enable clocks... If those operations affect the link state and the device
is not reset using PERST#, it will cause the device to crash.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 0/2] PHY: Add support for MT8196 DSI PHY
From: AngeloGioacchino Del Regno @ 2026-07-13 10:23 UTC (permalink / raw)
To: chunfeng.yun
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, chunkuang.hu,
p.zabel, matthias.bgg, angelogioacchino.delregno, justin.yeh,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel, dri-devel, kernel
Changes in v2:
- Added a few comments and fix scheduling while atomic issue in clk
enable ops by waiting with udelay() instead
- Removed one unnecessary delay after clk/pwr isolation disablement
This series adds support for the DSI PHY found in the newer MediaTek
Dimensity 9400 (MT6991), Genio Pro 5100 (MT8894) and Kompanio Ultra
(MT8196) SoCs.
AngeloGioacchino Del Regno (2):
dt-bindings: phy: mediatek,dsi-phy: Add support for MT8196
phy: mediatek: Add support for MT8196 MIPI DSI PHY
.../bindings/phy/mediatek,dsi-phy.yaml | 1 +
drivers/phy/mediatek/Makefile | 1 +
.../phy/mediatek/phy-mtk-mipi-dsi-mt8196.c | 196 ++++++++++++++++++
drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 1 +
drivers/phy/mediatek/phy-mtk-mipi-dsi.h | 2 +-
5 files changed, 200 insertions(+), 1 deletion(-)
create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: phy: mediatek,dsi-phy: Add support for MT8196
From: AngeloGioacchino Del Regno @ 2026-07-13 10:23 UTC (permalink / raw)
To: chunfeng.yun
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, chunkuang.hu,
p.zabel, matthias.bgg, angelogioacchino.delregno, justin.yeh,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel, dri-devel, kernel, Krzysztof Kozlowski
In-Reply-To: <20260713102322.21782-1-angelogioacchino.delregno@collabora.com>
Add support for the MediaTek Kompanio Ultra (MT8196) SoC: this
chip features a DSI PHY that is similar to the one found in the
MT8183 SoC, but is a new (incremental) revision with a different
register layout.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
index c6d0bbdbe0e2..9df1dbe1253b 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -39,6 +39,7 @@ properties:
- const: mediatek,mt2701-mipi-tx
- const: mediatek,mt8173-mipi-tx
- const: mediatek,mt8183-mipi-tx
+ - const: mediatek,mt8196-mipi-tx
reg:
maxItems: 1
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY
From: AngeloGioacchino Del Regno @ 2026-07-13 10:23 UTC (permalink / raw)
To: chunfeng.yun
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, chunkuang.hu,
p.zabel, matthias.bgg, angelogioacchino.delregno, justin.yeh,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel, dri-devel, kernel
In-Reply-To: <20260713102322.21782-1-angelogioacchino.delregno@collabora.com>
Add support for the MIPI DSI PHY found in the MediaTek MT8196 SoC
and its variants.
This PHY has a different register layout and provides support for
more hardware features compared to the previous generation.
This initial driver only adds support for basic functionality that
is necessary to drive MIPI DSI displays as a D-PHY.
Feature additions like lane-swap, DPHY/CPHY switching, dual-port,
and others, may be done in the future.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/phy/mediatek/Makefile | 1 +
.../phy/mediatek/phy-mtk-mipi-dsi-mt8196.c | 196 ++++++++++++++++++
drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 1 +
drivers/phy/mediatek/phy-mtk-mipi-dsi.h | 2 +-
4 files changed, 199 insertions(+), 1 deletion(-)
create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 1b8088df71e8..ed0da708759b 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_PHY_MTK_MIPI_CSI_0_5) += phy-mtk-mipi-csi-0-5.o
phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o
phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o
+phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8196.o
obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
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 000000000000..273f236fa7e9
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: jitao.shi <jitao.shi@mediatek.com>
+ *
+ * Copyright (c) 2026 Collabora Ltd.
+ * AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ */
+
+#include "phy-mtk-io.h"
+#include "phy-mtk-mipi-dsi.h"
+
+#define MIPITX_LANE_CON 0x0004
+#define RG_DSI_CPHY_T1DRV_EN BIT(0)
+#define RG_DSI_ANA_CK_SEL BIT(1)
+#define RG_DSI_PHY_CK_SEL BIT(2)
+#define RG_DSI_CPHY_EN BIT(3)
+#define RG_DSI_PHYCK_INV_EN BIT(4)
+#define RG_DSI_PWR04_EN BIT(5)
+#define RG_DSI_BG_LPF_EN BIT(6)
+#define RG_DSI_BG_CORE_EN BIT(7)
+#define RG_DSI_PAD_TIEL_SEL BIT(8)
+
+#define MIPITX_VOLTAGE_SEL 0x0008
+#define RG_DSI_HSTX_LDO_REF_SEL GENMASK(9, 6)
+#define RG_DSI_PRD_REF_SEL GENMASK(5, 0)
+#define RG_DSI_PRD_REF_MINI 0
+#define RG_DSI_PRD_REF_DEF 4
+#define RG_DSI_PRD_REF_MAX 7
+
+#define MIPITX_PRESERVED 0x000c
+#define MIPITX_PRESERVED_DEF 0xffff0040
+#define MIPITX_PRESERVED_MINI 0xffff00f0
+
+#define MIPITX_PLL_PWR 0x0028
+#define AD_DSI_PLL_SDM_PWR_ON BIT(0)
+#define AD_DSI_PLL_SDM_ISO_EN BIT(1)
+#define MIPITX_PLL_CON0 0x002c
+#define MIPITX_PLL_CON1 0x0030
+#define RG_DSI_PLL_EN BIT(0)
+#define RG_DSI_PLL_POSDIV GENMASK(10, 8)
+#define MIPITX_PLL_CON2 0x0034
+#define MIPITX_PLL_CON3 0x0038
+#define MIPITX_PLL_CON4 0x003c
+#define RG_DSI_PLL_IBIAS GENMASK(11, 10)
+
+#define MIPITX_D2_SW_CTL_EN 0x015c
+#define MIPITX_D0_SW_CTL_EN 0x025c
+#define MIPITX_CK_CKMODE_EN 0x0320
+#define DSI_CK_CKMODE_EN BIT(0)
+#define MIPITX_CK_SW_CTL_EN 0x035c
+#define MIPITX_D1_SW_CTL_EN 0x045c
+#define MIPITX_D3_SW_CTL_EN 0x055c
+#define DSI_SW_CTL_EN BIT(0)
+
+#define DSI_PHY_XTAL_CLK_HZ 26000000
+
+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 */
+ voltage = RG_DSI_PRD_REF_DEF;
+ pres = MIPITX_PRESERVED_DEF;
+ 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;
+ }
+
+ pcw_calc = ((u64)(mipi_tx->data_rate / 2) * txdiv) << 24;
+ pcw_calc = div_u64(pcw_calc, DSI_PHY_XTAL_CLK_HZ);
+
+ if (pcw_calc > U32_MAX) {
+ dev_err(mipi_tx->dev, "Calculated PCW=%llu overflow!\n", pcw_calc);
+ return -EINVAL;
+ }
+ pcw = (u32)pcw_calc;
+
+ 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);
+
+ 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 void mtk_mipi_tx_pll_disable(struct clk_hw *hw)
+{
+ struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
+ void __iomem *base = mipi_tx->regs;
+
+ mtk_phy_clear_bits(base + MIPITX_PLL_CON1, RG_DSI_PLL_EN);
+
+ mtk_phy_set_bits(base + MIPITX_PLL_PWR, AD_DSI_PLL_SDM_ISO_EN);
+ mtk_phy_clear_bits(base + MIPITX_PLL_PWR, AD_DSI_PLL_SDM_PWR_ON);
+}
+
+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);
+
+ 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,
+};
+
+static void mtk_mipi_tx_power_on_signal(struct phy *phy)
+{
+ struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
+ 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);
+ /* Wait for MIPI core to enable */
+ usleep_range(30, 100);
+ 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);
+
+ /*
+ * The MIPI TX drive strength is in the range of 3000 ~ 6000 microamps:
+ * RG_DSI_HSTX_LDO_REF_SEL expresses an offset from the minimum drive
+ * strength (3000uA) and can add a maximum offset of 3000uA, reaching a
+ * maximum drive strength of 3000+3000=6000uA.
+ */
+ mtk_phy_update_field(base + MIPITX_VOLTAGE_SEL, RG_DSI_HSTX_LDO_REF_SEL,
+ (mipi_tx->mipitx_drive - 3000) / 200);
+
+ mtk_phy_set_bits(base + MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
+}
+
+static void mtk_mipi_tx_power_off_signal(struct phy *phy)
+{
+ struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
+ void __iomem *base = mipi_tx->regs;
+
+ /* Switch ON each lane one by one */
+ mtk_phy_set_bits(base + MIPITX_D0_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_D1_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_D2_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_D3_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_CK_SW_CTL_EN, DSI_SW_CTL_EN);
+
+ writel(RG_DSI_PAD_TIEL_SEL | RG_DSI_BG_CORE_EN, base + MIPITX_LANE_CON);
+ writel(RG_DSI_PAD_TIEL_SEL, base + MIPITX_LANE_CON);
+}
+
+const struct mtk_mipitx_data mt8196_mipitx_data = {
+ .mipi_tx_clk_ops = &mtk_mipi_tx_pll_ops,
+ .mipi_tx_enable_signal = mtk_mipi_tx_power_on_signal,
+ .mipi_tx_disable_signal = mtk_mipi_tx_power_off_signal,
+};
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 065ea626093a..46f0cb3ac096 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -183,6 +183,7 @@ static const struct of_device_id mtk_mipi_tx_match[] = {
{ .compatible = "mediatek,mt2701-mipi-tx", .data = &mt2701_mipitx_data },
{ .compatible = "mediatek,mt8173-mipi-tx", .data = &mt8173_mipitx_data },
{ .compatible = "mediatek,mt8183-mipi-tx", .data = &mt8183_mipitx_data },
+ { .compatible = "mediatek,mt8196-mipi-tx", .data = &mt8196_mipitx_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mtk_mipi_tx_match);
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
index 5d4876f1dc95..e6f967078e3b 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
@@ -42,5 +42,5 @@ unsigned long mtk_mipi_tx_pll_recalc_rate(struct clk_hw *hw,
extern const struct mtk_mipitx_data mt2701_mipitx_data;
extern const struct mtk_mipitx_data mt8173_mipitx_data;
extern const struct mtk_mipitx_data mt8183_mipitx_data;
-
+extern const struct mtk_mipitx_data mt8196_mipitx_data;
#endif
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2 2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY
From: sashiko-bot @ 2026-07-13 10:32 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: devicetree, vkoul, olteanv, neil.armstrong, robh, conor+dt,
dri-devel, linux-phy
In-Reply-To: <20260713102322.21782-3-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Sleeping in Atomic Context
- [Low] Dead Code / Hardware Capability Restriction
--
--- Patch [2]: [PATCH v2 2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY ---
commit 290d9427c436e302c4aba5a26f5e3e1e9bb728f5
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 PHY has a different register layout and provides
support for more hardware features compared to the previous generation.
> 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
> @@ -0,0 +1,196 @@
[ ... ]
> +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 */
> + voltage = RG_DSI_PRD_REF_DEF;
[Severity: Low]
Is this block reachable? Later in mtk_mipi_tx_pll_determine_rate(),
req->rate is clamped to a maximum of 1,600,000,000 Hz. If the hardware
supports rates above 2.0 GHz, does the clamp limit need to be increased,
or is this dead code?
> + pres = MIPITX_PRESERVED_DEF;
> + txdiv = 1;
> + txdiv0 = 0;
> + } else if (mipi_tx->data_rate >= 1000000000) {
[ ... ]
> + 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]
Does this code sleep in an atomic context?
The mtk_mipi_tx_pll_enable() function is registered as the .enable
callback in mtk_mipi_tx_pll_ops below. The Common Clock Framework invokes
.enable under an enable_lock spinlock with interrupts disabled.
Calling usleep_range() here, which internally calls schedule(), will lead
to scheduling while atomic. Should this use an atomic-safe delay like
udelay(30), or should this logic be moved to the sleepable .prepare
callback?
> +
> + 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);
> +
> + 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/20260713102322.21782-1-angelogioacchino.delregno@collabora.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 0/2] PHY: Add support for MT8196 DSI PHY
From: AngeloGioacchino Del Regno @ 2026-07-13 10:38 UTC (permalink / raw)
To: chunfeng.yun
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, chunkuang.hu,
p.zabel, matthias.bgg, angelogioacchino.delregno, justin.yeh,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel, dri-devel, kernel
Changes in v3:
- Actually sent the correct patch series (sorry, I had messed up v2)
- Added definitions for minimum and maximum PLL rates
Changes in v2:
- Added a few comments and fix scheduling while atomic issue in clk
enable ops by waiting with udelay() instead
- Removed one unnecessary delay after clk/pwr isolation disablement
This series adds support for the DSI PHY found in the newer MediaTek
Dimensity 9400 (MT6991), Genio Pro 5100 (MT8894) and Kompanio Ultra
(MT8196) SoCs.
AngeloGioacchino Del Regno (2):
dt-bindings: phy: mediatek,dsi-phy: Add support for MT8196
phy: mediatek: Add support for MT8196 MIPI DSI PHY
.../bindings/phy/mediatek,dsi-phy.yaml | 1 +
drivers/phy/mediatek/Makefile | 1 +
.../phy/mediatek/phy-mtk-mipi-dsi-mt8196.c | 201 ++++++++++++++++++
drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 1 +
drivers/phy/mediatek/phy-mtk-mipi-dsi.h | 2 +-
5 files changed, 205 insertions(+), 1 deletion(-)
create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: phy: mediatek,dsi-phy: Add support for MT8196
From: AngeloGioacchino Del Regno @ 2026-07-13 10:38 UTC (permalink / raw)
To: chunfeng.yun
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, chunkuang.hu,
p.zabel, matthias.bgg, angelogioacchino.delregno, justin.yeh,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel, dri-devel, kernel, Krzysztof Kozlowski
In-Reply-To: <20260713103805.23030-1-angelogioacchino.delregno@collabora.com>
Add support for the MediaTek Kompanio Ultra (MT8196) SoC: this
chip features a DSI PHY that is similar to the one found in the
MT8183 SoC, but is a new (incremental) revision with a different
register layout.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
index c6d0bbdbe0e2..9df1dbe1253b 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -39,6 +39,7 @@ properties:
- const: mediatek,mt2701-mipi-tx
- const: mediatek,mt8173-mipi-tx
- const: mediatek,mt8183-mipi-tx
+ - const: mediatek,mt8196-mipi-tx
reg:
maxItems: 1
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY
From: AngeloGioacchino Del Regno @ 2026-07-13 10:38 UTC (permalink / raw)
To: chunfeng.yun
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, chunkuang.hu,
p.zabel, matthias.bgg, angelogioacchino.delregno, justin.yeh,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel, dri-devel, kernel
In-Reply-To: <20260713103805.23030-1-angelogioacchino.delregno@collabora.com>
Add support for the MIPI DSI PHY found in the MediaTek MT8196 SoC
and its variants.
This PHY has a different register layout and provides support for
more hardware features compared to the previous generation.
This initial driver only adds support for basic functionality that
is necessary to drive MIPI DSI displays as a D-PHY.
Feature additions like lane-swap, DPHY/CPHY switching, dual-port,
and others, may be done in the future.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/phy/mediatek/Makefile | 1 +
.../phy/mediatek/phy-mtk-mipi-dsi-mt8196.c | 201 ++++++++++++++++++
drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 1 +
drivers/phy/mediatek/phy-mtk-mipi-dsi.h | 2 +-
4 files changed, 204 insertions(+), 1 deletion(-)
create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 1b8088df71e8..ed0da708759b 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_PHY_MTK_MIPI_CSI_0_5) += phy-mtk-mipi-csi-0-5.o
phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o
phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o
+phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8196.o
obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
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 000000000000..eac3db9922db
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8196.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: jitao.shi <jitao.shi@mediatek.com>
+ *
+ * Copyright (c) 2026 Collabora Ltd.
+ * AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ */
+
+#include "phy-mtk-io.h"
+#include "phy-mtk-mipi-dsi.h"
+
+#define MIPITX_LANE_CON 0x0004
+#define RG_DSI_CPHY_T1DRV_EN BIT(0)
+#define RG_DSI_ANA_CK_SEL BIT(1)
+#define RG_DSI_PHY_CK_SEL BIT(2)
+#define RG_DSI_CPHY_EN BIT(3)
+#define RG_DSI_PHYCK_INV_EN BIT(4)
+#define RG_DSI_PWR04_EN BIT(5)
+#define RG_DSI_BG_LPF_EN BIT(6)
+#define RG_DSI_BG_CORE_EN BIT(7)
+#define RG_DSI_PAD_TIEL_SEL BIT(8)
+
+#define MIPITX_VOLTAGE_SEL 0x0008
+#define RG_DSI_HSTX_LDO_REF_SEL GENMASK(9, 6)
+#define RG_DSI_PRD_REF_SEL GENMASK(5, 0)
+#define RG_DSI_PRD_REF_MINI 0
+#define RG_DSI_PRD_REF_DEF 4
+#define RG_DSI_PRD_REF_MAX 7
+
+#define MIPITX_PRESERVED 0x000c
+#define MIPITX_PRESERVED_DEF 0xffff0040
+#define MIPITX_PRESERVED_MINI 0xffff00f0
+
+#define MIPITX_PLL_PWR 0x0028
+#define AD_DSI_PLL_SDM_PWR_ON BIT(0)
+#define AD_DSI_PLL_SDM_ISO_EN BIT(1)
+#define MIPITX_PLL_CON0 0x002c
+#define MIPITX_PLL_CON1 0x0030
+#define RG_DSI_PLL_EN BIT(0)
+#define RG_DSI_PLL_POSDIV GENMASK(10, 8)
+#define MIPITX_PLL_CON2 0x0034
+#define MIPITX_PLL_CON3 0x0038
+#define MIPITX_PLL_CON4 0x003c
+#define RG_DSI_PLL_IBIAS GENMASK(11, 10)
+
+#define MIPITX_D2_SW_CTL_EN 0x015c
+#define MIPITX_D0_SW_CTL_EN 0x025c
+#define MIPITX_CK_CKMODE_EN 0x0320
+#define DSI_CK_CKMODE_EN BIT(0)
+#define MIPITX_CK_SW_CTL_EN 0x035c
+#define MIPITX_D1_SW_CTL_EN 0x045c
+#define MIPITX_D3_SW_CTL_EN 0x055c
+#define DSI_SW_CTL_EN BIT(0)
+
+#define DSI_PHY_XTAL_CLK_HZ 26000000
+#define DSI_PHY_PLL_MIN_RATE_HZ 125000000
+#define DSI_PHY_PLL_MAX_RATE_HZ 2000000000
+
+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 >= DSI_PHY_PLL_MAX_RATE_HZ) {
+ /* Select higher signaling voltage for fast data rates */
+ voltage = RG_DSI_PRD_REF_DEF;
+ pres = MIPITX_PRESERVED_DEF;
+ 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;
+ }
+
+ pcw_calc = ((u64)(mipi_tx->data_rate / 2) * txdiv) << 24;
+ pcw_calc = div_u64(pcw_calc, DSI_PHY_XTAL_CLK_HZ);
+
+ if (pcw_calc > U32_MAX) {
+ dev_err(mipi_tx->dev, "Calculated PCW=%llu overflow!\n", pcw_calc);
+ return -EINVAL;
+ }
+ pcw = (u32)pcw_calc;
+
+ mtk_phy_update_field(base + MIPITX_VOLTAGE_SEL, RG_DSI_PRD_REF_SEL, voltage);
+ writel(pres, base + MIPITX_PRESERVED);
+
+ /* Enable the SDM and wait for power to stabilize */
+ 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(30);
+
+ /* Disable isolation and program PLL's PCW and dividers */
+ 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);
+
+ /* Enable the PLL and wait for the clock output to stabilize */
+ mtk_phy_set_bits(base + MIPITX_PLL_CON1, RG_DSI_PLL_EN);
+ udelay(30);
+
+ return 0;
+}
+
+static void mtk_mipi_tx_pll_disable(struct clk_hw *hw)
+{
+ struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
+ void __iomem *base = mipi_tx->regs;
+
+ mtk_phy_clear_bits(base + MIPITX_PLL_CON1, RG_DSI_PLL_EN);
+
+ mtk_phy_set_bits(base + MIPITX_PLL_PWR, AD_DSI_PLL_SDM_ISO_EN);
+ mtk_phy_clear_bits(base + MIPITX_PLL_PWR, AD_DSI_PLL_SDM_PWR_ON);
+}
+
+static int mtk_mipi_tx_pll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ req->rate = clamp_val(req->rate,
+ DSI_PHY_PLL_MIN_RATE_HZ, DSI_PHY_PLL_MAX_RATE_HZ);
+
+ 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,
+};
+
+static void mtk_mipi_tx_power_on_signal(struct phy *phy)
+{
+ struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
+ 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);
+ /* Wait for MIPI core to enable */
+ usleep_range(30, 100);
+ 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);
+
+ /*
+ * The MIPI TX drive strength is in the range of 3000 ~ 6000 microamps:
+ * RG_DSI_HSTX_LDO_REF_SEL expresses an offset from the minimum drive
+ * strength (3000uA) and can add a maximum offset of 3000uA, reaching a
+ * maximum drive strength of 3000+3000=6000uA.
+ */
+ mtk_phy_update_field(base + MIPITX_VOLTAGE_SEL, RG_DSI_HSTX_LDO_REF_SEL,
+ (mipi_tx->mipitx_drive - 3000) / 200);
+
+ mtk_phy_set_bits(base + MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
+}
+
+static void mtk_mipi_tx_power_off_signal(struct phy *phy)
+{
+ struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
+ void __iomem *base = mipi_tx->regs;
+
+ /* Switch ON each lane one by one */
+ mtk_phy_set_bits(base + MIPITX_D0_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_D1_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_D2_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_D3_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_phy_set_bits(base + MIPITX_CK_SW_CTL_EN, DSI_SW_CTL_EN);
+
+ writel(RG_DSI_PAD_TIEL_SEL | RG_DSI_BG_CORE_EN, base + MIPITX_LANE_CON);
+ writel(RG_DSI_PAD_TIEL_SEL, base + MIPITX_LANE_CON);
+}
+
+const struct mtk_mipitx_data mt8196_mipitx_data = {
+ .mipi_tx_clk_ops = &mtk_mipi_tx_pll_ops,
+ .mipi_tx_enable_signal = mtk_mipi_tx_power_on_signal,
+ .mipi_tx_disable_signal = mtk_mipi_tx_power_off_signal,
+};
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 065ea626093a..46f0cb3ac096 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -183,6 +183,7 @@ static const struct of_device_id mtk_mipi_tx_match[] = {
{ .compatible = "mediatek,mt2701-mipi-tx", .data = &mt2701_mipitx_data },
{ .compatible = "mediatek,mt8173-mipi-tx", .data = &mt8173_mipitx_data },
{ .compatible = "mediatek,mt8183-mipi-tx", .data = &mt8183_mipitx_data },
+ { .compatible = "mediatek,mt8196-mipi-tx", .data = &mt8196_mipitx_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mtk_mipi_tx_match);
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
index 5d4876f1dc95..e6f967078e3b 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
@@ -42,5 +42,5 @@ unsigned long mtk_mipi_tx_pll_recalc_rate(struct clk_hw *hw,
extern const struct mtk_mipitx_data mt2701_mipitx_data;
extern const struct mtk_mipitx_data mt8173_mipitx_data;
extern const struct mtk_mipitx_data mt8183_mipitx_data;
-
+extern const struct mtk_mipitx_data mt8196_mipitx_data;
#endif
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3 2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY
From: sashiko-bot @ 2026-07-13 10:48 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: conor+dt, dri-devel, devicetree, neil.armstrong, linux-phy, vkoul,
robh, olteanv
In-Reply-To: <20260713103805.23030-3-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Signaling voltage boost is exclusively tied to the absolute maximum clamped frequency, preventing high data rates from receiving the boost.
--
--- Patch [2]: [PATCH v3 2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY ---
commit a6b40caad1ac266a0481ef7b26baffceb672008c
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
phy: mediatek: Add support for MT8196 MIPI DSI PHY
This commit adds support for the MIPI DSI PHY found in the MediaTek MT8196
SoC and its variants. It introduces a new register layout and basic D-PHY
functionality needed to drive MIPI DSI displays.
> 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..eac3db9922dba
> --- /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 >= DSI_PHY_PLL_MAX_RATE_HZ) {
> + /* Select higher signaling voltage for fast data rates */
> + voltage = RG_DSI_PRD_REF_DEF;
> + pres = MIPITX_PRESERVED_DEF;
> + txdiv = 1;
> + txdiv0 = 0;
> + } else if (mipi_tx->data_rate >= 1000000000) {
[Severity: Medium]
Does this logic unintentionally restrict the higher signaling voltage to only
exact matches of the maximum PLL rate?
Since mtk_mipi_tx_pll_determine_rate() clamps the clock rate to
DSI_PHY_PLL_MAX_RATE_HZ (2.0 GHz), mipi_tx->data_rate can never exceed this
value. Consequently, panels requesting data rates slightly below 2.0 GHz
(for example, 1.99 GHz) will fall through to the 1.0 GHz branch instead of
receiving the voltage boost and correct PLL dividers intended for fast data
rates.
Could this conflation between the PLL octave band threshold and the maximum
frequency clamp macro also break the PLL divider logic if the maximum
supported rate limit is increased in the future?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260713103805.23030-1-angelogioacchino.delregno@collabora.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox