kernel/drivers/phy/cadence, branch linux-6.9.y

phy: cadence-torrent: Add USXGMII(156.25MHz) + SGMII/QSGMII(100MHz) multilink config for TI J7200

2024-02-07T14:02:13Z

Add a separate compatible and registers map table for TI J7200. TI J7200 uses Torrent SD0805 version which is a special version derived from Torrent SD0801 with some differences in register configurations. Add register sequences for USXGMII(156.25MHz) + SGMII/QSGMII(100MHz) multilink config for TI J7200. USXGMII uses PLL0 and SGMII/QSGMII uses PLL1. Signed-off-by: Swapnil Jakhade Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20240104133013.2911035-6-sjakhade@cadence.com Signed-off-by: Vinod Koul

phy: cadence-torrent: Add USXGMII(156.25MHz) + SGMII/QSGMII(100MHz) multilink configuration

2024-02-07T14:02:13Z

Add register sequences for USXGMII(156.25MHz) + SGMII/QSGMII(100MHz) multilink configuration. USXGMII uses PLL0 and SGMII/QSGMII uses PLL1. Signed-off-by: Swapnil Jakhade Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20240104133013.2911035-4-sjakhade@cadence.com Signed-off-by: Vinod Koul

phy: cadence-torrent: Add PCIe(100MHz) + USXGMII(156.25MHz) multilink configuration

2024-02-07T14:02:13Z

Torrent PHY can have separate input reference clocks for PLL0 and PLL1. Add support for dual reference clock multilink configurations. Add register sequences for PCIe(100MHz) + USXGMII(156.25MHz) multilink configuration. PCIe uses PLL0 and USXGMII uses PLL1. Signed-off-by: Swapnil Jakhade Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20240104133013.2911035-3-sjakhade@cadence.com Signed-off-by: Vinod Koul

phy: Explicitly include correct DT includes

2023-07-17T06:22:56Z

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Acked-by: Marc Kleine-Budde # for drivers/phy/phy-can-transceiver.c Acked-by: Heiko Stuebner Acked-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20230714174841.4061919-1-robh@kernel.org Signed-off-by: Vinod Koul

phy: cadence: Sierra: Add single link SGMII register configuration

2023-07-12T16:57:44Z

Add single link SGMII register configuration for no SSC for cdns,sierra-phy-t0 compatibility string. The configuration is based on Sierra Programmer's Guide and validated in Cisco CrayAR SoC. Co-developed-by: Bartosz Wawrzyniak Signed-off-by: Bartosz Wawrzyniak Signed-off-by: Marcin Wierzbicki Link: https://lore.kernel.org/r/20230626105533.2999966-1-mawierzb@cisco.com Signed-off-by: Vinod Koul

phy: cadence-torrent: Use key:value pair table for all settings

2023-07-12T16:57:40Z

Instead of a 3D matrix use a key:value pair table for link_cmn_vals, xcvr_diag_vals, pcs_cmn_vals, phy_pma_cmn_vals, cmn_vals, tx_ln_vals and rx_ln_vals. This makes it scaleable for multiple reference clocks. Wherever both CDNS and TI use the same settings, reuse the same data. Introduce CLK_ANY and ANY_SSC enums which are used if the setting is independent of clock rate or SSC type. Signed-off-by: Roger Quadros Signed-off-by: Swapnil Jakhade Link: https://lore.kernel.org/r/20230530143853.26571-3-sjakhade@cadence.com Signed-off-by: Vinod Koul

phy: cadence-torrent: Add single link USXGMII configuration for 156.25MHz refclk

2023-07-12T16:57:40Z

Add register sequences for single link USXGMII configuration supporting 156.25MHz reference clock frequency. Signed-off-by: Swapnil Jakhade Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20230530143853.26571-2-sjakhade@cadence.com Signed-off-by: Vinod Koul

Merge tag 'phy-for-6.5_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy

2023-07-06T04:38:13Z

Pull phy updates from Vinod Koul: "New Support: - Debugfs support for phy core and mediatek driver - Hisilicon inno-usb2-phy driver supporting Hi3798MV100 - Qualcomm SGMII SerDes PHY driver, SM6115 & QCM2290 QMP-USB support, SA8775P USB PHY & USB3 UNI support, QUSB2 support for IPQ9574, IPQ9574 USB3 PHY UpdatesL - Sparx5 serdes phy power optimzation - cadence salvo usb properties and updates and torrent DP with PCIe & USB support - Yaml conversion for Broadcom kona USB bindings and MXS USB binding" * tag 'phy-for-6.5_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (67 commits) dt-bindings: phy: brcm,brcmstb-usb-phy: Fix error in "compatible" conditional schema dt-bindings: phy: mixel,mipi-dsi-phy: Remove assigned-clock* properties dt-bindings: phy: intel,combo-phy: restrict node name suffixes dt-bindings: phy: qcom,usb-hs-phy: Add compatible phy: tegra: xusb: check return value of devm_kzalloc() phy: qcom: qmp-combo: fix Display Port PHY configuration for SM8550 phy: qcom: add the SGMII SerDes PHY driver dt-bindings: phy: describe the Qualcomm SGMII PHY phy: qualcomm: fix indentation in Makefile phy: usb: suppress OC condition for 7439b2 phy: usb: Turn off phy when port is in suspend phy: tegra: xusb: Clear the driver reference in usb-phy dev dt-bindings: phy: mxs-usb-phy: add imx8ulp and imx8qm compatible dt-bindings: phy: mxs-usb-phy: convert to DT schema format dt-bindings: phy: qcom,qmp-usb: fix bindings error dt-bindings: phy: qcom,qmp-ufs: fix the sc8180x regs dt-bindings: phy: qcom,qmp-pcie: fix the sc8180x regs phy: mediatek: tphy: add debugfs files phy: core: add debugfs files phy: fsl-imx8mp-usb: add support for phy tuning ...

phy: cadence: torrent: Add a determine_rate hook

2023-06-09T01:39:31Z

The Cadence Torrent refclk clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely. Cc: Kishon Vijay Abraham I Cc: Vinod Koul Cc: linux-phy@lists.infradead.org Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-42-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

phy: cadence: sierra: Add a determine_rate hook

2023-06-09T01:39:31Z

The Cadence Sierra PLL clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely. Cc: Kishon Vijay Abraham I Cc: Vinod Koul Cc: linux-phy@lists.infradead.org Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-41-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd