Re: [PATCH v6 0/5] PCI: qcom: Rework pipe_clk/pipe_clk_src handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 13, 2022 at 08:53:34PM +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.
> 
> Changes since v5:
>  - Rename the clock to clk-regmap-phy-mux and the enable/disable values
>    to phy_src_val and ref_src_val respectively (as recommended by
>    Johan).
> 
> Changes since v4:
>  - Renamed the clock to clk-regmap-pipe-src,
>  - Added mention of PCIe2 PHY to the commit message,
>  - Expanded commit messages to mention additional pipe clock details.
> 
> 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.
> 
> 
> Dmitry Baryshkov (5):
>   PCI: qcom: Remove unnecessary pipe_clk handling
>   clk: qcom: regmap: add PHY clock source implementation
>   clk: qcom: gcc-sm8450: use new clk_regmap_pipe_src_ops for PCIe pipe
>     clocks
>   clk: qcom: gcc-sc7280: use new clk_regmap_pipe_src_ops for PCIe pipe
>     clocks
>   PCI: qcom: Drop manual pipe_clk_src handling

So Bjorn A has already applied v2 of the three clock patches this series
to his tree. I guess dropping or reverting does is the best way to
handle this since trying to fix things up incrementally would just be
messy.

Johan



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux