linux-kernel - Re: [PATCH v3 4/4] PCIe: qcom: Add support to control pipe clk mux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YOxn5GWQsEH/+bSm@yoga>
Date:   Mon, 12 Jul 2021 11:03:48 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Prasad Malisetty <pmaliset@...eaurora.org>
Cc:     agross@...nel.org, bhelgaas@...gle.com, robh+dt@...nel.org,
        swboyd@...omium.org, lorenzo.pieralisi@....com,
        svarbanov@...sol.com, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, mgautam@...eaurora.org,
        dianders@...omium.org, mka@...omium.org, sanm@...eaurora.org
Subject: Re: [PATCH v3 4/4] PCIe: qcom: Add support to control pipe clk mux

On Tue 22 Jun 11:00 CDT 2021, Prasad Malisetty wrote:

> pipe-clk mux needs to switch between pipe_clk

If you spell "pipe-clk mux" as "gcc_pcie_N_pipe_clk_src" there's no
ambiguity in which clock you refer to.

> and XO as part of LPM squence. This is done by setting
> pipe_clk mux as parent of pipe_clk after phy init.

I thought the two possible cases where:

xo -> gcc_pcie_N_pipe_clk_src -> gcc_pcie_N_pipe_clk
PHY::pipe_clk -> gcc_pcie_N_pipe_clk_src -> gcc_pcie_N_pipe_clk

But here you're saying that you're setting the parent of PHY::pipe_clk
to gcc_pcie_N_pipe_clk?

> This is a new requirement for sc7280.
> For accessing to DBI registers during L23,
> need to switch the pipe clock with free-running
> clock (TCXO) using GCC’s registers

So in previous platforms we could access DBI registers, in L23, without
any clock?

What happens if we use xo as parent for the pipe clock

> 
> Signed-off-by: Prasad Malisetty <pmaliset@...eaurora.org>
> ---
>  drivers/pci/controller/dwc/pcie-qcom.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 8a7a300..80e9ee4 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -166,6 +166,9 @@ struct qcom_pcie_resources_2_7_0 {
>  	struct regulator_bulk_data supplies[2];
>  	struct reset_control *pci_reset;
>  	struct clk *pipe_clk;
> +	struct clk *pipe_clk_mux;
> +	struct clk *pipe_ext_src;
> +	struct clk *ref_clk_src;
>  };
>  
>  union qcom_pcie_resources {
> @@ -1167,6 +1170,20 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie)
>  	if (ret < 0)
>  		return ret;
>  
> +	if (of_device_is_compatible(dev->of_node, "qcom,pcie-sc7280")) {

So this is the first 2.7.0 that has this need? Are we just going to add
more compatibles to this list going forward?

> +		res->pipe_clk_mux = devm_clk_get(dev, "pipe_mux");
> +		if (IS_ERR(res->pipe_clk_mux))
> +			return PTR_ERR(res->pipe_clk_mux);

So this is gcc_pcie_N_pipe_clk_src?

> +
> +		res->pipe_ext_src = devm_clk_get(dev, "phy_pipe");
> +		if (IS_ERR(res->pipe_ext_src))
> +			return PTR_ERR(res->pipe_ext_src);

And this is the pipe_clk coming out of the PHY (What I call
PHY::pipe_clk above)?

> +
> +		res->ref_clk_src = devm_clk_get(dev, "ref");
> +		if (IS_ERR(res->ref_clk_src))
> +			return PTR_ERR(res->ref_clk_src);

And this is TCXO?

> +	}
> +
>  	res->pipe_clk = devm_clk_get(dev, "pipe");
>  	return PTR_ERR_OR_ZERO(res->pipe_clk);
>  }
> @@ -1255,6 +1272,11 @@ static void qcom_pcie_deinit_2_7_0(struct qcom_pcie *pcie)
>  static int qcom_pcie_post_init_2_7_0(struct qcom_pcie *pcie)
>  {
>  	struct qcom_pcie_resources_2_7_0 *res = &pcie->res.v2_7_0;
> +	struct dw_pcie *pci = pcie->pci;
> +	struct device *dev = pci->dev;
> +
> +	if (of_device_is_compatible(dev->of_node, "qcom,pcie-sc7280"))
> +		clk_set_parent(res->pipe_clk_mux, res->pipe_ext_src);
>  

So after phy_power_on() (not "phy init" as you say in the commit
message, perhaps you don't mean phy_init() but in general terms "phy
initialization") you need to make sure that gcc_pcie_N_pipe_clk_src is
actually fed by PHY::pipe_clk?

1) What's the gcc_pcie_N_pipe_clk_src parent before this?

2) Will the PHY initialization really succeed if the pipe_clk feeding
back from gcc isn't based on the PHY's pipe_clk? Is this a change in
sc7280?

3) In the commit message you're talking about the need to make XO the
parent of gcc_pcie_N_pipe_clk_src during L23, where in this patch does
that happen?

Regards,
Bjorn

>  	return clk_prepare_enable(res->pipe_clk);
>  }
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>