- 10 Feb, 2023 6 commits
-
-
Abel Vesa authored
The new SM8550 SoC bumps up the HW version of QMP phy to v6 for USB, UFS and PCIE g3x2. Add the new PCS PCIE specific offsets in a dedicated header file. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230208180020.2761766-5-abel.vesa@linaro.orgSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Abel Vesa authored
The new SM8550 SoC bumps up the HW version of QMP phy to v6.20 for PCIE g4x2. Add the new PCS offsets in a dedicated header file. Signed-off-by:
-
Abel Vesa authored
The new SM8550 SoC bumps up the HW version of QMP phy to v6 for USB, UFS and PCIE g3x2. Add the new PCS offsets in a dedicated header file. Signed-off-by:
-
Abel Vesa authored
Document the QMP PCIe PHY compatible for SM8550. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230208180020.2761766-2-abel.vesa@linaro.orgSigned-off-by:
-
Neil Armstrong authored
Copy the USB tables from the QMP USB3 PHY driver and add the missing DP tables from downstream to enable USB3/DP on the SM8350 and SM8450 platforms. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230206-topic-sm8350-upstream-usb-dp-combo-phy-v1-2-ed849ae6b849@linaro.orgSigned-off-by:
-
Neil Armstrong authored
Document the USB3/DP Combo PHY compatible found on the SM8350 & SM8450 SoCs. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230206-topic-sm8350-upstream-usb-dp-combo-phy-v1-1-ed849ae6b849@linaro.orgSigned-off-by:
-
- 03 Feb, 2023 11 commits
-
-
Stephen Boyd authored
Introduce a config option for each QMP PHY driver now that the QMP PHY mega-driver has been split up into different modules. This allows kernel configurators to limit the binary size of the kernel by only compiling in the QMP PHY driver that they need. Leave the old config QCOM_QMP in place and make it into a menuconfig so that 'make olddefconfig' continues to work. Furthermore, set the default of the new Kconfig symbols to be QCOM_QMP so that the transition is smooth. Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230202215330.2152726-1-swboyd@chromium.orgSigned-off-by:
-
Jon Hunter authored
Add the compatible string for the Tegra234 XUSB PHY. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Acked-by:
-
Vinod Koul authored
Merge tag phy-devm_of_phy_optional_get into next to bring in the new devm_of_phy_optional_get() API and users
-
Geert Uytterhoeven authored
Use the new devm_of_phy_optional_get() helper instead of open-coding the same operation. As devm_of_phy_optional_get() returns NULL if either the PHY cannot be found, or if support for the PHY framework is not enabled, it is no longer needed to check for -ENODEV or -ENOSYS. This lets us drop several checks for IS_ERR(), as phy_power_{on,off}() handle NULL parameters fine. Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/3adc5dd1149a17ea7daf4463549feab886c6b145.1674584626.git.geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
Use the new devm_of_phy_optional_get() helper instead of open-coding the same operation. As devm_of_phy_optional_get() returns NULL if either the PHY cannot be found, or if support for the PHY framework is not enabled, it is no longer needed to check for -ENODEV or -ENOSYS. This lets us drop several checks for IS_ERR(), as phy_power_{on,off}() handle NULL parameters fine. Signed-off-by: -
Geert Uytterhoeven authored
Use the new devm_of_phy_optional_get() helper instead of open-coding the same operation. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/56508eeadf7fa8692877e872871f10294d48c49d.1674584626.git.geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
Use the new devm_of_phy_optional_get() helper instead of open-coding the same operation. Signed-off-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/r/993b0f4ac5b84b2b72223011614d2e821f9e7302.1674584626.git.geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
Use the new devm_of_phy_optional_get() helper instead of open-coding the same operation. As devm_of_phy_optional_get() returns NULL if either the PHY cannot be found, or if support for the PHY framework is not enabled, it is no longer needed to check for -ENODEV or -ENOSYS. Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/f2d801cd73cca36a7162819289480d7fc91fcc7e.1674584626.git.geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
Add an optional variant of devm_of_phy_get() that also takes care of printing real errors, so drivers no longer have to open-code this operation. Signed-off-by:
-
Geert Uytterhoeven authored
Add the missing documentation for devm_of_phy_get(), which was forgotten when the function was introduced. Signed-off-by:
-
Geert Uytterhoeven authored
There were never any upstream users of this function since its introduction almost 10 years ago. Besides, the dummy for phy_optional_get() should have returned NULL instead of an error code. Signed-off-by:
-
- 02 Feb, 2023 9 commits
-
-
Luca Weiss authored
Add the tables and config for the combo phy found on SM6350. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Reviewed-by:
-
Luca Weiss authored
Add the compatible describing the combo phy found on SM6350. Reviewed-by:
-
Chunfeng Yun authored
Remove the temporary @mask_, this may cause build warning when use clang compiler for powerpc, but can't reproduce it when compile for arm64. the build warning is caused by: "warning: result of comparison of constant 18446744073709551615 with expression of type (aka 'unsigned long') is always false [-Wtautological-constant-out-of-range-compare]" More information provided in below lore link. After removing @mask_, there is a "CHECK:MACRO_ARG_REUSE" when run checkpatch.pl, but due to @mask is constant, no reuse problem will happen. Link: https://lore.kernel.org/lkml/202212160357.jJuesD8n-lkp@intel.com/t/ Fixes: 84513ecc ("phy: mediatek: fix build warning of FIELD_PREP()") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230118084343.26913-1-chunfeng.yun@mediatek.comSigned-off-by:
-
Abel Vesa authored
Add SM8550 specific register layout and table configs. Signed-off-by:
-
Abel Vesa authored
The new SM8550 SoC bumps up the HW version of QMP phy to v6 for USB, UFS and PCIE g3x2. Add the new PCS UFS specific offsets in a dedicated header file. Signed-off-by:
-
Abel Vesa authored
The new SM8550 SoC bumps up the HW version of QMP phy to v6 for USB, UFS and PCIE g3x2. Add the new qserdes TX RX but UFS specific offsets in a dedicated header file. Signed-off-by:
-
Abel Vesa authored
The new SM8550 SoC bumps up the HW version of QMP phy to v6 for USB, UFS and PCIE g3x2. Add the new qserdes TX RX offsets in a dedicated header file. Signed-off-by:
-
Abel Vesa authored
The new SM8550 SoC bumps up the HW version of QMP phy to v6 for USB, UFS and PCIE g3x2. Add the new qserdes com offsets in a dedicated header file. Signed-off-by:
-
Abel Vesa authored
Document the QMP UFS PHY compatible for SM8550. Signed-off-by:
-
- 31 Jan, 2023 1 commit
-
-
Geert Uytterhoeven authored
The NXP TJR1443 High-speed CAN transceiver with Sleep mode is a pin-compatible alternative for the TI TCAN1043. Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/0bfa1e4c43632e49c9512b4e7daa970545545dcf.1674037830.git.geert+renesas@glider.beSigned-off-by:
-
- 20 Jan, 2023 1 commit
-
-
Geert Uytterhoeven authored
The NXP TJR1443 High-speed CAN transceiver with Sleep mode is a pin-compatible alternative for the TI TCAN1043. Signed-off-by:
-
- 18 Jan, 2023 8 commits
-
-
Thierry Reding authored
Convert the Tegra XUSB pad controller bindings from free-form text format to json-schema. Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20230113150804.1272555-1-thierry.reding@gmail.comSigned-off-by:
-
Dmitry Baryshkov authored
The sdx64 uniphy gen3x1 PHY references the qmp_v4_usb3phy_regs_layout while the PHY itself uses v5 regs. While there are only minor differences between v4 and v5 regs and none of them concerns registers mentions in regs_layout, switch the PHY to use qmp_v5_usb3phy_regs_layout, to remove possible confusion. Fixes: 14d98d3b ("phy: qcom-qmp-usb: fix regs layout arrays") Signed-off-by:
-
Dmitry Baryshkov authored
The sm8450 gen3x1 PHY references the pciephy_v4_regs_layout while the PHY itself uses v5 regs. While there are only minor differences between v4 and v5 regs and none of them concerns registers mentions in regs_layout, switch the PHY to use pciephy_v5_regs_layout to remove possible confusion. Fixes: bbe207a1 ("phy: qcom-qmp-pcie: rename regs layout arrays") Signed-off-by:
-
Dmitry Baryshkov authored
Use symbolic names for the values inside reg layout arrays. New register names are added following the PCS register layout that is used by the particular PHY. Note: ipq8074 tables appear to use a mixture of v2 and v3 registers. This might need additional fixes. Signed-off-by:
-
Dmitry Baryshkov authored
The QPHY_PCS_LFPS_RXTERM_IRQ_STATUS register is not used, remove it from register layout. Signed-off-by:
-
Dmitry Baryshkov authored
All currently known QMP UFS PHYs have the same offsets for register sub-regions. Instead of using qmp_ufs_offsets_v5 for older generations of PHYs, rename the offsets struct instance to remove _v5 suffix. Signed-off-by:
-
Sinthu Raja authored
The WIZ acts as a wrapper for SerDes and has Lanes 0 and 2 reserved for USB for type-C lane swap if Lane 1 and Lane 3 are linked to the USB PHY that is integrated into the SerDes IP. The WIZ control register has to be configured to support this lane swap feature. The support for swapping lanes 2 and 3 is missing and therefore add support to configure the control register to swap between lanes 2 and 3 if PHY type is USB. Signed-off-by:
Sinthu Raja <sinthu.raja@ti.com> Reviewed-by:
Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230113150615.19375-3-sinthu.raja@ti.comSigned-off-by:
-
Sinthu Raja authored
It's possible that the Type-C plug orientation on the DIR line will be implemented through hardware design. In that situation, there won't be an external GPIO line available, but the driver still needs to address this since the DT won't use the typec-dir-gpios property. Add code to handle LN10 Type-C swap if typec-dir-gpios property is not specified in DT. Signed-off-by:
-
- 17 Jan, 2023 4 commits
-
-
Manivannan Sadhasivam authored
UFS PHY in SC8280XP SoC is capable of operating at HS G4 mode and the init sequence is compatible with SM8350. Hence, add the tbls_hs_g4 instance reusing the G4 init sequence of SM8350. Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20230114071009.88102-13-manivannan.sadhasivam@linaro.orgSigned-off-by:
-
Manivannan Sadhasivam authored
UFS PHY in SM8450 SoC is capable of operating at HS G4 mode and the init sequence is compatible with SM8350. Hence, add the tbls_hs_g4 instance reusing the G4 init sequence of SM8350. Reviewed-by:
-
Manivannan Sadhasivam authored
UFS PHY in SM8350 SoC is capable of operating at HS G4 mode. Hence, add the required register settings using the tables_hs_g4 struct instance. Reviewed-by:
-
Manivannan Sadhasivam authored
SM8350 default init sequence sets some PCS registers to HS G3, thereby disabling HS G4 mode. This has the effect on MPHY capability negotiation between the host and the device during link startup and causes the PA_MAXHSGEAR to G3 irrespective of device max gear. Due to that, the agreed gear speed determined by the UFS core will become G3 only and the platform won't run at G4. So, let's remove setting these registers for SM8350 as like other G4 compatible platforms. One downside of this is that, when the board design uses non-G4 compatible device, then MPHY will continue to run in the default mode (G4) even if UFSHCD runs in G3. But this is the case for other platforms as well. Tested-by: Andrew Halaney <ahalaney@redhat.com> # Qdrive3/sa8540p-ride Signed-off-by:
-
