On Sun, May 01, 2022 at 10:21:44PM +0300, Dmitry Baryshkov wrote: > PCIe pipe clk (and some other clocks) must be parked to the "safe" > source (bi_tcxo) when corresponding GDSC is turned off and on again. > Currently this is handcoded in the PCIe driver by reparenting the > gcc_pipe_N_clk_src clock. > > Instead of doing it manually, follow the approach used by > clk_rcg2_shared_ops and implement this parking in the enable() and > disable() clock operations for respective pipe clocks. > > PCIe part depends on [1]. > > Changes since v3: > - Replaced the clock multiplexer implementation with branch-like clock. > > Changes since v2: > - Added is_enabled() callback > - Added default parent to the pipe clock configuration > > Changes since v1: > - Rebased on top of [1]. > - Removed erroneous Fixes tag from the patch 4. > > Changes since RFC: > - Rework clk-regmap-mux fields. Specify safe parent as P_* value rather > than specifying the register value directly > - Expand commit message to the first patch to specially mention that > it is required only on newer generations of Qualcomm chipsets. > > [1]: https://lore.kernel.org/all/20220401133351.10113-1-johan+linaro@xxxxxxxxxx/ > > Dmitry Baryshkov (5): > PCI: qcom: Remove unnecessary pipe_clk handling > clk: qcom: regmap: add pipe clk implementation > clk: qcom: gcc-sm8450: use new clk_regmap_pipe_ops for PCIe pipe > clocks > clk: qcom: gcc-sc7280: use new clk_regmap_pipe_ops for PCIe pipe > clocks > PCI: qcom: Drop manual pipe_clk_src handling > > drivers/clk/qcom/Makefile | 1 + > drivers/clk/qcom/clk-regmap-pipe.c | 62 ++++++++++++++++++++ > drivers/clk/qcom/clk-regmap-pipe.h | 24 ++++++++ > drivers/clk/qcom/gcc-sc7280.c | 49 ++++++---------- > drivers/clk/qcom/gcc-sm8450.c | 51 ++++++---------- > drivers/pci/controller/dwc/pcie-qcom.c | 81 +------------------------- > 6 files changed, 128 insertions(+), 140 deletions(-) > create mode 100644 drivers/clk/qcom/clk-regmap-pipe.c > create mode 100644 drivers/clk/qcom/clk-regmap-pipe.h Hi guys, where are we with this series ? I have noticed there is an ongoing review so if you don't disagree I'd mark it as "Changes Requested" and wait for a v5. Thanks, Lorenzo
