- 28 Oct, 2022 39 commits
-
-
Johan Hovold authored
Since the QMP driver split there will be at most a single child node so drop the obsolete iteration construct. While at it, drop the verbose error logging that would have been printed also on probe deferrals. Note that there's no need to check if there are additional child nodes (the kernel is not a devicetree validator), but let's return an error if there are no child nodes at all for now. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20221024090041.19574-4-johan+linaro@kernel.orgSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Johan Hovold authored
The UFS QMP PHY driver only manages a single PHY so merge the old qcom_qmp and qmp_phy structures and drop the PHY array. Signed-off-by:
-
Johan Hovold authored
Move the device-id table below probe() and next to the driver structure to keep the driver callback functions grouped together. Signed-off-by:
-
Dmitry Baryshkov authored
According to the kernel 4.4 sources from NHSS.QSDK.9.0.2 and according to hardware docs, the PHY registers layout used for IPQ8074 USB3 PHY is incorrect. This platform uses offset 0x174 for the PCS_STATUS register, 0xd8 for PCS_AUTONOMOUS_MODE_CTRL, etc. Correct the PHY registers layout. Fixes: 94a407cc ("phy: qcom-qmp: create copies of QMP PHY driver") Fixes: 507156f5 ("phy: qcom-qmp: Add USB QMP PHY support for IPQ8074") Signed-off-by:
-
Johan Hovold authored
Drop the start and pwrdn-ctrl abstractions which are no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
Drop the start and pwrdn-ctrl abstractions which are no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
Drop the start and pwrdn-ctrl abstractions which are no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
The driver expects every configuration to set the pwrdn_ctrl and phy_status masks. Add some probe WARN_ON_ONCE() to probe to catch any new driver support that fails to provide them. Signed-off-by:
-
Johan Hovold authored
All PCIe PHYs need to start and stop the SerDes and PCS so drop the start-ctrl abstraction which is no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
All USB PHYs need to start and stop the SerDes and PCS so drop the start-ctrl abstraction which is no longer needed since the QMP driver split. Similarly, drop the pwrdn-ctrl abstraction which also is not needed since the split. Signed-off-by:
-
Johan Hovold authored
It typically takes between one and two milliseconds for the PHY to become ready after starting it. Increase the tight 3--10 us polling period to the more reasonable 51--200 us. Signed-off-by:
-
Johan Hovold authored
Clean up the PHY status polling by dropping the configuration mask which is no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
It typically takes between one and two milliseconds for the PHY to become ready after starting it. Increase the tight 3--10 us polling period to the more reasonable 51--200 us. Signed-off-by:
-
Johan Hovold authored
Clean up the PHY ready polling by dropping the mask variables which are no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
Drop the unused phy-status configuration mask which has never been used for UFS PHYs. Signed-off-by:
-
Johan Hovold authored
It typically takes between one and two milliseconds for the PHY to become ready after starting it. Increase the tight 3--10 us polling period to the more reasonable 51--200 us. Signed-off-by:
-
Johan Hovold authored
Clean up the PHY status polling by dropping the configuration mask which is no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
It typically takes between one and two milliseconds for the PHY to become ready after starting it. Increase the tight 3--10 us polling period to the more reasonable 51--200 us. Signed-off-by:
-
Johan Hovold authored
Clean up the PHY ready and status polling by dropping the configuration masks which are no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
It typically takes between one and two milliseconds for the PHY to become ready after starting it. Increase the tight 3--10 us polling period to the more reasonable 51--200 us. Signed-off-by:
-
Johan Hovold authored
Clean up the status polling by dropping the ready bit mask which is no longer needed since the QMP driver split. Signed-off-by:
-
Johan Hovold authored
The phy_status mask was never set for IPQ6018 which meant that the driver would not wait for the PHY to be initialised during power-on and would never detect PHY initialisation timeouts. Fixes: 520264db ("phy: qcom-qmp: add QMP V2 PCIe PHY support for ipq60xx") Signed-off-by:
-
Johan Hovold authored
The phy_status mask was never set for IPQ8074 (gen3) which meant that the driver would not wait for the PHY to be initialised during power-on and would never detect PHY initialisation timeouts. Fixes: 334fad18 ("phy: qcom-qmp-pcie: add IPQ8074 PCIe Gen3 QMP PHY support") Signed-off-by:
-
Johan Hovold authored
The phy_status mask was never set for SC8180X which meant that the driver would not wait for the PHY to be initialised during power-on and would never detect PHY initialisation timeouts. Fixes: f839f14e ("phy: qcom-qmp: Add sc8180x PCIe support") Signed-off-by:
-
Vidya Sagar authored
Set ENABLE_L2_EXIT_RATE_CHANGE register bit to request UPHY PLL rate change to Gen1 during initialization. This helps in the below surprise link down cases, - Surprise link down happens at Gen3/Gen4 link speed. - Surprise link down happens and external REFCLK is cut off, which causes UPHY PLL rate to deviate to an invalid rate. Signed-off-by:
Vidya Sagar <vidyas@nvidia.com> Link: https://lore.kernel.org/r/20221013183854.21087-9-vidyas@nvidia.comSigned-off-by:
-
Johan Hovold authored
The power-down delay was included in the first version of the QMP driver as an optional delay after powering on the PHY (using POWER_DOWN_CONTROL) and just before starting it. Later changes modified this sequence by powering on before initialising the PHY, but the optional delay stayed where it was (i.e. before starting the PHY). The vendor driver does not use a delay before starting the PHY and this is likely not needed on any platform unless there is a corresponding delay in the vendor kernel init sequence tables (i.e. in devicetree). Let's keep the delay for now, but drop the redundant delay period configuration while increasing the unnecessarily low timer slack somewhat. Reviewed-by:
-
Johan Hovold authored
The SC8280XP PHY does not need a delay before starting the PHY (which is what the has_pwrdn_delay config option really controls) so drop the unnecessary delay. Signed-off-by:
-
Johan Hovold authored
The power-down delay was included in the first version of the QMP driver as an optional delay after powering on the PHY (using POWER_DOWN_CONTROL) and just before starting it. Later changes modified this sequence by powering on before initialising the PHY, but the optional delay stayed where it was (i.e. before starting the PHY). The vendor driver does not use a delay before starting the PHY and this is likely not needed on any platform unless there is a corresponding delay in the vendor kernel init sequence tables (i.e. in devicetree). Let's keep the delay for now, but drop the redundant delay period configuration while increasing the unnecessarily low timer slack somewhat. Reviewed-by:
-
Johan Hovold authored
The SC8280XP combo PHY does not need a delay before starting the USB PHY (which is what the has_pwrdn_delay config option really controls) so drop the unnecessary delay. Signed-off-by:
-
Johan Hovold authored
The power-down delay was included in the first version of the QMP driver for MSM8996 as an optional delay after powering on the PHY (using POWER_DOWN_CONTROL) and just before starting it. Later changes modified this sequence by powering on before initialising the PHY, but the optional delay stayed where it was (i.e. before starting the PHY). The vendor driver does not use a delay before starting the PHY and this is likely not needed on any platform unless there is a corresponding delay in the vendor kernel init sequence tables (i.e. in devicetree). Let's keep the delay for now, but drop the redundant configuration options while increasing the unnecessarily low timer slack somewhat. Reviewed-by:
-
Johan Hovold authored
The power-down delay was included in the first version of the QMP driver as an optional delay after powering on the PHY (using POWER_DOWN_CONTROL) and just before starting it. Later changes modified this sequence by powering on before initialising the PHY, but the optional delay stayed where it was (i.e. before starting the PHY). The vendor driver does not use a delay before starting the PHY and this is likely not needed on any platform unless there is a corresponding delay in the vendor kernel init sequence tables (i.e. in devicetree). But as the vendor kernel do have a 1 ms delay *after* starting the PHY and before starting to poll the status it is possible that later contributors have simply not noticed that the mainline power-down delay is not equivalent. As the current delay before even starting the PHY is pretty much pointless and likely a mistake, move the delay after starting the PHY which avoids a few iterations of polling and speeds up startup by 1 ms (the poll loop otherwise takes about 1.8 ms). Note that MSM8998 has never used a power-down delay so add a flag to skip the delay in case starting the PHY is faster on MSM8998. This can be removed after someone takes a measurement. Signed-off-by:
-
Johan Hovold authored
The power-down delay was included in the first version of the QMP driver as an optional delay after powering on the PHY (using POWER_DOWN_CONTROL) and just before starting it. Later changes modified this sequence by powering on before initialising the PHY, but the optional delay stayed where it was (i.e. before starting the PHY). The vendor driver does not use a delay before starting the PHY and this is likely not needed on any platform unless there is a corresponding delay in the vendor kernel init sequence tables (i.e. in devicetree). Let's keep the delay for now, but drop the redundant delay period configuration while increasing the unnecessarily low timer slack somewhat. Reviewed-by:
-
Johan Hovold authored
The QMP USB PHY driver does not use the "in-layout" configuration macro to configure registers that are typically accessed using "regs_layout" arrays (e.g. QPHY_START_CTRL) so drop this unused feature. Signed-off-by:
-
Johan Hovold authored
The QMP UFS PHY driver does not use the "in-layout" configuration macro to configure registers that are typically accessed using "regs_layout" arrays (e.g. QPHY_START_CTRL) so drop this unused feature. Reviewed-by:
-
Johan Hovold authored
The MSM8996 QMP PCIe PHY driver no longer uses the "in-layout" configuration macro to configure registers that are typically accessed using "regs_layout" arrays (e.g. QPHY_START_CTRL) so drop this unused feature. Reviewed-by:
-
Johan Hovold authored
The PCS initialisation table for IPQ8074 includes updates of the reset and start-control registers which is already handled explicitly by the driver during power on. Drop the redundant register write from the IPQ8074 configuration table and along with it the now unused "in-layout" configuration macro and code. Reviewed-by:
-
Johan Hovold authored
The QMP combo PHY driver does not use the "in-layout" configuration macro to configure registers that are typically accessed using "regs_layout" arrays (e.g. QPHY_START_CTRL) so drop this unused feature. Reviewed-by:
-
Johan Hovold authored
Drop some unnecessary or incorrect comments. Reviewed-by:
-
Johan Hovold authored
Regulator core already logs an error message in case requesting a regulator fails so drop the mostly redundant error message from probe. Reviewed-by:
-
- 17 Oct, 2022 1 commit
-
-
Johan Hovold authored
Since commit 0d58280c ("phy: Update PHY power control sequence") the PHY is powered on before configuring the registers and only the MSM8996 PCIe PHY, which includes the POWER_DOWN_CONTROL register in its PCS initialisation table, may possibly require a second update afterwards. To make things worse, the POWER_DOWN_CONTROL register lies at a different offset on more recent SoCs so that the second update, which still used a hard-coded offset, would write to an unrelated register (e.g. a revision-id register on SC8280XP). As the MSM8996 PCIe PHY is now handled by a separate driver, simply drop the bogus register update. Fixes: e4d8b05a ("phy: qcom-qmp: Use proper PWRDOWN offset for sm8150 USB") added support Reviewed-by:
-
