summaryrefslogtreecommitdiff
path: root/drivers/phy/rockchip
AgeCommit message (Collapse)Author
2026-10-05phy: rockchip: phy-rockchip-inno-csidphy: add support for rk3576 variantAmin Gattout
The two RK3576 MIPI CSI-2 DPHYs can be supported using the existing phy-rockchip-inno-csidphy driver, but they need their own driver data: as on RK3588 the GRF control bits live in a dedicated CSI-DPHY GRF at offset 0x0, while each PHY instance only has an APB reset line, as on RK3568. Signed-off-by: Amin Gattout <amin.gattout@gmail.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Michael Riesch <michael.riesch@collabora.com> Link: https://patch.msgid.link/20260915-rk3576-dphy-v2-3-b56e68b54b8c@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-04phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level controlCristian Ciocaltea
During HDMI 2.1 FRL link training, the source may need to incrementally raise the TxFFE level in response to persistent link failures reported by the sink during LTS3. The phy_configure_opts_hdmi struct now carries ffe_level and set_ffe_level fields to convey such an update independently of a full rate reconfiguration. Wire up the optional TxFFE control in the Samsung HDPTX PHY driver. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260901-hdptx-ffe-v2-3-3a5922c76fc5@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-04phy: rockchip: samsung-hdptx: Handle PHY config after module reloadCristian Ciocaltea
The pll_config_dirty mechanism introduced in commit aec3e4ce25da ("phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes") invalidates the clock rate in determine_rate() by resetting req->rate to zero, ensuring CCF will invoke set_rate() to program pending PLL configuration changes into hardware. However, after a module reload cycle the PHY PLL clock gets re-registered with CCF, which causes the framework's cached rate to also be zero. Setting req->rate to zero then has no effect, since CCF sees no difference between the requested and current rates and skips calling set_rate(), leaving the PLL unconfigured. Address this by first computing the actual target rate from the HDMI link configuration, and only then invalidating it when it matches the CCF cached rate. Fixes: aec3e4ce25da ("phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260901-hdptx-ffe-v2-2-3a5922c76fc5@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: naneng-combphy: Fix TX detect RX termination errataShawn Lin
Some PHY revisions may fail to detect the peer RX's termination resistor (RTERM) under certain critical temperature conditions. This causes TX detection failures on PCIe links. Add a workaround to force the RTERM detection ready signal for affected PHY revisions. This ensures reliable TX-to-RX termination detection across all operating temperature ranges. The fix applies to RK3562, RK3568, RK3576 and RK3588 SoCs which share the same PHY IP with this hardware errata. Fixes: 7160820d742a ("phy: rockchip: add naneng combo phy for RK3568") Fixes: f13bff25161b ("phy: rockchip-naneng-combo: Support rk3562") Fixes: ba8ad7eece66 ("phy: rockchip-naneng-combo: add rk3576 support") Fixes: a03c44277253 ("phy: rockchip: Add naneng combo phy support for RK3588") Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/1788158204-161347-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: Make sure clk_init_data is fully initializedGeert Uytterhoeven
The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://patch.msgid.link/adb5bd47343dd31661748d5de14cb28a2bae2d17.1787240165.git.geert+renesas@glider.be Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip-samsung-dcphy: Enable runtime PM at PHY core levelJason Yang
phy_create() only enables runtime PM on the new PHY device if the parent already has it enabled, and this driver enables it afterwards. The PHY device therefore never gets runtime PM, and phy_pm_runtime_get_sync() returns -ENOTSUPP for every phy_init() and phy_power_on(). The block is still resumed today, but only through the supplier link fw_devlink builds from the phys phandle, which fw_devlink=off and =permissive do not. Move devm_pm_runtime_enable() before devm_phy_create(), as done for the sibling HDPTX PHY in commit 10ba8479f460 ("phy: phy-rockchip-samsung-hdptx: Enable runtime PM at PHY core level"). Fixes: b2a1a2ae7818 ("phy: rockchip: Add Samsung MIPI D-/C-PHY driver") Signed-off-by: Jason Yang <jason98166@gmail.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patch.msgid.link/20260821-dcphy-rpm-v1-v1-1-a7db728b2539@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Only enable USB3 when not in high-speed modeSebastian Reichel
Ensure that USB3 mode is not accidently enabled during PHY re-init for systems that are configured as high-speed only via DT. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/message/20260626212424.C215E1F000E9%40smtp.kernel.org Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-11-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Handle rk_udphy_reset_deassert errorsSebastian Reichel
Handle rk_udphy_reset_deassert returning errors to avoid theoretical (Rockchip reset controller driver does not return errors) SError. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/message/20260626211151.2332F1F000E9%40smtp.kernel.org Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-10-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Avoid xHCI SErrorsSebastian Reichel
The USBDP PHY provides the PIPE clock to the USB3 controller, which means the PHY must be fully running when anything tries to access the xHCI registers. When switching between USB3-only, USB3 + DP and DP-only mode, the PHY must be re-initialized resulting in a short period of the PHY being disabled. If the DWC3 driver decides to access the xHCI at this point the system will fail with an SError. This patch avoids the problems by disabling the USB3 port before re-initializing it. This does a couple of things: - forces phystatus to 0 from GRF (not from PHY) - switches PIPE clock source from PHY to UTMI (safe fallback clock) - num_u3_port=0 The last part will be ignored, as DWC3 already probed, but the clock re-routing will avoid the SError. There is a small delay afterwards to make sure the mux happened. The datasheet gives no hints how long it takes, so delay time is a guess. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-9-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Add some extra debug messagesSebastian Reichel
It's useful to log PHY reinit to ease debugging issues around USB-C hotplugging. Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-8-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Hold mutex in DP PHY configureSebastian Reichel
rk_udphy_dp_phy_configure() accesses some variables from the struct rk_udphy, which are updated independently from the USB-C framework. The USB-C mux/orientation switch functions already hold a mutex to ensure mutual exclusive access to the struct rk_udphy states, so simply hold the same one in the DP PHY configuration function. Reproducing problems due to this on real hardware would be really hard, but could be possible when quickly re-connecting the USB-C connector. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-phy/20260612164627.23D391F000E9@smtp.kernel.org/ Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-7-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Use guard functions for mutexSebastian Reichel
Convert the driver to use guard functions for mutex handling as a small cleanup. There is a small functional change in the DP PHY power up function, which no longer sleeps if the internal powerup code returns an error. This is not a problem as the sleep is only relevant for successful power-up. Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-6-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USBSebastian Reichel
Handle TYPEC_STATE_SAFE and TYPEC_STATE_USB Type-C state events, so that the muxing is properly updated when exiting DP AltMode. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/message/20260619155020.CC7361F000E9%40smtp.kernel.org Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-5-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Factor out lane_mux_sel setupSebastian Reichel
Avoid describing the USB+DP lane_mux_sel logic twice by introducing a helper function to reduce code duplication. Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-4-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Re-init the PHY on orientation changeSebastian Reichel
Changing the cable orientation reconfigures the lane muxing, which requires re-initializing the PHY. Without this DP functionality breaks, if the cable is re-plugged with swapped orientation. Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-3-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Rename mode_change to phy_needs_reinitSebastian Reichel
Right now the mode_change property is set whenever the mode changes between USB-only, DP-only and USB-DP. It is needed, because on any mode change the PHY needs to be re-initialized. Apparently at least DP also requires a re-init when the cable orientation is changed, which is currently not being done (except when the orientation switch also involves a mode change). Prepare for this by renaming mode_change to phy_needs_reinit. Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-2-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Drop DP HPD handlingSebastian Reichel
Drop the HPD handling logic from the USBDP PHY. The registers involved require the display controller power domain being enabled and thus the HPD signal should be handled by the displayport controller itself. Apart from that the HPD handling as it is done here is incorrect and misses hotplug events happening after the USB-C connector (e.g. when a USB-C to HDMI adapter is involved and the HDMI cable is replugged). Proper USB-C DP HPD support requires some restructuring of the DP controller driver, which will happen independent of this patch. The mainline kernel does not yet support USB-C DP AltMode on RK3588 and RK3576, so it is fine to drop this code without adding the counterpart in the DRM in an atomic change. Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-part2-v15-1-8d507cb1174f@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Register DP aux bridgeSebastian Reichel
Add support to use USB-C connectors with the DP altmode helper code on devicetree based platforms. To get this working there must be a DRM bridge chain from the DisplayPort controller to the USB-C connector. E.g. on Rockchip RK3576: root@rk3576 # cat /sys/kernel/debug/dri/0/encoder-0/bridges bridge[0]: dw_dp_bridge_funcs refcount: 7 type: [10] DP OF: /soc/dp@27e40000:rockchip,rk3576-dp ops: [0x47] detect edid hpd bridge[1]: drm_aux_bridge_funcs refcount: 4 type: [0] Unknown OF: /soc/phy@2b010000:rockchip,rk3576-usbdp-phy ops: [0x0] bridge[2]: drm_aux_hpd_bridge_funcs refcount: 5 type: [10] DP OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector ops: [0x4] hpd Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-16-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Cleanup DP lane selection functionSebastian Reichel
Use FIELD_PREP_WM16() helpers to simplify the DP lane selection logic. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-15-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONSTSebastian Reichel
Cleanup code by replacing open-coded version of FIELD_PREP_WM16_CONST with the existing helper macro. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-14-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Rename DP lane functionsSebastian Reichel
The common prefix for DisplayPort related functions is rk_udphy_dp_ (with a final _), so update the two DP lane functions to follow that scheme. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-13-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Limit DP lane count to muxed lanesSebastian Reichel
In theory the DP controller could request 4 lanes when the PHY is restricted to 2 lanes as the other half is used by USB3. With the current user (DW-DP) this cannot happen, but as the check is cheap and users might change in the future protect things accordingly. Not doing so would corrupt USB3 usage by the following code configuring the voltages. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-phy/20260612165546.98E1F1F000E9@smtp.kernel.org/ Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://lore.kernel.org/linux-phy/20260612165546.98E1F1F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-12-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Support single-lane DPZhang Yubing
Implement support for using just a single DisplayPort line. Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-11-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Add missing mode_change updateSebastian Reichel
rk_udphy_set_typec_default_mapping() updates the available modes, but does not set the mode_change as required. This results in missing re-initialization and thus non-working DisplayPort. Fix this issue by introducing a new helper to update the available modes. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-10-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Fix LFPS detect threshold controlWilliam Wu
According to the LFPS Tx Low Power/LFPS Rx Detect Threshold [1], the device under test(DUT) must not respond if LFPS below the minimum LFPS Rx Detect Threshold 100mV. Test fail on Rockchip platforms, because the default LFPS detect threshold is set to 65mV. The USBDP PHY LFPS detect threshold voltage could be set to 30mV ~ 140mV, and since there could be 10-20% PVT variation, we set LFPS detect threshold voltage to 110mV. [1] https://compliance.usb.org/resources/LFPS_Rx_Tx_Low_Power_Compliance_Update_Rev5.pdf [Taken over from rockchip's kernel tree; the registers are not described in the TRM] Signed-off-by: William Wu <william.wu@rock-chips.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-9-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Amend SSC modulation deviationFrank Wang
Move SSC modulation deviation into private config of clock - 24M: 0x00d4[5:0] = 0x30 - 26M: 0x00d4[5:0] = 0x33 [Taken over from rockchip's kernel tree; register 0x00d4 is not described in the TRM] Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-8-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Keep clocks running on PHY re-initSebastian Reichel
When a mode change is required rk_udphy_power_on() disables the clocks and then calls rk_udphy_setup(), which then enables all the clocks again before continuing with rk_udphy_init(). Considering that rk_udphy_init() does assert the reset lines, re-enabling the clocks is just delaying things. Avoid it by directly calling rk_udphy_init(). Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-7-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Drop seamless DP takeoverSebastian Reichel
Right now the DRM drivers do not support seamless DP takeover and I'm I'm not aware of any bootloader implementing this feature either. In any case this feature would be limited to boards using the USBDP PHY for a DP or eDP connection instead of the more commonly USB-C connector. With USB-C's DP AltMode a seamless DP takeover requires handing over the state of the TCPM state machine from the bootloader to the kernel. This in turn requires a huge amount of work to keep the state machine implementations synchronized. It's very unlikely we will see somebody implementing that in the foreseeable future. As the current code is obviously buggy and untested, let's simply drop support for seamless DP takeover. It can be re-implemented cleanly once somebody adds all missing bits. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/ Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-6-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Handle missing clock-names DT property gracefullySebastian Reichel
The rk_udphy_clk_init() function would currently try to do a strncmp for a NULL pointer, if DT specifies 'clocks' property, but no 'clock-names' property. Fix this by making sure the clock has an id string set. Note that DT binding requires setting clock-names, so this is only a problem when booting a non-compliant device tree. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/message/20260619154349.071321F000E9%40smtp.kernel.org Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-5-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Fix devm_clk_bulk_get_all checkSebastian Reichel
If devm_clk_bulk_get_all() returns -EPROBE_DEFER, it is replaced with -ENODEV, permanently failing the driver probe instead of allowing it to defer. Avoid masking the error code to fix the issue. This effectively drops returning -ENODEV in case no clocks are being described in DT. This special case will now be handled by the follow-up check searching for "refclk" and exit with -EINVAL. None of this will be hit in practice, since the driver is only used by RK3588 and RK3576 - on these platforms the DT is validated to contain the clocks and the clock driver is force probed early. Thus there is no need to backport this. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/ Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-4-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Do not lose USB3 PHY statusSebastian Reichel
By default (i.e. without manually enabling runtime PM) DWC3 requests the USB3 PHY once and keeps it enabled all the time. When DisplayPort is being requested later on, a mode change is needed. This re-initializes the PHY. During re-initialization the status variable has incorrectly been cleared, which means the tracking information for USB3 is lost. This is not an immediate problem, since the DP side keeps the PHY enabled. But once DP is toggled off, the whole PHY will be disabled. This is a problem, because the USB side still needs it powered. Fix things by not clearing the status flags. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-3-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-03phy: rockchip: usbdp: Update mode_change after error handlingSebastian Reichel
If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be tried again. Fix this by only updating the variable after all potential errors have been handled. Note, that no errors have been seen on real hardware and failures would most likely be fatal and require at least a full reboot as the function already asserts the PHY reset lines. So this is more of a theoretical issue. Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/ Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260915-rockchip-usbdp-cleanup-v15-2-80e2c11d1ce8@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-24Merge tag 'phy-for-7.3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy updates from Vinod Koul: "As usual bunch of new device and driver support and updates to existing drivers and addition of Manivannan to help with reviews. New Support: - Mediatek MT8196 DSI PHY support - Renesas RZ/G3L usb2 support - Qualcomm SM8475 QMP USB PHY and PCIe phy, IPQ9650 QMP PCIe PHY, QUSB2 Phy for Shikra SoC, Hawi support for QMP PCIe phy and UFS PHY. Glymur QMP PCIe Multi-PHY driver and multiple link-mode support, ipq5210 PCIe phy support - Spacemit USB3/PCIe comb PHY driver Updates: - Samsung hdptx driver improvements for modernizing the register access and code cleanup - Qualcomm drop duplicate v8 DP headers, improved runtime handling for qmp drivers - Rockchip clock lane phase tuning and 2500 Mbps support and TMDS rate handling - Freescale imx8mq improvements for runtime pm, pd handling" * tag 'phy-for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (76 commits) MAINTAINERS: Add Manivannan Sadhasivam as the Reviewer for Generic PHY Framework phy: rockchip-samsung-dcphy: fix out-of-range max_register phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driver dt-bindings: phy: qcom: Add Glymur QMP PCIe multiple link-mode PHY phy: rockchip: samsung-hdptx: Consistently use bitfield macros phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16() phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling phy: rockchip: samsung-hdptx: Consolidate consumer_put on error path phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRL phy: rockchip: samsung-hdptx: Guard against clk rate integer underflow phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs phy: renesas: rcar-gen3-usb2: Ignore missing VBUS regulator phy: qcom: qmp-pcie: Add support for SM8475 Gen3x1 PCIe0 port phy: qcom: qmp-pcie: Add pcs_lane1 offset to V5 offsets dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add SM8475 QMP PHY ...
2026-08-18Merge tag 'v7.2' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 7.2
2026-08-11phy: rockchip-samsung-dcphy: fix out-of-range max_registerJason Yang
The PHY register block is 64KB, so with a register stride of 4 the last accessible register sits at offset 0xfffc. max_register names 0x10000, one register past the end of the mapping: dumping the registers through the regmap debugfs interface reads beyond the ioremapped region and oopses on the unmapped page. The oops fires with the regmap lock held, so later PHY operations deadlock. Fixes: b2a1a2ae7818 ("phy: rockchip: Add Samsung MIPI D-/C-PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Jason Yang <jason98166@gmail.com> Assisted-by: Claude:claude-opus-5 Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patch.msgid.link/20260811-dcphy-maxreg-v1-v1-1-aa63f6a63a64@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Consistently use bitfield macrosCristian Ciocaltea
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> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-10-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()Cristian Ciocaltea
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> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-9-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Drop restrict_rate_change handlingCristian Ciocaltea
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> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-8-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Consolidate consumer_put on error pathCristian Ciocaltea
rk_hdptx_phy_consumer_put() is invoked in both branches of the mode check conditional in rk_hdptx_phy_power_on() on the error path. Simplify the code by moving the single call to the end of the function. No functional change intended. Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-7-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaroundCristian Ciocaltea
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(). Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-6-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changesCristian Ciocaltea
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-related changes. 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> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-5-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRLCristian Ciocaltea
rk_hdptx_phy_clk_calc_rate_from_pll_cfg() is currently unable to handle cascade mode for the 3.2GHz FRL operating mode, as it relies solely on LCPLL_LCVCO_MODE_EN_MASK to determinate the rate from the rk_hdptx_frl_lcpll_cfg array. Since there is no entry for this particular rate, the function returns 0. This is the only rate which requires LC_REF_CLK_SEL to be set in GRF_HDPTX_CON0, hence extend the FRL matching accordingly. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support") Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-4-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Guard against clk rate integer underflowCristian Ciocaltea
The 'fout' subtraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could result in an integer underflow, if the hardware registers are misconfigured or contain uninitialized values, such that the computed sigma-delta modulator offset sdm exceeds the base frequency fout. This might lead to an absurdly high clock rate being returned to the Common Clock Framework, with unpredictable effects on downstream clk consumers. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260611235702.0E9691F000E9@smtp.kernel.org/ Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-3-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rateCristian Ciocaltea
Calculating 'sdm' fraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could trigger a divide-by-zero, as it uses div_u64() with a denominator read directly from hardware: the values ropll_hw.sdm_deno, ropll_hw.sdc_deno, ropll_hw.sdc_n, and ropll_hw.sdc_num are populated from PLL registers which, in theory, could be left by the bootloader uninitialized/misconfigured. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-2-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpcCristian Ciocaltea
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> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andyshrk@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-1-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: rockchip: inno-hdmi: Remove deprecated way to configure TMDS rateJonas Karlman
The TMDS character rate of this PHY is configured using PHY bus width in downstream vendor kernel and out-of-tree patches, however no in-tree consumer of this PHY has ever called phy_set_bus_width() to change the TMDS character rate as currently only 8-bit RGB output is supported by the HDMI display driver. The series "Split Generic PHY consumer and provider" clarifies that phy_set_bus_width() is intended as a provider-only function. Remove the deprecated unused fallback way to configure TMDS character rate now that this HDMI PHY support using phy_configure() to configure the TMDS character rate. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #rk3328 Tested-by: Diederik de Haas <diederik@cknow-tech.com> # Rock64 Link: https://patch.msgid.link/20260518180722.2480799-3-jonas@kwiboo.se Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: rockchip: inno-hdmi: Add configure() and validate() opsJonas Karlman
The commit 10ed34d6eaaf ("phy: Add HDMI configuration options") introduced a way for HDMI PHYs to be configured through the generic phy_configure() function. This driver derives the TMDS character rate from the pixel clock and the PHY bus width setting. However, no in-tree consumer of this PHY has ever called phy_set_bus_width() to change the TMDS character rate as only 8-bit RGB output is supported by the HDMI display driver. Add configure() and validate() ops to allow consumers to configure the TMDS character rate using phy_configure(). Fallback to the deprecated way of using the PHY bus width to configure the TMDS character rate. A typical call chain during DRM modeset on a RK3328 device: dw_hdmi_rockchip_encoder_atomic_check(): - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000 dw_hdmi_rockchip_encoder_atomic_mode_set(): - inno_hdmi_phy_configure(): pixclock 148500000 - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000 vop_crtc_atomic_enable(): - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000 inno_hdmi_phy_rk3328_clk_set_rate(): pixclock 594000000 tmdsclock 594000000 - inno_hdmi_phy_rk3328_clk_recalc_rate(): pixclock 594000000 vco 594000000 dw_hdmi_rockchip_encoder_enable(): - inno_hdmi_phy_power_on(): Inno HDMI PHY Power On - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000 Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #rk3328 Tested-by: Diederik de Haas <diederik@cknow-tech.com> # Rock64 Link: https://patch.msgid.link/20260518180722.2480799-2-jonas@kwiboo.se Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuningGerald Loacker
At high data rates like 4K60 (2500 Mbps), such as when using an LT6911GXD bridge chip on an RK3588 board, fixed default timing parameters can cause signal integrity issues and clock-data recovery failures. The driver currently lacks a mechanism to adjust the clock lane sampling phase to compensate for board-specific trace variations. Resolve this by parsing and applying the optional 'rockchip,clk-lane-phase' device tree property. This enables board-specific tuning of the clock lane sampling phase in ~40 ps steps (range 0-7) to optimize link stability. If the property is absent, the driver falls back to the hardware default. Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> Reviewed-by: Michael Riesch <michael.riesch@collabora.com> Link: https://patch.msgid.link/20260725-feature-mipi-csi-dphy-4k60-v4-3-5b2c4626d31e@wolfvision.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq tableGerald Loacker
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this rate. This is essential for RK3588 reusing this array and fully supporting rates up to 2500 Mbps. Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy") Reviewed-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> Link: https://patch.msgid.link/20260725-feature-mipi-csi-dphy-4k60-v4-1-5b2c4626d31e@wolfvision.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-02Merge tag 'phy-fixes-7.2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy fixes from Vinod Koul: - fixes for zynqmp clock and pm error handling and SERDES scrambler register handling - Rockchip SSC spread fix - Qualcomm musb return call fix * tag 'phy-fixes-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB phy: zynqmp: use read-modify-write for SERDES scrambler bypass phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask phy: zynqmp: fix runtime PM leak on probe allocation failure phy: zynqmp: fix clock error handling in xpsgtr_phy_init() phy: rockchip: naneng-combphy: Always configure SSC spread direction phy: qcom: m31-eusb2: Fix return value of init call