- 28 Oct, 2022 31 commits
-
-
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 <johan+linaro@kernel.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20221012085002.24099-16-johan+linaro@kernel.orgSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
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 9 commits
-
-
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:
-
Johan Hovold authored
Keep the clock lists together and sorted by symbol name. Reviewed-by:
-
Johan Hovold authored
Always define the POWER_DOWN_CONTROL register instead of falling back to the v2 (and v3) offset during power on and power off. Reviewed-by:
-
Johan Hovold authored
Always define the POWER_DOWN_CONTROL register instead of falling back to the v2 (and v4) offset during power on and power off. Reviewed-by:
-
Johan Hovold authored
Always define the POWER_DOWN_CONTROL register instead of falling back to the v2 (and v3) offset during power on and power off. Reviewed-by:
-
Johan Hovold authored
This driver uses v2 registers only so drop the unnecessary POWER_DOWN_CONTROL override. Note that this register is already hard-coded when powering on the PHY. Reviewed-by:
-
Johan Hovold authored
Move the power-down-control register update that powers on the PHY to the power-on handler so that it matches the power-off handler. Note that the power-on handler is currently always called directly after init. Reviewed-by:
-
Johan Hovold authored
Always define the POWER_DOWN_CONTROL register instead of falling back to the v2 offset during power on and power off. Reviewed-by:
-
Johan Hovold authored
Drop the common-block register defines that are unused since the QMP driver split. Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
-
