The USB controllers on sc7280 do not retain the state when
the system goes into low power state and the GDSCs are
turned off. This results in the controllers reinitializing and
re-enumerating all the connected devices (resulting in additional
delay while coming out of suspend)
Fix this by updating the .pwrsts for the USB GDSCs so they only
transition to retention state in low power.
Since sc7280 only supports cx (parent of usb gdscs) Retention, there
are no cxcs offsets mentioned in order to support the Retention
state.
Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220920111517.10407-3-quic_rjendra@quicinc.com
The USB controller on sc7180 does not retain the state when
the system goes into low power state and the GDSC is
turned off. This results in the controller reinitializing and
re-enumerating all the connected devices (resulting in additional
delay while coming out of suspend)
Fix this by updating the .pwrsts for the USB GDSC so it only
transitions to retention state in low power.
Since sc7180 only supports cx (parent of usb gdsc) Retention, there
are no cxcs offsets mentioned in order to support the Retention
state.
Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220920111517.10407-2-quic_rjendra@quicinc.com
GDSCs cannot be transitioned into a Retention state in SW.
When either the RETAIN_MEM bit, or both the RETAIN_MEM and
RETAIN_PERIPH bits are set, and the GDSC is left ON, the HW
takes care of retaining the memory/logic for the domain when
the parent domain transitions to power collapse/power off state.
On some platforms where the parent domains lowest power state
itself is Retention, just leaving the GDSC in ON (without any
RETAIN_MEM/RETAIN_PERIPH bits being set) will also transition
it to Retention.
The existing logic handling the PWRSTS_RET seems to set the
RETAIN_MEM/RETAIN_PERIPH bits if the cxcs offsets are specified
but then explicitly turns the GDSC OFF as part of _gdsc_disable().
Fix that by leaving the GDSC in ON state.
Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220920111517.10407-1-quic_rjendra@quicinc.com
Convert the driver to use OF match data for providing the Alpha PLL config
per compatible.
This is required for IPQ8074 support since it uses a different Alpha PLL
config.
While we are here rename "ipq_pll_config" to "ipq6018_pll_config" to make
it clear that it is for IPQ6018 only.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220818220628.339366-5-robimarko@gmail.com
While working on IPQ8074 APSS driver it was discovered that IPQ6018 and
IPQ8074 use almost the same PLL and APSS clocks, however APSS driver is
currently broken.
More precisely apcs_alias0_clk_src is broken, it was added as regmap_mux
clock.
However after debugging why it was always stuck at 800Mhz, it was figured
out that its not regmap_mux compatible at all.
It is a simple mux but it uses RCG2 register layout and control bits, so
utilize the new clk_rcg2_mux_closest_ops to correctly drive it while not
having to provide a dummy frequency table.
While we are here, use ARRAY_SIZE for number of parents.
Tested on IPQ6018-CP01-C1 reference board and multiple IPQ8074 boards.
Fixes: 5e77b4ef1b ("clk: qcom: Add ipq6018 apss clock controller")
Signed-off-by: Robert Marko <robimarko@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220818220628.339366-2-robimarko@gmail.com
An RCG may act as a mux that switch between 2 parents.
This is the case on IPQ6018 and IPQ8074 where the APCS core clk that feeds
the CPU cluster clock just switches between XO and the PLL that feeds it.
Add the required ops to add support for this special configuration and use
the generic mux function to determine the rate.
This way we dont have to keep a essentially dummy frequency table to use
RCG2 as a mux.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Robert Marko <robimarko@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220818220628.339366-1-robimarko@gmail.com
Replace parent_names in PLLs, secondary muxes and primary muxes with
parent_data. For primary muxes there were never any *cl_pll_acd clocks,
so instead of adding them, put the primary PLLs in both PLL_INDEX and
ACD_INDEX, then make sure ACD_INDEX is always picked over PLL_INDEX when
setting parent since we always want ACD when using the primary PLLs.
Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
[DB: switch to parent_hws for pmux clocks]
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220714100351.1834711-2-dmitry.baryshkov@linaro.org
The USB PHY on MSM8909 works with the driver used on MSM8916
(phy-qcom-usb-hs.c). When turning the PHY on/off it is first reset
using the standard reset controller API. On MSM8916 the reset is
provided by the USB driver (ci_hdrc_msm_por_reset() in ci_hdrc_msm.c).
While this seems to work on MSM8909 as well, the Qualcomm Linux sources
suggest that the PHY should be reset using the GCC_USB2_HS_PHY_ONLY_BCR
register instead. In general this is easy to set up in the device tree,
thanks to the standard reset controller API.
However, to conform to the specifications of the PHY the reset signal
should be asserted for at least 10 us. This is handled correctly on
MSM8916 in ci_hdrc_msm_por_reset(), but not within the GCC driver.
Fix this by making use of the new "udelay" field of qcom_reset_map
and set a delay of ~15 us between the assertion/deassertion of the
USB PHY reset signal.
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220706134132.3623415-5-stephan.gerhold@kernkonzept.com
The amount of time required between asserting and deasserting the reset
signal can vary depending on the involved hardware component. Sometimes
1 us might not be enough and a larger delay is necessary to conform to
the specifications.
Usually this is worked around in the consuming drivers, by replacing
reset_control_reset() with a sequence of reset_control_assert(), waiting
for a custom delay, followed by reset_control_deassert().
However, in some cases the driver making use of the reset is generic and
can be used with different reset controllers. In this case the reset
time requirement is better handled directly by the reset controller
driver.
Make this possible by adding an "udelay" field to the qcom_reset_map
that allows setting a different reset delay (in microseconds).
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220706134132.3623415-4-stephan.gerhold@kernkonzept.com
