* Re: [PATCH 2/2] phy: nuvoton: Add MA35D1 USB2 OTG PHY driver
From: Vinod Koul @ 2026-06-11 11:04 UTC (permalink / raw)
To: Joey Lu
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jacky Huang, Shan-Chun Hung, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260604101220.1092822-3-a0987203069@gmail.com>
On 04-06-26, 18:12, Joey Lu wrote:
> Add a PHY driver for the USB 2.0 PHYs in the Nuvoton MA35D1 SoC,
> intended for use with the EHCI and OHCI host controllers.
>
> The MA35D1 SoC has two USB ports:
>
> - USB0: an OTG port shared between a DWC2 gadget controller and
> EHCI0/OHCI0 host controllers. A hardware mux automatically routes
> the physical USB0 signals to the appropriate controller based on the
> USB ID pin state. The DWC2 IP is device-only in hardware,
> so host-mode operation on USB0 is handled entirely by EHCI0/OHCI0.
>
> - USB1: a dedicated host-only port served by EHCI1/OHCI1.
>
> The driver implements:
> - Power-On Reset sequence with a guard that skips re-initialization if
> the PHY is already operational. This protects PHY0 when the DWC2
> gadget driver has already run its own init before EHCI0 probes.
> - Optional resistor calibration trim via nuvoton,rcalcode.
> - Optional over-current detect polarity via nuvoton,oc-active-high.
> - For PHY0 only: a USB role switch that exposes the hardware ID pin
> state (PWRONOTP[16]).
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/phy/nuvoton/Kconfig | 15 ++
> drivers/phy/nuvoton/Makefile | 1 +
> drivers/phy/nuvoton/phy-ma35d1-otg.c | 264 +++++++++++++++++++++++++++
> 3 files changed, 280 insertions(+)
> create mode 100644 drivers/phy/nuvoton/phy-ma35d1-otg.c
>
> diff --git a/drivers/phy/nuvoton/Kconfig b/drivers/phy/nuvoton/Kconfig
> index d02cae2db315..5fdd13f841e7 100644
> --- a/drivers/phy/nuvoton/Kconfig
> +++ b/drivers/phy/nuvoton/Kconfig
> @@ -10,3 +10,18 @@ config PHY_MA35_USB
> help
> Enable this to support the USB2.0 PHY on the Nuvoton MA35
> series SoCs.
> +
> +config PHY_MA35_USB_OTG
> + tristate "Nuvoton MA35 USB2.0 OTG PHY driver"
> + depends on ARCH_MA35 || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + select MFD_SYSCON
> + select USB_ROLE_SWITCH
> + help
> + Enable this to support the USB2.0 OTG PHY on the Nuvoton MA35
> + series SoCs. This driver handles PHY initialization for the
> + EHCI/OHCI host controllers, including per-PHY power-on reset,
> + resistor calibration trim, and over-current polarity
> + configuration. For the OTG port (PHY0), it also monitors the
> + USB ID pin and registers a USB role switch.
> diff --git a/drivers/phy/nuvoton/Makefile b/drivers/phy/nuvoton/Makefile
> index 2937e3921898..3ecd76f35d7c 100644
> --- a/drivers/phy/nuvoton/Makefile
> +++ b/drivers/phy/nuvoton/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
>
> obj-$(CONFIG_PHY_MA35_USB) += phy-ma35d1-usb2.o
> +obj-$(CONFIG_PHY_MA35_USB_OTG) += phy-ma35d1-otg.o
Have you considered reusing usb2 driver with a different power_on
function? Or handle the differences internally in the driver. There are
few similarities in two and some things are different
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 16/16] MAINTAINERS: expand Lynx 28G entry to cover Lynx 10G SerDes
From: Ioana Ciornei @ 2026-06-11 11:07 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, Tanjeff Moos, linux-kernel,
devicetree, Conor Dooley, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260610151952.2141019-17-vladimir.oltean@nxp.com>
On Wed, Jun 10, 2026 at 06:19:52PM +0300, Vladimir Oltean wrote:
> The lynx-28g and lynx-10g drivers share code and hardware architecture,
> so let them be covered by a single MAINTAINERS entry.
>
> Add myself as a second maintainer alongside Ioana Ciornei.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/2] Add support for the QMP PCIe PHYs in Qualcomm IPQ9650
From: Vinod Koul @ 2026-06-11 11:15 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260602-ipq9650_pcie_phy-v1-0-d8c32a36dbd9@oss.qualcomm.com>
On 02-06-26, 14:40, Kathiravan Thirumoorthy wrote:
> Qualcomm's IPQ9650 SoC has 3 Gen3 dual lane and 2 Gen3 single lane
> controllers with the QMP PHYs. Unlike the PHYs in the other IPQ SoC,
> refgen supply is needed to bringup the PHYs. Both single and dual lane
> shares the same HW init sequence. So reuse the tables.
>
> Document the compatible along with refgen supply and add the phy driver
> support for it.
Please rebase this on phy-next tomorrow. It does not apply for me due to
changes applied ealier today
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Vinod Koul @ 2026-06-11 11:26 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Neil Armstrong, Heiko Stuebner, Algea Cao, Dmitry Baryshkov,
kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <ebcad67e-e14a-4d0e-b3e0-79ae1d146eaf@collabora.com>
On 03-06-26, 13:27, Cristian Ciocaltea wrote:
> On 5/20/26 10:05 PM, Cristian Ciocaltea wrote:
> > Hi Vinod,
> >
> > On 5/11/26 9:21 PM, Cristian Ciocaltea wrote:
> >> This series provides a set of bug fixes and cleanups for the Rockchip
> >> Samsung HDPTX PHY driver.
> >>
> >> The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
> >> calculation and synchronization issues. Specifically, it fixes edge
> >> cases where the PHY PLL is pre-programmed by an external component (like
> >> a bootloader) or when changing the color depth (bpc) while keeping the
> >> modeline constant. Because the Common Clock Framework .set_rate()
> >> callback might not be invoked if the pixel clock remains unchanged, this
> >> previously led to out-of-sync states between CCF and the actual HDMI PHY
> >> configuration.
> >>
> >> The second part focuses on code cleanups and modernizing the register
> >> access. Now that dw_hdmi_qp driver has fully switched to using
> >> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
> >> and the restrict_rate_change flag logic. Finally, it refactors the
> >> driver to consistently use standard bitfield macros.
> >>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >> ---
> >> Changes in v2:
> >> - Collected Tested-by tags from Thomas and Simon
> >> - Fixed a typo in commit description of patch 1
> >> - Added a comment in patch 2 explaining why PLL config errors are
> >> ignored for rk_hdptx_phy_consumer_get()
> >> - Added a missed FIELD_GET conversion for lcpll_hw.pms_sdiv in patch 6
> >> - Rebased onto latest phy/fixes
> >> - Link to v1: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com
> >
> > In case you missed my comments from last week on the Sashiko AI review findings
> > - in short, I don't think there is anything to worry about and the series should
> > be fine to apply as-is. Please let me know if you would still prefer a new
> > revision.
> Kind reminder..
Please post a new revision based on phy/next
Thanks
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 09/16] phy: lynx-28g: make lynx_28g_pll_read_configuration() callable per PLL
From: Ioana Ciornei @ 2026-06-11 11:38 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, Tanjeff Moos, linux-kernel
In-Reply-To: <20260610151952.2141019-10-vladimir.oltean@nxp.com>
On Wed, Jun 10, 2026 at 06:19:45PM +0300, Vladimir Oltean wrote:
> In a future change, lynx_28g_pll_read_configuration() and
> lynx_28g_lane_read_configuration() will be made methods of struct
> lynx_info.
>
> There is no functional reason, but lynx_28g_lane_read_configuration() is
> called per lane and lynx_28g_pll_read_configuration() iterates over PLLs
> internally. So the API exported by the lynx_info structure would not be
> uniform. Change lynx_28g_pll_read_configuration() to also permit reading
> the PLL configuration individually, and move the for loop at the call
> site.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 11/16] phy: lynx-28g: add support for big endian register maps
From: Ioana Ciornei @ 2026-06-11 11:40 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, Tanjeff Moos, linux-kernel
In-Reply-To: <20260610151952.2141019-12-vladimir.oltean@nxp.com>
On Wed, Jun 10, 2026 at 06:19:47PM +0300, Vladimir Oltean wrote:
> Some 10G Lynx SerDes blocks are big endian and require byte swapping
> because the CPUs are little endian armv8 (LS1046A). Parse the
> "big-endian" device tree property, and modify the base lynx_read() and
> lynx_write() accessors to test this property before issuing either the
> ioread32() or ioread32be() variants (as per
> Documentation/driver-api/device-io.rst).
>
> All other accessors - lynx_rmw(), lynx_lane_read(), lynx_lane_write(),
> lynx_lane_rmw(), lynx_pll_read() - need to go through these endian-aware
> helpers.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 12/16] phy: lynx-28g: optimize read-modify-write operation
From: Ioana Ciornei @ 2026-06-11 11:41 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, Tanjeff Moos, linux-kernel
In-Reply-To: <20260610151952.2141019-13-vladimir.oltean@nxp.com>
On Wed, Jun 10, 2026 at 06:19:48PM +0300, Vladimir Oltean wrote:
> It is unnecessary to rewrite a register if the masked field already
> contains the desired value upon reading. The hardware behaviour does not
> depend upon register writes with identical values.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 13/16] phy: lynx-28g: improve phy_validate() procedure
From: Ioana Ciornei @ 2026-06-11 11:50 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, Tanjeff Moos, linux-kernel
In-Reply-To: <20260610151952.2141019-14-vladimir.oltean@nxp.com>
On Wed, Jun 10, 2026 at 06:19:49PM +0300, Vladimir Oltean wrote:
> lynx_28g_validate() suffers from the following shortcomings:
>
> - Changing the protocol should not be possible if the source protocol of
> the lane is unsupported. This is because lynx_28g_proto_conf[] only
> covers the register deltas between any pair of supported lane modes,
> but that delta is probably incomplete if the source protocol is, say,
> PCIe (which is currently assimilated by the driver to
> LANE_MODE_UNKNOWN).
>
> lynx_28g_proto_conf() does refuse changing the protocol if the current
> one is unsupported, but we shouldn't advertise it via phy_validate()
> at all.
>
> The phy_set_mode_ext() call should perform the exact same
> verifications as phy_validate() did, in case the caller bypassed
> phy_validate(). So we need to centralize the logic into a common
> validation. But lynx_28g_set_mode() later needs the lane_mode that
> this validation needs to compute anyway, so name the common helper
> lynx_phy_mode_to_lane_mode() and let it return that lane_mode.
>
> - Future core sanity checks on phy_validate() will want to differentiate
> the case where this optional method is not implemented from the case
> where the mode/submode is really not supported. So we shouldn't return
> -EOPNOTSUPP from lynx_28g_validate(), but -EINVAL to signal that we do
> implement the operation:
> https://lore.kernel.org/linux-phy/aY2lFTIALH7qEJmM@shell.armlinux.org.uk/
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
This series provides a set of bug fixes and cleanups for the Rockchip
Samsung HDPTX PHY driver.
The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
calculation and synchronization issues. Specifically, it fixes edge
cases where the PHY PLL is pre-programmed by an external component (like
a bootloader) or when changing the color depth (bpc) while keeping the
modeline constant. Because the Common Clock Framework .set_rate()
callback might not be invoked if the pixel clock remains unchanged, this
previously led to out-of-sync states between CCF and the actual HDMI PHY
configuration.
The second part focuses on code cleanups and modernizing the register
access. Now that dw_hdmi_qp driver has fully switched to using
phy_configure(), we can drop the deprecated TMDS rate setup workarounds
and the restrict_rate_change flag logic. Finally, it refactors the
driver to consistently use standard bitfield macros.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Changes in v3:
- Replaced div_u64() with DIV_ROUND_CLOSEST_ULL() in Patch 1 (Sashiko)
- Fixed theoretical usage_count unbalanced issue in Patch 2 (Sashiko)
- Rebased series onto latest phy/next
- Link to v2: https://patch.msgid.link/20260511-hdptx-clk-fixes-v2-0-664e41379cab@collabora.com
Changes in v2:
- Collected Tested-by tags from Thomas and Simon
- Fixed a typo in commit description of patch 1
- Added a comment in patch 2 explaining why PLL config errors are
ignored for rk_hdptx_phy_consumer_get()
- Added a missed FIELD_GET conversion for lcpll_hw.pms_sdiv in patch 6
- Rebased onto latest phy/fixes
- Link to v1: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com
---
Cristian Ciocaltea (6):
phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround
phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling
phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()
phy: rockchip: samsung-hdptx: Consistently use bitfield macros
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 216 ++++++++++------------
1 file changed, 95 insertions(+), 121 deletions(-)
---
base-commit: 293e19f416fa3f233a2fb013258f7abcb39ad6ed
change-id: 20260227-hdptx-clk-fixes-47426632f862
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 2/6] phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
Any changes to the PHY link rate and/or color depth done via the HDMI
PHY configuration API are not immediately programmed into the hardware,
but are delayed until the PHY usage count gets incremented from 0 to 1,
that is when it is powered on or when the PLL clock exposed through
the CCF API is prepared, whichever comes first.
Since the clock might remain in prepared state after subsequent PHY
config changes, the programming can also be triggered via
clk_ops.set_rate(). However, from the clock consumer perspective (i.e.
VOP2 display controller), the (pixel) clock rate doesn't vary with bpc,
as that is handled internally by the PHY and reflected in the TDMS
character rate only.
As a consequence, changing the bpc while preserving the modeline may
lead to out-of-sync issues between CCF and HDMI PHY config state,
because the .set_rate() callback is not invoked when clock rate remains
constant. This may also happen when the PHY PLL has been pre-programmed
by an external entity, e.g. the bootloader, which is actually a
regression introduced by the recent FRL patches.
Introduce a pll_config_dirty flag to keep track of uncommitted PHY
config changes and use it in clk_ops.determine_rate() to invalidate the
current clock rate (as known by CCF) and, consequently, ensure those
changes are programmed into hardware via clk_ops.set_rate().
Moreover, proceed with a similar fix in phy_ops.power_on() callback, to
handle the scenario where the CCF API is not used due to operating in
FRL mode, while the clock is still in a prepared state and thus
preventing rk_hdptx_phy_consumer_get() to apply the updated PHY
configuration.
Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support")
Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management")
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 84 +++++++++++++----------
1 file changed, 48 insertions(+), 36 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 710603afff86..5295d5f6f287 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -413,6 +413,7 @@ struct rk_hdptx_phy {
/* clk provider */
struct clk_hw hw;
+ bool pll_config_dirty;
bool restrict_rate_change;
atomic_t usage_count;
@@ -1260,13 +1261,19 @@ static int rk_hdptx_tmds_ropll_cmn_config(struct rk_hdptx_phy *hdptx)
static int rk_hdptx_pll_cmn_config(struct rk_hdptx_phy *hdptx)
{
+ int ret;
+
if (hdptx->hdmi_cfg.rate <= HDMI20_MAX_RATE)
- return rk_hdptx_tmds_ropll_cmn_config(hdptx);
+ ret = rk_hdptx_tmds_ropll_cmn_config(hdptx);
+ else if (hdptx->hdmi_cfg.rate == FRL_8G4L_RATE)
+ ret = rk_hdptx_frl_lcpll_ropll_cmn_config(hdptx);
+ else
+ ret = rk_hdptx_frl_lcpll_cmn_config(hdptx);
- if (hdptx->hdmi_cfg.rate == FRL_8G4L_RATE)
- return rk_hdptx_frl_lcpll_ropll_cmn_config(hdptx);
+ if (!ret)
+ hdptx->pll_config_dirty = false;
- return rk_hdptx_frl_lcpll_cmn_config(hdptx);
+ return ret;
}
static int rk_hdptx_frl_lcpll_mode_config(struct rk_hdptx_phy *hdptx)
@@ -1347,25 +1354,22 @@ static int rk_hdptx_phy_consumer_get(struct rk_hdptx_phy *hdptx)
return 0;
ret = regmap_read(hdptx->grf, GRF_HDPTX_STATUS, &status);
- if (ret)
- goto dec_usage;
-
- if (status & HDPTX_O_PLL_LOCK_DONE)
- dev_warn(hdptx->dev, "PLL locked by unknown consumer!\n");
+ if (ret) {
+ atomic_dec(&hdptx->usage_count);
+ return ret;
+ }
if (mode == PHY_MODE_DP) {
rk_hdptx_dp_reset(hdptx);
} else {
- ret = rk_hdptx_pll_cmn_config(hdptx);
- if (ret)
- goto dec_usage;
+ /*
+ * Ignore PLL config errors at this point as pll_config_dirty
+ * was not reset and, therefore, operation will be retried.
+ */
+ rk_hdptx_pll_cmn_config(hdptx);
}
return 0;
-
-dec_usage:
- atomic_dec(&hdptx->usage_count);
- return ret;
}
static int rk_hdptx_phy_consumer_put(struct rk_hdptx_phy *hdptx, bool force)
@@ -1700,13 +1704,18 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
if (ret)
rk_hdptx_phy_consumer_put(hdptx, true);
} else {
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
+ if (hdptx->pll_config_dirty)
+ ret = rk_hdptx_pll_cmn_config(hdptx);
- if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
- ret = rk_hdptx_frl_lcpll_mode_config(hdptx);
- else
- ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
+ if (!ret) {
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0,
+ HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
+
+ if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
+ ret = rk_hdptx_frl_lcpll_mode_config(hdptx);
+ else
+ ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
+ }
if (ret)
rk_hdptx_phy_consumer_put(hdptx, true);
@@ -2081,7 +2090,10 @@ static int rk_hdptx_phy_configure(struct phy *phy, union phy_configure_opts *opt
dev_err(hdptx->dev, "invalid hdmi params for phy configure\n");
} else {
hdptx->restrict_rate_change = true;
- dev_dbg(hdptx->dev, "%s rate=%llu bpc=%u\n", __func__,
+ hdptx->pll_config_dirty = true;
+
+ dev_dbg(hdptx->dev, "%s %s rate=%llu bpc=%u\n", __func__,
+ hdptx->hdmi_cfg.mode ? "FRL" : "TMDS",
hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
}
@@ -2303,8 +2315,19 @@ static int rk_hdptx_phy_clk_determine_rate(struct clk_hw *hw,
{
struct rk_hdptx_phy *hdptx = to_rk_hdptx_phy(hw);
- if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
- return hdptx->hdmi_cfg.rate;
+ /*
+ * Invalidate current clock rate to ensure rk_hdptx_phy_clk_set_rate()
+ * will be invoked to commit PLL configuration.
+ */
+ if (hdptx->pll_config_dirty) {
+ req->rate = 0;
+ return 0;
+ }
+
+ if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL) {
+ req->rate = hdptx->hdmi_cfg.rate;
+ return 0;
+ }
/*
* FIXME: Temporarily allow altering TMDS char rate via CCF.
@@ -2336,17 +2359,6 @@ static int rk_hdptx_phy_clk_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
struct rk_hdptx_phy *hdptx = to_rk_hdptx_phy(hw);
- unsigned long long link_rate = rate;
-
- if (hdptx->hdmi_cfg.mode != PHY_HDMI_MODE_FRL)
- link_rate = DIV_ROUND_CLOSEST_ULL(rate * hdptx->hdmi_cfg.bpc, 8);
-
- /* Revert any unlikely link rate change since determine_rate() */
- if (hdptx->hdmi_cfg.rate != link_rate) {
- dev_warn(hdptx->dev, "Reverting unexpected rate change from %llu to %llu\n",
- link_rate, hdptx->hdmi_cfg.rate);
- hdptx->hdmi_cfg.rate = link_rate;
- }
/*
* The link rate would be normally programmed in HW during
--
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 1/6] phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
The PHY PLL can be programmed by an external component, e.g. the
bootloader, just before the recalc_rate() callback is invoked during
devm_clk_hw_register() in the probe path.
Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and
attempts to compute the clock rate, while making use of the bpc value
from the HDMI PHY configuration, which always defaults to 8 because
phy_configure() was not run at that point. As a consequence, the
(re)calculated rate is incorrect when the actual bpc was higher than 8.
Do not rely on any of the hdmi_cfg members when computing the clock rate
and, instead, read the required input data (i.e. bpc), directly from the
hardware registers.
Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config")
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 2d973bc37f07..710603afff86 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -2168,7 +2168,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
struct lcpll_config lcpll_hw;
struct ropll_config ropll_hw;
u64 fout, sdm;
- u32 mode, val;
+ u32 mode, bpc, val;
int ret, i;
ret = regmap_read(hdptx->regmap, CMN_REG(0008), &mode);
@@ -2266,6 +2266,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
if (ret)
return 0;
ropll_hw.pms_sdiv = ((val & PLL_PCG_POSTDIV_SEL_MASK) >> 4) + 1;
+ bpc = (FIELD_GET(PLL_PCG_CLK_SEL_MASK, val) << 1) + 8;
fout = PLL_REF_CLK * ropll_hw.pms_mdiv;
if (ropll_hw.sdm_en) {
@@ -2280,7 +2281,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
fout = fout + sdm;
}
- return div_u64(fout * 2, ropll_hw.pms_sdiv * 10);
+ return DIV_ROUND_CLOSEST_ULL(fout * 2 * 8, ropll_hw.pms_sdiv * 10 * bpc);
}
static unsigned long rk_hdptx_phy_clk_recalc_rate(struct clk_hw *hw,
@@ -2288,19 +2289,13 @@ static unsigned long rk_hdptx_phy_clk_recalc_rate(struct clk_hw *hw,
{
struct rk_hdptx_phy *hdptx = to_rk_hdptx_phy(hw);
u32 status;
- u64 rate;
int ret;
ret = regmap_read(hdptx->grf, GRF_HDPTX_CON0, &status);
if (ret || !(status & HDPTX_I_PLL_EN))
return 0;
- rate = rk_hdptx_phy_clk_calc_rate_from_pll_cfg(hdptx);
-
- if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
- return rate;
-
- return DIV_ROUND_CLOSEST_ULL(rate * 8, hdptx->hdmi_cfg.bpc);
+ return rk_hdptx_phy_clk_calc_rate_from_pll_cfg(hdptx);
}
static int rk_hdptx_phy_clk_determine_rate(struct clk_hw *hw,
--
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 3/6] phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
Since commit ba9c2fe18c17 ("drm/rockchip: dw_hdmi_qp: Switch to
phy_configure()") the TMDS rate setup doesn't rely anymore on the
unconventional usage of the bus width, instead it is managed exclusively
through the HDMI PHY configuration API.
Drop the now obsolete workaround to retrieve the TMDS character rate via
phy_get_bus_width() during power_on().
While at it, get rid of the extra call to rk_hdptx_phy_consumer_put() by
moving the statement at the end of the function.
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 27 +++++------------------
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 5295d5f6f287..92c77e58518c 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -1660,22 +1660,6 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
enum phy_mode mode = phy_get_mode(phy);
int ret, lane;
- if (mode != PHY_MODE_DP) {
- if (!hdptx->hdmi_cfg.rate && hdptx->hdmi_cfg.mode != PHY_HDMI_MODE_FRL) {
- /*
- * FIXME: Temporary workaround to setup TMDS char rate
- * from the RK DW HDMI QP bridge driver.
- * Will be removed as soon the switch to the HDMI PHY
- * configuration API has been completed on both ends.
- */
- hdptx->hdmi_cfg.rate = phy_get_bus_width(hdptx->phy) & 0xfffffff;
- hdptx->hdmi_cfg.rate *= 100;
- }
-
- dev_dbg(hdptx->dev, "%s rate=%llu bpc=%u\n", __func__,
- hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
- }
-
ret = rk_hdptx_phy_consumer_get(hdptx);
if (ret)
return ret;
@@ -1701,9 +1685,10 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
rk_hdptx_dp_pll_init(hdptx);
ret = rk_hdptx_dp_aux_init(hdptx);
- if (ret)
- rk_hdptx_phy_consumer_put(hdptx, true);
} else {
+ dev_dbg(hdptx->dev, "%s rate=%llu bpc=%u\n", __func__,
+ hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
+
if (hdptx->pll_config_dirty)
ret = rk_hdptx_pll_cmn_config(hdptx);
@@ -1716,11 +1701,11 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
else
ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
}
-
- if (ret)
- rk_hdptx_phy_consumer_put(hdptx, true);
}
+ if (ret)
+ rk_hdptx_phy_consumer_put(hdptx, true);
+
return ret;
}
--
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 4/6] phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
Since commit 6efbd0f46dd8 ("phy: rockchip: samsung-hdptx: Restrict
altering TMDS char rate via CCF"), adjusting the rate via the Common
Clock Framework API has been disallowed.
To avoid breaking existing users until switching to the PHY config API,
it introduced a temporary exception to the rule, controlled via the
'restrict_rate_change' flag.
As the API transition completed, remove the now deprecated exception
logic.
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 42 +++++------------------
1 file changed, 8 insertions(+), 34 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 92c77e58518c..529dd2d5d9bd 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -414,7 +414,6 @@ struct rk_hdptx_phy {
/* clk provider */
struct clk_hw hw;
bool pll_config_dirty;
- bool restrict_rate_change;
atomic_t usage_count;
@@ -2074,7 +2073,6 @@ static int rk_hdptx_phy_configure(struct phy *phy, union phy_configure_opts *opt
if (ret) {
dev_err(hdptx->dev, "invalid hdmi params for phy configure\n");
} else {
- hdptx->restrict_rate_change = true;
hdptx->pll_config_dirty = true;
dev_dbg(hdptx->dev, "%s %s rate=%llu bpc=%u\n", __func__,
@@ -2301,41 +2299,17 @@ static int rk_hdptx_phy_clk_determine_rate(struct clk_hw *hw,
struct rk_hdptx_phy *hdptx = to_rk_hdptx_phy(hw);
/*
- * Invalidate current clock rate to ensure rk_hdptx_phy_clk_set_rate()
- * will be invoked to commit PLL configuration.
+ * For uncommitted PLL configuration, invalidate the current clock rate
+ * to ensure rk_hdptx_phy_clk_set_rate() will be always invoked.
+ * Otherwise, restrict the rate according to the PHY link setup.
*/
- if (hdptx->pll_config_dirty) {
+ if (hdptx->pll_config_dirty)
req->rate = 0;
- return 0;
- }
-
- if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL) {
+ else if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
req->rate = hdptx->hdmi_cfg.rate;
- return 0;
- }
-
- /*
- * FIXME: Temporarily allow altering TMDS char rate via CCF.
- * To be dropped as soon as the RK DW HDMI QP bridge driver
- * switches to make use of phy_configure().
- */
- if (!hdptx->restrict_rate_change && req->rate != hdptx->hdmi_cfg.rate) {
- struct phy_configure_opts_hdmi hdmi = {
- .tmds_char_rate = req->rate,
- };
-
- int ret = rk_hdptx_phy_verify_hdmi_config(hdptx, &hdmi, &hdptx->hdmi_cfg);
-
- if (ret)
- return ret;
- }
-
- /*
- * The TMDS char rate shall be adjusted via phy_configure() only,
- * hence ensure rk_hdptx_phy_clk_set_rate() won't be invoked with
- * a different rate argument.
- */
- req->rate = DIV_ROUND_CLOSEST_ULL(hdptx->hdmi_cfg.rate * 8, hdptx->hdmi_cfg.bpc);
+ else
+ req->rate = DIV_ROUND_CLOSEST_ULL(hdptx->hdmi_cfg.rate * 8,
+ hdptx->hdmi_cfg.bpc);
return 0;
}
--
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 5/6] phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
The 16 most significant bits of the general-purpose register (GRF) are
used as a write-enable mask for the remaining 16 bits.
Make use of the recently introduced FIELD_PREP_WM16() macro to avoid
open-coding the bit shift operations and improve code readability.
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 52 +++++++++++------------
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 529dd2d5d9bd..5ed110e2adc7 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (c) 2021-2022 Rockchip Electronics Co., Ltd.
- * Copyright (c) 2024 Collabora Ltd.
+ * Copyright (c) 2024-2026 Collabora Ltd.
*
* Author: Algea Cao <algea.cao@rock-chips.com>
* Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
@@ -10,6 +10,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/delay.h>
+#include <linux/hw_bitfield.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of.h>
@@ -949,7 +950,9 @@ static void rk_hdptx_pre_power_up(struct rk_hdptx_phy *hdptx)
reset_control_assert(hdptx->rsts[RST_CMN].rstc);
reset_control_assert(hdptx->rsts[RST_INIT].rstc);
- val = (HDPTX_I_PLL_EN | HDPTX_I_BIAS_EN | HDPTX_I_BGR_EN) << 16;
+ val = (FIELD_PREP_WM16(HDPTX_I_PLL_EN, 0) |
+ FIELD_PREP_WM16(HDPTX_I_BIAS_EN, 0) |
+ FIELD_PREP_WM16(HDPTX_I_BGR_EN, 0));
regmap_write(hdptx->grf, GRF_HDPTX_CON0, val);
}
@@ -960,8 +963,8 @@ static int rk_hdptx_post_enable_lane(struct rk_hdptx_phy *hdptx)
reset_control_deassert(hdptx->rsts[RST_LANE].rstc);
- val = (HDPTX_I_BIAS_EN | HDPTX_I_BGR_EN) << 16 |
- HDPTX_I_BIAS_EN | HDPTX_I_BGR_EN;
+ val = (FIELD_PREP_WM16(HDPTX_I_BIAS_EN, 1) |
+ FIELD_PREP_WM16(HDPTX_I_BGR_EN, 1));
regmap_write(hdptx->grf, GRF_HDPTX_CON0, val);
/* 3 lanes FRL mode */
@@ -990,16 +993,15 @@ static int rk_hdptx_post_enable_pll(struct rk_hdptx_phy *hdptx)
u32 val;
int ret;
- val = (HDPTX_I_BIAS_EN | HDPTX_I_BGR_EN) << 16 |
- HDPTX_I_BIAS_EN | HDPTX_I_BGR_EN;
+ val = (FIELD_PREP_WM16(HDPTX_I_BIAS_EN, 1) |
+ FIELD_PREP_WM16(HDPTX_I_BGR_EN, 1));
regmap_write(hdptx->grf, GRF_HDPTX_CON0, val);
usleep_range(10, 15);
reset_control_deassert(hdptx->rsts[RST_INIT].rstc);
usleep_range(10, 15);
- val = HDPTX_I_PLL_EN << 16 | HDPTX_I_PLL_EN;
- regmap_write(hdptx->grf, GRF_HDPTX_CON0, val);
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0, FIELD_PREP_WM16(HDPTX_I_PLL_EN, 1));
usleep_range(10, 15);
reset_control_deassert(hdptx->rsts[RST_CMN].rstc);
@@ -1037,7 +1039,9 @@ static void rk_hdptx_phy_disable(struct rk_hdptx_phy *hdptx)
reset_control_assert(hdptx->rsts[RST_CMN].rstc);
reset_control_assert(hdptx->rsts[RST_INIT].rstc);
- val = (HDPTX_I_PLL_EN | HDPTX_I_BIAS_EN | HDPTX_I_BGR_EN) << 16;
+ val = (FIELD_PREP_WM16(HDPTX_I_PLL_EN, 0) |
+ FIELD_PREP_WM16(HDPTX_I_BIAS_EN, 0) |
+ FIELD_PREP_WM16(HDPTX_I_BGR_EN, 0));
regmap_write(hdptx->grf, GRF_HDPTX_CON0, val);
}
@@ -1135,7 +1139,7 @@ static int rk_hdptx_frl_lcpll_cmn_config(struct rk_hdptx_phy *hdptx)
rk_hdptx_pre_power_up(hdptx);
- regmap_write(hdptx->grf, GRF_HDPTX_CON0, LC_REF_CLK_SEL << 16);
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0, FIELD_PREP_WM16(LC_REF_CLK_SEL, 0));
rk_hdptx_multi_reg_write(hdptx, rk_hdptx_common_cmn_init_seq);
rk_hdptx_multi_reg_write(hdptx, rk_hdptx_frl_lcpll_cmn_init_seq);
@@ -1178,8 +1182,7 @@ static int rk_hdptx_frl_lcpll_ropll_cmn_config(struct rk_hdptx_phy *hdptx)
rk_hdptx_pre_power_up(hdptx);
/* ROPLL input reference clock from LCPLL (cascade mode) */
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- (LC_REF_CLK_SEL << 16) | LC_REF_CLK_SEL);
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0, FIELD_PREP_WM16(LC_REF_CLK_SEL, 1));
rk_hdptx_multi_reg_write(hdptx, rk_hdptx_common_cmn_init_seq);
rk_hdptx_multi_reg_write(hdptx, rk_hdptx_frl_lcpll_ropll_cmn_init_seq);
@@ -1218,7 +1221,7 @@ static int rk_hdptx_tmds_ropll_cmn_config(struct rk_hdptx_phy *hdptx)
rk_hdptx_pre_power_up(hdptx);
- regmap_write(hdptx->grf, GRF_HDPTX_CON0, LC_REF_CLK_SEL << 16);
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0, FIELD_PREP_WM16(LC_REF_CLK_SEL, 0));
rk_hdptx_multi_reg_write(hdptx, rk_hdptx_common_cmn_init_seq);
rk_hdptx_multi_reg_write(hdptx, rk_hdptx_tmds_cmn_init_seq);
@@ -1336,11 +1339,9 @@ static void rk_hdptx_dp_reset(struct rk_hdptx_phy *hdptx)
FIELD_PREP(LN_TX_DRV_EI_EN_MASK, 0));
regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_I_PLL_EN << 16 | FIELD_PREP(HDPTX_I_PLL_EN, 0x0));
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_I_BIAS_EN << 16 | FIELD_PREP(HDPTX_I_BIAS_EN, 0x0));
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_I_BGR_EN << 16 | FIELD_PREP(HDPTX_I_BGR_EN, 0x0));
+ FIELD_PREP_WM16(HDPTX_I_PLL_EN, 0) |
+ FIELD_PREP_WM16(HDPTX_I_BIAS_EN, 0) |
+ FIELD_PREP_WM16(HDPTX_I_BGR_EN, 0));
}
static int rk_hdptx_phy_consumer_get(struct rk_hdptx_phy *hdptx)
@@ -1616,9 +1617,8 @@ static int rk_hdptx_dp_aux_init(struct rk_hdptx_phy *hdptx)
FIELD_PREP(OVRD_SB_VREG_EN_MASK, 0x1));
regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_I_BGR_EN << 16 | FIELD_PREP(HDPTX_I_BGR_EN, 0x1));
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_I_BIAS_EN << 16 | FIELD_PREP(HDPTX_I_BIAS_EN, 0x1));
+ FIELD_PREP_WM16(HDPTX_I_BGR_EN, 1) |
+ FIELD_PREP_WM16(HDPTX_I_BIAS_EN, 1));
usleep_range(20, 25);
reset_control_deassert(hdptx->rsts[RST_INIT].rstc);
@@ -1665,7 +1665,7 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
if (mode == PHY_MODE_DP) {
regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x1));
+ FIELD_PREP_WM16(HDPTX_MODE_SEL, 1));
for (lane = 0; lane < 4; lane++) {
regmap_update_bits(hdptx->regmap, LANE_REG(031e) + 0x400 * lane,
@@ -1693,7 +1693,7 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
if (!ret) {
regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
+ FIELD_PREP_WM16(HDPTX_MODE_SEL, 0));
if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
ret = rk_hdptx_frl_lcpll_mode_config(hdptx);
@@ -1828,8 +1828,7 @@ static int rk_hdptx_phy_set_rate(struct rk_hdptx_phy *hdptx,
u32 bw, status;
int ret;
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_I_PLL_EN << 16 | FIELD_PREP(HDPTX_I_PLL_EN, 0x0));
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0, FIELD_PREP_WM16(HDPTX_I_PLL_EN, 0));
switch (dp->link_rate) {
case 1620:
@@ -1885,8 +1884,7 @@ static int rk_hdptx_phy_set_rate(struct rk_hdptx_phy *hdptx,
regmap_update_bits(hdptx->regmap, CMN_REG(0095), DP_TX_LINK_BW_MASK,
FIELD_PREP(DP_TX_LINK_BW_MASK, bw));
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_I_PLL_EN << 16 | FIELD_PREP(HDPTX_I_PLL_EN, 0x1));
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0, FIELD_PREP_WM16(HDPTX_I_PLL_EN, 1));
ret = regmap_read_poll_timeout(hdptx->grf, GRF_HDPTX_STATUS,
status, FIELD_GET(HDPTX_O_PLL_LOCK_DONE, status),
--
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 6/6] phy: rockchip: samsung-hdptx: Consistently use bitfield macros
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
Make the code more robust and improve readability by using the available
bitfield macros (e.g. FIELD_PREP, FIELD_GET) whenever possible, instead
of open coding the related bit operations.
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 24 ++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 5ed110e2adc7..a8a8cd176897 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -53,6 +53,12 @@
/* CMN_REG(001e) */
#define LCPLL_PI_EN_MASK BIT(5)
#define LCPLL_100M_CLK_EN_MASK BIT(0)
+/* CMN_REG(0022) */
+#define ANA_LCPLL_PMS_PDIV_MASK GENMASK(7, 4)
+#define ANA_LCPLL_PMS_REFDIV_MASK GENMASK(3, 0)
+/* CMN_REG(0023) */
+#define LCPLL_PMS_SDIV_RBR_MASK GENMASK(7, 4)
+#define LCPLL_PMS_SDIV_HBR_MASK GENMASK(3, 0)
/* CMN_REG(0025) */
#define LCPLL_PMS_IQDIV_RSTN_MASK BIT(4)
/* CMN_REG(0028) */
@@ -1157,9 +1163,11 @@ static int rk_hdptx_frl_lcpll_cmn_config(struct rk_hdptx_phy *hdptx)
regmap_write(hdptx->regmap, CMN_REG(0020), cfg->pms_mdiv);
regmap_write(hdptx->regmap, CMN_REG(0021), cfg->pms_mdiv_afc);
regmap_write(hdptx->regmap, CMN_REG(0022),
- (cfg->pms_pdiv << 4) | cfg->pms_refdiv);
+ FIELD_PREP(ANA_LCPLL_PMS_PDIV_MASK, cfg->pms_pdiv) |
+ FIELD_PREP(ANA_LCPLL_PMS_REFDIV_MASK, cfg->pms_refdiv));
regmap_write(hdptx->regmap, CMN_REG(0023),
- (cfg->pms_sdiv << 4) | cfg->pms_sdiv);
+ FIELD_PREP(LCPLL_PMS_SDIV_RBR_MASK, cfg->pms_sdiv) |
+ FIELD_PREP(LCPLL_PMS_SDIV_HBR_MASK, cfg->pms_sdiv));
regmap_write(hdptx->regmap, CMN_REG(002a), cfg->sdm_deno);
regmap_write(hdptx->regmap, CMN_REG(002b), cfg->sdm_num_sign);
regmap_write(hdptx->regmap, CMN_REG(002c), cfg->sdm_num);
@@ -1229,8 +1237,10 @@ static int rk_hdptx_tmds_ropll_cmn_config(struct rk_hdptx_phy *hdptx)
regmap_write(hdptx->regmap, CMN_REG(0051), cfg->pms_mdiv);
regmap_write(hdptx->regmap, CMN_REG(0055), cfg->pms_mdiv_afc);
regmap_write(hdptx->regmap, CMN_REG(0059),
- (cfg->pms_pdiv << 4) | cfg->pms_refdiv);
- regmap_write(hdptx->regmap, CMN_REG(005a), cfg->pms_sdiv << 4);
+ FIELD_PREP(ANA_ROPLL_PMS_PDIV_MASK, cfg->pms_pdiv) |
+ FIELD_PREP(ANA_ROPLL_PMS_REFDIV_MASK, cfg->pms_refdiv));
+ regmap_write(hdptx->regmap, CMN_REG(005a),
+ FIELD_PREP(ROPLL_PMS_SDIV_RBR_MASK, cfg->pms_sdiv));
regmap_update_bits(hdptx->regmap, CMN_REG(005e), ROPLL_SDM_EN_MASK,
FIELD_PREP(ROPLL_SDM_EN_MASK, cfg->sdm_en));
@@ -2177,7 +2187,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
ret = regmap_read(hdptx->regmap, CMN_REG(0023), &val);
if (ret)
return 0;
- lcpll_hw.pms_sdiv = val & 0xf;
+ lcpll_hw.pms_sdiv = FIELD_GET(LCPLL_PMS_SDIV_HBR_MASK, val);
ret = regmap_read(hdptx->regmap, CMN_REG(002B), &val);
if (ret)
@@ -2197,7 +2207,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
ret = regmap_read(hdptx->regmap, CMN_REG(002D), &val);
if (ret)
return 0;
- lcpll_hw.sdc_n = (val & LCPLL_SDC_N_MASK) >> 1;
+ lcpll_hw.sdc_n = FIELD_GET(LCPLL_SDC_N_MASK, val);
for (i = 0; i < ARRAY_SIZE(rk_hdptx_frl_lcpll_cfg); i++) {
const struct lcpll_config *cfg = &rk_hdptx_frl_lcpll_cfg[i];
@@ -2258,7 +2268,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
ret = regmap_read(hdptx->regmap, CMN_REG(0086), &val);
if (ret)
return 0;
- ropll_hw.pms_sdiv = ((val & PLL_PCG_POSTDIV_SEL_MASK) >> 4) + 1;
+ ropll_hw.pms_sdiv = FIELD_GET(PLL_PCG_POSTDIV_SEL_MASK, val) + 1;
bpc = (FIELD_GET(PLL_PCG_CLK_SEL_MASK, val) << 1) + 8;
fout = PLL_REF_CLK * ropll_hw.pms_mdiv;
--
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 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Cristian Ciocaltea @ 2026-06-11 12:34 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Heiko Stuebner, Algea Cao, Dmitry Baryshkov,
kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <aiqbX8kon8HtiSEl@vaman>
On 6/11/26 2:26 PM, Vinod Koul wrote:
> On 03-06-26, 13:27, Cristian Ciocaltea wrote:
>> On 5/20/26 10:05 PM, Cristian Ciocaltea wrote:
>>> Hi Vinod,
>>>
>>> On 5/11/26 9:21 PM, Cristian Ciocaltea wrote:
>>>> This series provides a set of bug fixes and cleanups for the Rockchip
>>>> Samsung HDPTX PHY driver.
>>>>
>>>> The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
>>>> calculation and synchronization issues. Specifically, it fixes edge
>>>> cases where the PHY PLL is pre-programmed by an external component (like
>>>> a bootloader) or when changing the color depth (bpc) while keeping the
>>>> modeline constant. Because the Common Clock Framework .set_rate()
>>>> callback might not be invoked if the pixel clock remains unchanged, this
>>>> previously led to out-of-sync states between CCF and the actual HDMI PHY
>>>> configuration.
>>>>
>>>> The second part focuses on code cleanups and modernizing the register
>>>> access. Now that dw_hdmi_qp driver has fully switched to using
>>>> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
>>>> and the restrict_rate_change flag logic. Finally, it refactors the
>>>> driver to consistently use standard bitfield macros.
>>>>
>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>>> ---
>>>> Changes in v2:
>>>> - Collected Tested-by tags from Thomas and Simon
>>>> - Fixed a typo in commit description of patch 1
>>>> - Added a comment in patch 2 explaining why PLL config errors are
>>>> ignored for rk_hdptx_phy_consumer_get()
>>>> - Added a missed FIELD_GET conversion for lcpll_hw.pms_sdiv in patch 6
>>>> - Rebased onto latest phy/fixes
>>>> - Link to v1: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com
>>>
>>> In case you missed my comments from last week on the Sashiko AI review findings
>>> - in short, I don't think there is anything to worry about and the series should
>>> be fine to apply as-is. Please let me know if you would still prefer a new
>>> revision.
>> Kind reminder..
>
> Please post a new revision based on phy/next
Done (also addressed the confirmed Sashiko reported issues):
https://lore.kernel.org/all/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com/
Thanks,
Cristian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 2/6] phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
From: sashiko-bot @ 2026-06-11 12:52 UTC (permalink / raw)
To: Cristian Ciocaltea; +Cc: neil.armstrong, olteanv, vkoul, linux-phy
In-Reply-To: <20260611-hdptx-clk-fixes-v3-2-67b1b0c00e16@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Ignoring PLL configuration errors in `rk_hdptx_phy_consumer_get()` leads to silent hardware failure and violates the CCF API contract.
--
commit 6b14268a38889c73eedd6c085d780316eb0e7c3c
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
This commit introduces a pll_config_dirty flag to keep track of uncommitted
PHY configuration changes. It ensures that changes to the PHY link rate or
color depth are delayed and properly programmed into the hardware when the
PHY usage count is incremented.
> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> index 710603afff866..5295d5f6f287a 100644
> --- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> +++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
[ ... ]
> @@ -1347,25 +1354,22 @@ static int rk_hdptx_phy_consumer_get(struct rk_hdptx_phy *hdptx)
> return 0;
>
> ret = regmap_read(hdptx->grf, GRF_HDPTX_STATUS, &status);
> - if (ret)
> - goto dec_usage;
> -
> - if (status & HDPTX_O_PLL_LOCK_DONE)
> - dev_warn(hdptx->dev, "PLL locked by unknown consumer!\n");
> + if (ret) {
> + atomic_dec(&hdptx->usage_count);
> + return ret;
> + }
>
> if (mode == PHY_MODE_DP) {
> rk_hdptx_dp_reset(hdptx);
> } else {
> - ret = rk_hdptx_pll_cmn_config(hdptx);
> - if (ret)
> - goto dec_usage;
> + /*
> + * Ignore PLL config errors at this point as pll_config_dirty
> + * was not reset and, therefore, operation will be retried.
> + */
> + rk_hdptx_pll_cmn_config(hdptx);
> }
>
> return 0;
[Severity: High]
Is it safe to ignore the return value of rk_hdptx_pll_cmn_config() here?
If rk_hdptx_pll_cmn_config() fails, we return 0 to the caller. This causes
clk_prepare() to return success to the Common Clock Framework even though
the hardware failed to initialize. Does this violate the API contract?
Also, hdptx->usage_count is left incremented despite the hardware failure.
[ ... ]
> @@ -1700,13 +1704,18 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
> if (ret)
> rk_hdptx_phy_consumer_put(hdptx, true);
> } else {
> - regmap_write(hdptx->grf, GRF_HDPTX_CON0,
> - HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
> + if (hdptx->pll_config_dirty)
> + ret = rk_hdptx_pll_cmn_config(hdptx);
[Severity: High]
Will this retry block actually execute if pll_config_dirty was already false?
If the initial rk_hdptx_pll_cmn_config() failure happened in
rk_hdptx_phy_consumer_get() when pll_config_dirty was false, it seems
pll_config_dirty remains false. When rk_hdptx_phy_power_on() is later called,
it checks if pll_config_dirty is true and might skip the retry entirely,
leaving the hardware in a partially initialized state with an unlocked PLL.
> + if (!ret) {
> + regmap_write(hdptx->grf, GRF_HDPTX_CON0,
> + HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
> +
> + if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
> + ret = rk_hdptx_frl_lcpll_mode_config(hdptx);
> + else
> + ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
> + }
>
> if (ret)
> rk_hdptx_phy_consumer_put(hdptx, true);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 2/6] phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
From: Cristian Ciocaltea @ 2026-06-11 14:11 UTC (permalink / raw)
To: sashiko-reviews; +Cc: neil.armstrong, olteanv, vkoul, linux-phy
In-Reply-To: <20260611125215.9BE6C1F00898@smtp.kernel.org>
Hi,
TL;DR: This is similar to the review we got on v2, i.e. no real concerns, the
series can be safely applied.
Regards,
Cristian
On 6/11/26 3:52 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider: - [High] Ignoring PLL configuration errors in
> `rk_hdptx_phy_consumer_get()` leads to silent hardware failure and violates
> the CCF API contract. --
>
> commit 6b14268a38889c73eedd6c085d780316eb0e7c3c Author: Cristian Ciocaltea
> <cristian.ciocaltea@collabora.com>
>
> phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
>
> This commit introduces a pll_config_dirty flag to keep track of uncommitted
> PHY configuration changes. It ensures that changes to the PHY link rate or
> color depth are delayed and properly programmed into the hardware when the PHY
> usage count is incremented.
>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
>> b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c index
>> 710603afff866..5295d5f6f287a 100644 ---
>> a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c +++
>> b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> [ ... ]
>> @@ -1347,25 +1354,22 @@ static int rk_hdptx_phy_consumer_get(struct
>> rk_hdptx_phy *hdptx) return 0;
>>
>> ret = regmap_read(hdptx->grf, GRF_HDPTX_STATUS, &status); - if (ret)
>> - goto dec_usage; - - if (status &
>> HDPTX_O_PLL_LOCK_DONE) - dev_warn(hdptx->dev, "PLL locked
>> by unknown consumer!\n"); + if (ret) { +
>> atomic_dec(&hdptx->usage_count); + return ret; + }
>>
>> if (mode == PHY_MODE_DP) { rk_hdptx_dp_reset(hdptx); } else { -
>> ret = rk_hdptx_pll_cmn_config(hdptx); - if (ret) -
>> goto dec_usage; + /* + * Ignore PLL config
>> errors at this point as pll_config_dirty + * was not reset
>> and, therefore, operation will be retried. + */ +
>> rk_hdptx_pll_cmn_config(hdptx); }
>>
>> return 0;
>
> [Severity: High] Is it safe to ignore the return value of
> rk_hdptx_pll_cmn_config() here?
Yes, this is done on purpose since the error is not critical at this point and
we don't want to bail out too early. In practice, this shouldn't happen, unless
the hardware is faulty, in which case the kernel is likely to crash before
reaching this.
>
> If rk_hdptx_pll_cmn_config() fails, we return 0 to the caller. This causes
> clk_prepare() to return success to the Common Clock Framework even though
> the hardware failed to initialize. Does this violate the API contract?
>
> Also, hdptx->usage_count is left incremented despite the hardware failure.
That's not a valid usecase, the hardware will be eventually programmed by
rk_hdptx_phy_clk_set_rate() or rk_hdptx_phy_power_on(), whichever comes first.
The clock provider is dependent on the PHY configuration, which is expected to
follow clk_prepare_enable().
>
> [ ... ]
>> @@ -1700,13 +1704,18 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
>> if (ret)
>> rk_hdptx_phy_consumer_put(hdptx, true);
>> } else {
>> - regmap_write(hdptx->grf, GRF_HDPTX_CON0,
>> - HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
>> + if (hdptx->pll_config_dirty)
>> + ret = rk_hdptx_pll_cmn_config(hdptx);
>
> [Severity: High]
> Will this retry block actually execute if pll_config_dirty was already false?
>
> If the initial rk_hdptx_pll_cmn_config() failure happened in
> rk_hdptx_phy_consumer_get() when pll_config_dirty was false, it seems
> pll_config_dirty remains false. When rk_hdptx_phy_power_on() is later called,
> it checks if pll_config_dirty is true and might skip the retry entirely,
> leaving the hardware in a partially initialized state with an unlocked PLL.
The hardware is not really useful without rk_hdptx_phy_configure() being called,
which sets pll_config_dirty to true.
>
>> + if (!ret) {
>> + regmap_write(hdptx->grf, GRF_HDPTX_CON0,
>> + HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
>> +
>> + if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
>> + ret = rk_hdptx_frl_lcpll_mode_config(hdptx);
>> + else
>> + ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
>> + }
>>
>> if (ret)
>> rk_hdptx_phy_consumer_put(hdptx, true);
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/6] phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
From: sashiko-bot @ 2026-06-11 14:43 UTC (permalink / raw)
To: Cristian Ciocaltea; +Cc: neil.armstrong, vkoul, olteanv, linux-phy
In-Reply-To: <20260611-hdptx-clk-fixes-v3-1-67b1b0c00e16@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Potential divide-by-zero when computing SDM fraction if bootloader leaves specific PLL registers uninitialized or misconfigured.
- [High] FRL_8G4L_RATE (3.2GHz) cascade mode is not handled correctly in clock rate recalculation, causing it to return 0.
--
commit 7c989d5f5cf68e3aea19b9dd58be7c8b907619aa
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
This patch updates the rate recalculation logic to read the bpc value directly
from hardware registers instead of relying on the uninitialized HDMI PHY
configuration. This resolves incorrect rate calculations when bpc is higher
than 8.
> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> index 2d973bc37f076..710603afff866 100644
> --- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> +++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> @@ -2168,7 +2168,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
> struct lcpll_config lcpll_hw;
> struct ropll_config ropll_hw;
> u64 fout, sdm;
> - u32 mode, val;
> + u32 mode, bpc, val;
> int ret, i;
>
> ret = regmap_read(hdptx->regmap, CMN_REG(0008), &mode);
[Severity: High]
This is a pre-existing issue, but does
rk_hdptx_phy_clk_calc_rate_from_pll_cfg() fail to handle cascade mode for the
3.2GHz FRL_8G4L_RATE?
When the hardware is configured in cascade mode using both LCPLL and ROPLL,
CMN_REG(0008) has LCPLL_LCVCO_MODE_EN_MASK set.
The function sees this bit and assumes the rate must be determined solely
from the rk_hdptx_frl_lcpll_cfg array:
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:rk_hdptx_phy_clk_calc_rate_from_pll_cfg() {
...
if (mode & LCPLL_LCVCO_MODE_EN_MASK) {
...
for (i = 0; i < ARRAY_SIZE(rk_hdptx_frl_lcpll_cfg); i++) {
...
return cfg->rate;
}
dev_dbg(hdptx->dev, "%s no FRL match found\n", __func__);
return 0;
}
...
}
For the 3.2GHz config, it searches the array for an entry with pms_mdiv of
107, finds no match, and returns 0 instead of falling through to the ROPLL
calculation.
Could this bypass the ROPLL calculation and cause the clock framework to
register a 0 Hz rate for the 3.2GHz HDMI mode?
[ ... ]
> @@ -2266,6 +2266,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
> if (ret)
> return 0;
> ropll_hw.pms_sdiv = ((val & PLL_PCG_POSTDIV_SEL_MASK) >> 4) + 1;
> + bpc = (FIELD_GET(PLL_PCG_CLK_SEL_MASK, val) << 1) + 8;
>
> fout = PLL_REF_CLK * ropll_hw.pms_mdiv;
> if (ropll_hw.sdm_en) {
[Severity: High]
This is a pre-existing issue, but could this division trigger a
divide-by-zero panic if the bootloader leaves the PLL registers
uninitialized or misconfigured?
The calculation uses div_u64() with a denominator read directly from hardware:
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:rk_hdptx_phy_clk_calc_rate_from_pll_cfg() {
...
if (ropll_hw.sdm_en) {
sdm = div_u64(PLL_REF_CLK * ropll_hw.sdc_deno *
ropll_hw.pms_mdiv * ropll_hw.sdm_num,
16 * ropll_hw.sdm_deno *
(ropll_hw.sdc_deno * ropll_hw.sdc_n - ropll_hw.sdc_num));
...
}
The values ropll_hw.sdm_deno, ropll_hw.sdc_deno, ropll_hw.sdc_n, and
ropll_hw.sdc_num are populated from CMN_REG(0060), CMN_REG(0070), etc.,
without any zero-checks.
If the PLL is enabled but these registers evaluate to 0, it appears this
would cause a panic during driver probe or when the clock framework queries
the rate.
Is it safe to directly trust the hardware register state for this denominator
without sanitization?
> @@ -2280,7 +2281,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
> fout = fout + sdm;
> }
>
> - return div_u64(fout * 2, ropll_hw.pms_sdiv * 10);
> + return DIV_ROUND_CLOSEST_ULL(fout * 2 * 8, ropll_hw.pms_sdiv * 10 * bpc);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/3] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi
From: Vinod Koul @ 2026-06-11 15:29 UTC (permalink / raw)
To: palash.kambar
Cc: neil.armstrong, robh, krzk+dt, conor+dt, mani, alim.akhtar,
bvanassche, andersson, dmitry.baryshkov, abel.vesa, luca.weiss,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat
In-Reply-To: <20260526090956.2340262-4-palash.kambar@oss.qualcomm.com>
On 26-05-26, 14:39, palash.kambar@oss.qualcomm.com wrote:
> From: Palash Kambar <palash.kambar@oss.qualcomm.com>
>
> Add the init sequence tables and config for the UFS QMP phy found in
> the Hawi SoC.
This fails to build for me on phy/next
In file included from drivers/phy/qualcomm/phy-qcom-qmp-ufs.c:24:
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c:1878:26: error: ‘QSERDES_V8_COM_PLL_IVCO_MODE1’ undeclared here (not in a function); did you mean ‘QSERDES_V6_COM_PLL_IVCO_MODE1’?
1878 | QMP_PHY_INIT_CFG(QSERDES_V8_COM_PLL_IVCO_MODE1, 0x1f),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/phy/qualcomm/phy-qcom-qmp-common.h:22:27: note: in definition of macro ‘QMP_PHY_INIT_CFG’
22 | .offset = o, \
| ^
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c:1879:26: error: ‘QSERDES_V8_COM_CMN_IETRIM’ undeclared here (not in a function); did you mean ‘QSERDES_V6_COM_CMN_IETRIM’?
1879 | QMP_PHY_INIT_CFG(QSERDES_V8_COM_CMN_IETRIM, 0x07),
| ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/phy/qualcomm/phy-qcom-qmp-common.h:22:27: note: in definition of macro ‘QMP_PHY_INIT_CFG’
22 | .offset = o, \
And so on. Looks like QSERDES_V8_COM_PLL_IVCO_MODE1 etc are not define.
Please rebase test and send again
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krzysztof Kozlowski, YijieYang, Konrad Dybcio
In-Reply-To: <20260610-topic-purwa_phy_shutup_warning-v2-1-951c1fbfe9b2@oss.qualcomm.com>
On Wed, 10 Jun 2026 11:45:12 +0200, Konrad Dybcio wrote:
> Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation.
> The PHY is however physically laid out as if it were to, since there
> are two separate ports (A/B).
>
> Split out a new if-then block to un-require the bifurcation register
> handle to squash this warning:
>
> [...]
Applied, thanks!
[1/1] dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa
commit: b3ee497970c63cea37976aeaa84bac39611fe0eb
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1] phy: nxp-ptn3222: Use named initializers for struct i2c_device_id
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Neil Armstrong, linux-phy, linux-kernel
In-Reply-To: <20260519151957.1593214-2-u.kleine-koenig@baylibre.com>
On Tue, 19 May 2026 17:19:57 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> This patch doesn't modify the compiled arrays, only their representation
> in source form benefits. The former was confirmed with x86 and arm64
> builds.
>
> [...]
Applied, thanks!
[1/1] phy: nxp-ptn3222: Use named initializers for struct i2c_device_id
commit: 4904117935319233b1ec8f0528560dc91e8ae4c2
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] PCI: qcom: Add support for Eliza
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Bjorn Andersson,
Krishna Chaitanya Chundru
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20260608-eliza-v3-0-9bdeb7434b28@oss.qualcomm.com>
On Mon, 08 Jun 2026 14:18:12 +0530, Krishna Chaitanya Chundru wrote:
> This series adds PCIe support for the Qualcomm Eliza SoC. Eliza includes
> two PCIe root complex controllers capable of 8GT/s x1 and 8GT/s x2.
>
> The QMP PCIe PHY support adds a new Gen3x1 PHY configuration with
> Eliza-specific initialization tables, and reuses the existing SM8550
> Gen3x2 configuration for the x2 PHY instance.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: phy: sc8280xp-qmp-pcie: Document Eliza PCIe phy
commit: afdf104ec11681aacba0865863647f725f47ab90
[3/3] phy: qcom: qmp-pcie: Add QMP PCIe PHY support for Eliza
commit: fdd2913a4e505716dce5c9f89c268628d9a019d5
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 00/16] New Generic PHY driver for Lynx 10G SerDes
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: linux-phy, Vladimir Oltean
Cc: Ioana Ciornei, Neil Armstrong, Tanjeff Moos, linux-kernel
In-Reply-To: <20260610151952.2141019-1-vladimir.oltean@nxp.com>
On Wed, 10 Jun 2026 18:19:36 +0300, Vladimir Oltean wrote:
> The 10G Lynx SerDes is present on NXP LS1028A, LS1046A, LS1088A,
> LS2088A and other SoCs (unsupported here). It is an older generation of
> the 28G Lynx present in LX2160A and LX2162A.
>
> Modify the Generic PHY driver for lynx-28g to create a common portion
> (lynx-common) and add a new driver for lynx-10g and DT bindings.
>
> [...]
Applied, thanks!
[01/16] phy: lynx-28g: avoid returning NULL in of_xlate() function
commit: 493f8fc57bf685e23d3c924dbd787249d47fb972
[02/16] phy: lynx-28g: reject probing on devices with unsupported OF nodes
commit: a45f9dac20b6757487502109feac0298ec78f3bd
[03/16] phy: lynx-28g: move lane mode helpers to new core module
commit: ac0ffe7cf1221182f4068d8aaf825b01655c7ca9
[04/16] phy: lynx-28g: move data structures to core
commit: b7021a4d3129aeb0e25c3edcaf3a36199e73f652
[05/16] phy: lynx-28g: common lynx_pll_get()
commit: d4550ea4b161202607e31b0b6c6c34fef7e2b797
[06/16] phy: lynx-28g: generalize protocol converter accessors
commit: 51c25f4b0c883c1b7eee5f8f3aa0c2245eb6351a
[07/16] phy: lynx-28g: provide default lynx_lane_supports_mode() implementation
commit: 09697afa157df0a420fb6b107a71bb45dd32aabf
[08/16] phy: lynx-28g: move struct lynx_info definitions downwards
commit: 9515c35eaac9fc51717c8dbb5d18ec5a923b8342
[09/16] phy: lynx-28g: make lynx_28g_pll_read_configuration() callable per PLL
commit: b1c4d866edb7aa62048f5e373586ac8580ef0ec8
[10/16] phy: lynx-28g: common probe() and remove()
commit: 719a2da392349db052532db89637622a71d14d49
[11/16] phy: lynx-28g: add support for big endian register maps
commit: c6c1d7dfd59b181b96b0909b63e140b0aa61ac59
[12/16] phy: lynx-28g: optimize read-modify-write operation
commit: f64ef1995dd6f902da0bd3bc60c72c825098b652
[13/16] phy: lynx-28g: improve phy_validate() procedure
commit: f124b54b19223c85dabd9421ec622d8256e240de
[14/16] dt-bindings: phy: lynx-10g: initial document
commit: a7dc4e95d31c6bc674b24697aacadf7c6f1cbe6a
[15/16] phy: lynx-10g: new driver
commit: 6dc92ba487a21b923eb409357ffe966a6e9d2343
[16/16] MAINTAINERS: expand Lynx 28G entry to cover Lynx 10G SerDes
commit: 61df73e12eb245adc54606de287cf8898b3a66c4
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Neil Armstrong, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Liu Ying, Felix Gu
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, sashiko
In-Reply-To: <20260609-lvds-phy-v1-1-6ad790c6d0ea@gmail.com>
On Tue, 09 Jun 2026 22:48:50 +0800, Felix Gu wrote:
> The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get()
> with pm_runtime_put(). The asynchronous variant queues a work item
> to handle the idle check and potential suspend, which can be cancelled
> by a subsequent pm_runtime_disable() call if probe fails after the reset.
>
> Switch to pm_runtime_put_sync() to run the idle check and suspend
> synchronously.
>
> [...]
Applied, thanks!
[1/1] phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
commit: b28ec8ce03d8f9a0f7a9ec84f1ed9b5a6f393791
Best regards,
--
~Vinod
--
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