linux-stable.git/drivers/phy/qualcomm, branch v6.5.2

phy: qcom-snps-femto-v2: use qcom_snps_hsphy_suspend/resume error code

2023-07-12T16:57:03+00:00

The return value from qcom_snps_hsphy_suspend/resume is not used. Make
sure qcom_snps_hsphy_runtime_suspend/resume return this value as well.

Signed-off-by: Adrien Thierry 
Link: https://lore.kernel.org/r/20230629144542.14906-4-athierry@redhat.com
Signed-off-by: Vinod Koul

phy: qcom-snps-femto-v2: properly enable ref clock

2023-07-12T16:57:02+00:00

The driver is not enabling the ref clock, which thus gets disabled by
the clk_disable_unused() initcall. This leads to the dwc3 controller
failing to initialize if probed after clk_disable_unused() is called,
for instance when the driver is built as a module.

To fix this, switch to the clk_bulk API to handle both cfg_ahb and ref
clocks at the proper places.

Note that the cfg_ahb clock is currently not used by any device tree
instantiation of the PHY. Work needs to be done separately to fix this.

Link: https://lore.kernel.org/linux-arm-msm/ZEqvy+khHeTkC2hf@fedora/
Fixes: 51e8114f80d0 ("phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs")
Signed-off-by: Adrien Thierry 
Link: https://lore.kernel.org/r/20230629144542.14906-3-athierry@redhat.com
Signed-off-by: Vinod Koul

phy: qcom-snps-femto-v2: keep cfg_ahb_clk enabled during runtime suspend

2023-07-12T16:57:02+00:00

In the dwc3 core, both system and runtime suspend end up calling
dwc3_suspend_common(). From there, what happens for the PHYs depends on
the USB mode and whether the controller is entering system or runtime
suspend.

HOST mode:
  (1) system suspend on a non-wakeup-capable controller

  The [1] if branch is taken. dwc3_core_exit() is called, which ends up
  calling phy_power_off() and phy_exit(). Those two functions decrease the
  PM runtime count at some point, so they will trigger the PHY runtime
  sleep (assuming the count is right).

  (2) runtime suspend / system suspend on a wakeup-capable controller

  The [1] branch is not taken. dwc3_suspend_common() calls
  phy_pm_runtime_put_sync(). Assuming the ref count is right, the PHY
  runtime suspend op is called.

DEVICE mode:
  dwc3_core_exit() is called on both runtime and system sleep
  unless the controller is already runtime suspended.

OTG mode:
  (1) system suspend : dwc3_core_exit() is called

  (2) runtime suspend : do nothing

In host mode, the code seems to make a distinction between 1) runtime
sleep / system sleep for wakeup-capable controller, and 2) system sleep
for non-wakeup-capable controller, where phy_power_off() and phy_exit()
are only called for the latter. This suggests the PHY is not supposed to
be in a fully powered-off state for runtime sleep and system sleep for
wakeup-capable controller.

Moreover, downstream, cfg_ahb_clk only gets disabled for system suspend.
The clocks are disabled by phy->set_suspend() [2] which is only called
in the system sleep path through dwc3_core_exit() [3].

With that in mind, don't disable the clocks during the femto PHY runtime
suspend callback. The clocks will only be disabled during system suspend
for non-wakeup-capable controllers, through dwc3_core_exit().

[1] https://elixir.bootlin.com/linux/v6.4/source/drivers/usb/dwc3/core.c#L1988
[2] https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/LV.AU.1.2.1.r2-05300-gen3meta.0/drivers/usb/phy/phy-msm-snps-hs.c#L524
[3] https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/LV.AU.1.2.1.r2-05300-gen3meta.0/drivers/usb/dwc3/core.c#L1915

Signed-off-by: Adrien Thierry 
Link: https://lore.kernel.org/r/20230629144542.14906-2-athierry@redhat.com
Signed-off-by: Vinod Koul

phy: qcom: qmp-combo: fix Display Port PHY configuration for SM8550

2023-06-21T12:16:35+00:00

The SM8550 PHY also uses a different offset for the CMN_STATUS reg,
use the right one for the v6 Display Port configuration.

Fixes: 49742e9edab3 ("phy: qcom-qmp-combo: Add support for SM8550")
Signed-off-by: Neil Armstrong 
Reviewed-by: Konrad Dybcio 
Link: https://lore.kernel.org/r/20230601-topic-sm8550-upstream-dp-phy-init-fix-v1-1-4e9da9f97991@linaro.org
Signed-off-by: Vinod Koul

phy: qcom: add the SGMII SerDes PHY driver

2023-06-21T12:15:10+00:00

Implement support for the SGMII/SerDes PHY present on various Qualcomm
platforms.

Signed-off-by: Bartosz Golaszewski 
Link: https://lore.kernel.org/r/20230619091336.194914-4-brgl@bgdev.pl
Signed-off-by: Vinod Koul

phy: qualcomm: fix indentation in Makefile

2023-06-21T12:15:10+00:00

Align all entries in Makefile.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Andrew Halaney 
Link: https://lore.kernel.org/r/20230619091336.194914-2-brgl@bgdev.pl
Signed-off-by: Vinod Koul

phy: qcom-qmp-combo: Introduce drm_bridge

2023-05-19T17:47:19+00:00

The QMP combo PHY sits in an of_graph connected between the DisplayPort
controller and a USB Type-C connector (or possibly a redriver).

The TCPM needs to be able to convey the HPD signal to the DisplayPort
controller, but no directly link is provided by DeviceTree so the signal
needs to "pass through" the QMP combo phy.

Handle this by introducing a drm_bridge which upon initialization finds
the next bridge (i.e. the usb-c-connector) and chain this together. This
way HPD changes in the connector will propagate to the DisplayPort
driver.

The connector bridge is resolved lazily, as the TCPM is expected to be
able to resolve the typec mux and switch at probe time, so the QMP combo
phy will probe before the TCPM.

Acked-by: Neil Armstrong 
Tested-by: Bryan O'Donoghue 
Reviewed-by: Bryan O'Donoghue 
Tested-by: Abel Vesa 
Tested-by: Steev Klimaszewski 
Tested-by: Neil Armstrong  # on HDK8450
Tested-by: Johan Hovold 	# X13s
Reviewed-by: Johan Hovold 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20230515032743.400170-7-quic_bjorande@quicinc.com
Signed-off-by: Vinod Koul

phy: qcom-qmp-combo: Introduce orientation switching

2023-05-19T17:47:19+00:00

The data lanes of the QMP PHY is swapped in order to handle changing
orientation of the USB Type-C cable. Register a typec_switch device to
allow a TCPM to configure the orientation.

The newly introduced orientation variable is adjusted based on the
request, and the initialized components are brought down and up again.
To keep track of what parts needs to be cycled new variables to keep
track of the individual init_count is introduced.

Both the USB and the DisplayPort altmode signals are properly switched.
For DisplayPort the controller will after the TCPM having established
orientation power on the PHY, so this is not done implicitly, but for
USB the PHY typically is kept initialized across the switch, and must
therefore then be reinitialized.

This is based on initial work by Wesley Cheng.

Link: https://lore.kernel.org/r/20201009082843.28503-3-wcheng@codeaurora.org/
Reviewed-by: Johan Hovold 
Reviewed-by: Neil Armstrong 
Tested-by: Abel Vesa 
Tested-by: Steev Klimaszewski 
Tested-by: Neil Armstrong  # on HDK8450
Tested-by: Johan Hovold 	# X13s
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20230515032743.400170-6-quic_bjorande@quicinc.com
Signed-off-by: Vinod Koul

phy: qcom-qmp-combo: Introduce orientation variable

2023-05-19T17:47:19+00:00

In multiple places throughout the driver code has been written in
prepration for handling of orientation switching.

Introduce a typec_orientation in qmp_combo and fill out the various
"placeholders" with the associated logic. By initializing the
orientation to "normal" this change has no functional impact, but
reduces the size of the upcoming introduction of dynamic orientation
switching.

Reviewed-by: Neil Armstrong 
Tested-by: Abel Vesa 
Tested-by: Steev Klimaszewski 
Tested-by: Neil Armstrong  # on HDK8450
Tested-by: Johan Hovold 	# X13s
Reviewed-by: Johan Hovold 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20230515032743.400170-5-quic_bjorande@quicinc.com
Signed-off-by: Vinod Koul

phy: qcom-qmp-combo: Extend phy_mutex to all phy_ops

2023-05-19T17:47:19+00:00

The phy core ensures mutual exclusion across the ops for a given phy,
but the upcoming introduction of USB Type-C orientation switching might
race with the DisplayPort phy operations. So extend the mutual exclusion
to cover the remaining ops as well, to avoid concurrent reconfiguration
of the hardware.

Reported-by: Johan Hovold 
Reviewed-by: Johan Hovold 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20230515032743.400170-4-quic_bjorande@quicinc.com
Signed-off-by: Vinod Koul