- 12 Apr, 2024 6 commits
-
-
Sebastian Reichel authored
Add device tree binding document for Rockchip USBDP Combo PHY with Samsung IP block. Co-developed-by:
Frank Wang <frank.wang@rock-chips.com> Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20240408225109.128953-2-sebastian.reichel@collabora.comSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Daniel Golle authored
Add driver for MediaTek's XFI T-PHY which can be found in the MT7988 SoC. The XFI T-PHY is a 10 Gigabit/s Ethernet SerDes PHY with muxes on the internal side to be used with either USXGMII PCS or LynxI PCS, depending on the selected PHY interface mode. The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of PHY_INTERFACE_MODE_* corresponding to the supported modes: * USXGMII \ * 10GBase-R }- USXGMII PCS - XGDM \ * 5GBase-R / \ }- Ethernet MAC * 2500Base-X \ / * 1000Base-X }- LynxI PCS - GDM / * Cisco SGMII (MAC side) / I chose the name XFI T-PHY because names of functions dealing with the phy in the vendor driver are prefixed "xfi_pextp_". The register space used by the phy is called "pextp" in the vendor sources, which could be read as "_P_CI _ex_press _T_-_P_hy", and that is quite misleading as this phy isn't used for anything related to PCIe, so I wanted to find a better name. XFI is still somehow related (as in: you would find the relevant places using grep in the vendor driver when looking for that) and the term seemed to at least somehow be aligned with the function of that phy: Dealing with (up to) 10 Gbit/s Ethernet serialized differential signals. In order to work-around a performance issue present on the first of two XFI T-PHYs found in MT7988, special tuning is applied which can be selected by adding the 'mediatek,usxgmii-performance-errata' property to the device tree node, similar to how the vendor driver is doing that too. There is no documentation for most registers used for the analog/tuning part, however, most of the registers have been partially reverse-engineered from MediaTek's SDK implementation (see links, an opaque sequence of 32-bit register writes) and descriptions for all relevant digital registers and bits such as resets and muxes have been supplied by MediaTek. Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/b72d6cba92bf9e29fb035c03052fa1e86664a25b/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_sgmii.c Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/dec96a1d9b82cdcda4a56453fd0b453d4cab4b85/21.02/files/target/linux/mediatek/files-5.4/drivers/net/ethernet/mediatek/mtk_eth_soc.cSigned-off-by:Daniel Golle <daniel@makrotopia.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/8719c82634df7e8e984f1a608be3ba2f2d494fb4.1712625857.git.daniel@makrotopia.orgSigned-off-by:
-
Daniel Golle authored
Add bindings for the MediaTek XFI Ethernet SerDes T-PHY found in the MediaTek MT7988 SoC which can operate at various interfaces modes: via USXGMII PCS: * USXGMII * 10GBase-R * 5GBase-R via LynxI SGMII PCS: * 2500Base-X * 1000Base-X * Cisco SGMII (MAC side) Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240409161505.66619-2-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Neil Armstrong authored
Update the SM8650 UFS PHY init tables to support Gear 4 and Gear 5 using the overlays setup (only supported Gear 5 before), and sync back with the latest Qualcomm recommended values. The new recommended values allow a solid 50% bump in sequential read/write benchmarks on the SM8650 QRD & HDK reference boards. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240410-topic-sm8650-upstream-ufs-g5-v1-1-5527c44b37e6@linaro.orgSigned-off-by:
-
Vinod Koul authored
This brings rockchip,pcie3-phy changes into next which incoming patches are dependent on
-
- 07 Apr, 2024 1 commit
-
-
Gabor Juhos authored
According to the 'qcom,ipq5332-usb-hsphy.yaml' schema, the 5V supply regulator must be defined via the 'vdd-supply' property. The driver however requests for the 'vdda-phy' regulator which results in the following message when the driver is probed on a IPQ5018 based board with a device tree matching to the schema: qcom-m31usb-phy 5b000.phy: supply vdda-phy not found, using dummy regulator qcom-m31usb-phy 5b000.phy: Registered M31 USB phy This means that the regulator specified in the device tree never gets enabled. Change the driver to use the 'vdd' name for the regulator as per defined in the schema in order to ensure that the corresponding regulator gets enabled. Fixes: 08e49af5 ("phy: qcom: Introduce M31 USB PHY driver") Reviewed-by:
Varadarajan Narayanan <quic_varada@quicinc.com> Signed-off-by:
Gabor Juhos <j4g8y7@gmail.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240406-phy-qcom-m31-regulator-fix-v2-1-c8e9795bc071@gmail.comSigned-off-by:
-
- 06 Apr, 2024 13 commits
-
-
Stephen Boyd authored
The register base that was used to write to the QSERDES_DP_PHY_MODE register was 'dp_dp_phy' before commit 815891ee ("phy: qcom-qmp-combo: Introduce orientation variable"). There isn't any explanation in the commit why this is changed, so I suspect it was an oversight or happened while being extracted from some other series. Oddly the value being 0x4c or 0x5c doesn't seem to matter for me, so I suspect this is dead code, but that can be fixed in another patch. It's not good to write to the wrong register space, and maybe some other version of this phy relies on this. Cc: Douglas Anderson <dianders@chromium.org> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Abel Vesa <abel.vesa@linaro.org> Cc: Steev Klimaszewski <steev@kali.org> Cc: Johan Hovold <johan+linaro@kernel.org> Cc: Bjorn Andersson <quic_bjorande@quicinc.com> Cc: stable@vger.kernel.org # 6.5 Fixes: 815891ee ("phy: qcom-qmp-combo: Introduce orientation variable") Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240405000111.1450598-1-swboyd@chromium.orgSigned-off-by:
-
Stephen Boyd authored
Commit ec17373a ("phy: qcom: qmp-combo: extract common function to setup clocks") changed the offset that is used to write to DP_PHY_VCO_DIV from QSERDES_V3_DP_PHY_VCO_DIV to QSERDES_V4_DP_PHY_VCO_DIV. Unfortunately, this offset is different between v3 and v4 phys: #define QSERDES_V3_DP_PHY_VCO_DIV 0x064 #define QSERDES_V4_DP_PHY_VCO_DIV 0x070 meaning that we write the wrong register on v3 phys now. Add another generic register to 'regs' and use it here instead of a version specific define to fix this. This was discovered after Abhinav looked over register dumps with me from sc7180 Trogdor devices that started failing to light up the external display with v6.6 based kernels. It turns out that some monitors are very specific about their link clk frequency and if the default power on reset value is still there the monitor will show a blank screen or a garbled display. Other monitors are perfectly happy to get a bad clock signal. Cc: Douglas Anderson <dianders@chromium.org> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: ec17373a ("phy: qcom: qmp-combo: extract common function to setup clocks") Signed-off-by:
-
Sebastian Reichel authored
The pcie1l0_sel and pcie1l1_sel bits in PCIESEL_CON configure the mux for PCIe1L0 and PCIe1L1 to either the PIPE Combo PHYs or the PCIe3 PHY. Thus this configuration interfers with the data-lanes configuration done by the PCIe3 PHY. RK3588 has three Combo PHYs. The first one has a dedicated PCIe controller and is not affected by this. For the other two Combo PHYs, there is one mux for each of them. pcie1l0_sel selects if PCIe 1L0 is muxed to Combo PHY 1 when bit is set to 0 or to the PCIe3 PHY when bit is set to 1. pcie1l1_sel selects if PCIe 1L1 is muxed to Combo PHY 2 when bit is set to 0 or to the PCIe3 PHY when bit is set to 1. Currently the code always muxes 1L0 and 1L1 to the Combi PHYs once one of them is being used in PCIe mode. This is obviously wrong when at least one of the ports should be muxed to the PCIe3 PHY. Fix this by introducing Combo PHY identification and then only setting up the required bit. Fixes: a03c4427 ("phy: rockchip: Add naneng combo phy support for RK3588") Reported-by:
Michal Tomek <mtdev79b@gmail.com> Signed-off-by:
-
Sebastian Reichel authored
Currently the PCIe v3 PHY driver only sets the pcie1ln_sel bits, but does not clear them because of an incorrect write mask. This fixes up the issue by using a newly introduced constant for the write mask. While at it also introduces a proper GENMASK based constant for the PCIE30_PHY_MODE. Fixes: 2e9bffc4 ("phy: rockchip: Support PCIe v3") Signed-off-by:
-
Michal Tomek authored
So far all RK3588 boards use fully aggregated PCIe. CM3588 is one of the few boards using this feature and apparently it is broken. The PHY offers the following mapping options: port 0 lane 0 - always mapped to controller 0 (4L) port 0 lane 1 - to controller 0 or 2 (1L0) port 1 lane 0 - to controller 0 or 1 (2L) port 1 lane 1 - to controller 0, 1 or 3 (1L1) The data-lanes DT property maps these as follows: 0 = no controller (unsupported by the HW) 1 = 4L 2 = 2L 3 = 1L0 4 = 1L1 That allows the following configurations with first column being the mainline data-lane mapping, second column being the downstream name, third column being PCIE3PHY_GRF_CMN_CON0 and PHP_GRF_PCIESEL register values and final column being the user visible lane setup: <1 1 1 1> = AGGREG = [4 0] = x4 (aggregation) <1 1 2 2> = NANBNB = [0 0] = x2 x2 (no bif.) <1 3 2 2> = NANBBI = [1 1] = x2 x1x1 (bif. of port 0) <1 1 2 4> = NABINB = [2 2] = x1x1 x2 (bif. of port 1) <1 3 2 4> = NABIBI = [3 3] = x1x1 x1x1 (bif. of both ports) The driver currently does not program PHP_GRF_PCIESEL correctly, which is fixed by this patch. As a side-effect the new logic is much simpler than the old logic. Fixes: 2e9bffc4 ("phy: rockchip: Support PCIe v3") Signed-off-by:
-
Peter Griffin authored
Add the newly created ufs phy for GS101 to MAINTAINERS. Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20240404122559.898930-18-peter.griffin@linaro.orgSigned-off-by:
-
Peter Griffin authored
Add the m-phy tuning values for gs101 UFS phy and SoC callbacks gs101_phy_wait_for_calibration() and gs101_phy_wait_for_cdr_lock(). Signed-off-by:
-
Peter Griffin authored
Some SoCs like gs101 don't fit in well with the existing pll lock and clock data recovery (CDR) callback used by existing exynos platforms. Allow SoCs to specifify and implement their own calibration and CDR functions that can be called by the generic samsung phy code. Signed-off-by:
-
Peter Griffin authored
This allows us to obtain a PMU regmap that is created by the exynos-pmu driver. Platforms such as gs101 require exynos-pmu created regmap to issue SMC calls for PMU register accesses. Existing platforms still get a MMIO regmap as before. Signed-off-by:
André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20240404122559.898930-10-peter.griffin@linaro.orgSigned-off-by:
-
Peter Griffin authored
Update dt schema to include the gs101 ufs phy compatible. Signed-off-by:
-
Danila Tikhonov authored
QMP UFS PHY used in SC7180 requires 3 clocks: * ref - 19.2MHz reference clock from RPMh * ref_aux - Auxiliary reference clock from GCC * qref - QREF clock from GCC This change obviously breaks the ABI, but it is inevitable since the clock topology needs to be accurately described in the binding. Signed-off-by:
Danila Tikhonov <danila@jiaxyga.com> Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20240401182240.55282-2-danila@jiaxyga.comSigned-off-by:
-
Marcel Ziswiler authored
Leaving AUX_PLL_REFCLK_SEL at its reset default of AUX_IN (PLL clock) proves to be more stable on the i.MX 8M Mini. Fixes: 1aa97b00 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver") Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by:
Richard Zhu <hongxing.zhu@nxp.com> Link: https://lore.kernel.org/r/20240322130646.1016630-2-marcel@ziswiler.comSigned-off-by:
-
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the phy_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
"Ricardo B. Marliere" <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240305-class_cleanup-phy-v1-1-106013a644dc@marliere.netSigned-off-by:
-
- 05 Apr, 2024 9 commits
-
-
Neil Armstrong authored
The PCIe Gen4x2 PHY found in the SM8[456]50 SoCs have a second clock, enable this second clock by setting the proper 20MHz hardware rate in the Gen4x2 SM8[456]50 aux_clock_rate config fields. Reviewed-by:
-
Neil Armstrong authored
The PCIe Gen4x2 PHY found in the SM8[456]50 SoCs have a second clock, add the code to register it for PHYs configs that sets a aux_clock_rate. In order to get the right clock, add qmp_pcie_clk_hw_get() which uses the newly introduced QMP_PCIE_PIPE_CLK & QMP_PCIE_PHY_AUX_CLK clock IDs and also supports the legacy bindings by returning the PIPE clock when #clock-cells=0. Signed-off-by:
-
Neil Armstrong authored
The PCIe Gen4x2 PHY found in the SM8[456]50 SoCs have a second clock, in order to expose it, split the current clock registering in two parts: - CCF clock registering - DT clock registering Keep the of_clk_add_hw_provider/devm_add_action_or_reset to keep compatibility with the legacy subnode bindings. Signed-off-by:
-
Neil Armstrong authored
The PCIe Gen4x2 PHY found in the SM8[456]50 SoCs have a second clock named "PHY_AUX_CLK" which is an input of the Global Clock Controller (GCC) which is muxed & gated then returned to the PHY as an input. Document the clock IDs to select the PIPE clock or the AUX clock, also enforce a second clock-output-names and a #clock-cells value of 1 for the PCIe Gen4x2 PHY found in the SM8[456]50 SoCs. Reviewed-by:
-
Mikhail Kobuk authored
Replace hardcoded 'gbe_phy_init' array size by explicit one. Fixes: 93433708 ("phy: marvell: phy-mvebu-a3700-comphy: Add native kernel implementation") Signed-off-by:
Mikhail Kobuk <m.kobuk@ispras.ru> Link: https://lore.kernel.org/r/20240321164734.49273-2-m.kobuk@ispras.ruSigned-off-by:
-
Mikhail Kobuk authored
There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr' every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'. Make sure 'gbe_phy_init[addr]' is used when all elements of 'gbe_phy_init_fix' array are handled. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 93433708 ("phy: marvell: phy-mvebu-a3700-comphy: Add native kernel implementation") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20240321164734.49273-1-m.kobuk@ispras.ruSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/57a3338a1cec683ac84d48e00dbf197e15ee5481.1709886922.git.u.kleine-koenig@pengutronix.deSigned-off-by:
-
Rick Wertenbroek authored
Several functions had "rochchip" instead of "rockchip" in their name. Replace "rochchip" by "rockchip". Signed-off-By:
Rick Wertenbroek <rick.wertenbroek@gmail.com> Reviewed-by:
-
Neil Armstrong authored
The QMP USB3/DP PHY found in the SM8650 SoC requires a slightly different Voltage Swing table for HBR/RBR link speeds. Add a new hbr/rbr voltage switch table named "v6" used in a new sm8650 qmp_phy_cfg struct replacing the sm8550 fallback used for the sm8650 compatible. Fixes: 80c1afe8 ("phy: qcom: qmp-combo: add QMP USB3/DP PHY tables for SM8650") Signed-off-by:
-
- 29 Mar, 2024 2 commits
-
-
Danila Tikhonov authored
Add the tables and constants for init sequences for UFS QMP phy found in SM8475 SoC. Signed-off-by:
-
Danila Tikhonov authored
Document the QMP UFS PHY compatible for SM8475. Signed-off-by:
-
- 28 Mar, 2024 9 commits
-
-
Neil Armstrong authored
Remove duplicate "return 0" in qmp_v4_configure_dp_phy() Fixes: 186ad90a ("phy: qcom: qmp-combo: reuse register layouts for even more registers") Signed-off-by:
-
Abel Vesa authored
Add v6 HW support by implementing the version ops. Add the X1E80100 compatible and match config as it is v6. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
-
Abel Vesa authored
In order to support different HW versions move everything specific to v4 into so-called version ops. Signed-off-by:
-
Abel Vesa authored
The Qualcomm X1E80100 platform has multiple PHYs that can work in both eDP or DP mode, so document their compatible. Signed-off-by:
-
Abel Vesa authored
The SMB2360 PMICs contain the same repeater as the PM8550B, but requiring different settings, so add dedicated compatible for SMB2360. Reviewed-by:
-
Abel Vesa authored
Add a dt-bindings compatible string for the Qualcomm's SMB2360 PMIC. Acked-by:
-
Vinod Koul authored
phy_dp_modes_6.10 This contains the dp submode definition and associated qcom driver change
-
Abel Vesa authored
Future platforms should not use different compatibles to differentiate between eDP and DP mode. Instead, they should use a single compatible as the IP block is the same. It will be the job of the controller to set the submode of the PHY accordingly. The existing platforms will remain with separate compatibles for each mode. Signed-off-by:
-
Abel Vesa authored
In some cases, a DP PHY needs to be configured to work in eDP mode. So add submodes for both DP and eDP so they can be used by the controllers for specifying the mode the PHY should be configured in. Signed-off-by:
-
