linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Prasad Malisetty <pmaliset@codeaurora.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: agross@kernel.org, bhelgaas@google.com, robh+dt@kernel.org,
	swboyd@chromium.org, lorenzo.pieralisi@arm.com,
	svarbanov@mm-sol.com, devicetree@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, dianders@chromium.org,
	mka@chromium.org, sanm@codeaurora.org, sallenki@codeaurora.org,
	vbadigan@codeaurora.org
Subject: Re: [PATCH v3 4/4] PCIe: qcom: Add support to control pipe clk mux
Date: Fri, 16 Jul 2021 12:23:58 +0530	[thread overview]
Message-ID: <b0e037b9c6cb58d6ac9f47de9c5aabaf@codeaurora.org> (raw)
In-Reply-To: <YOxn5GWQsEH/+bSm@yoga>

On 2021-07-12 21:33, Bjorn Andersson wrote:
> 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.
> 
Sure, it looks fine, I will modify accordingly.

>> 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?
> 
Yeah, I will correct that statement.

>> 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
> 
 From SC7280 onwards, POR value for "gcc_pcie_N_pipe_clk_src" is TCX0. we 
need TCXO as parent to enable gdsc and then once PHY init successful we 
are changing gcc_pcie_N_pipe_clk_src to PHY pipe clk. In system suspend 
call back GDSC will be disabled and gcc_pcie_N_pipe_clk_src changed to 
TCX0. In the same way resume call back switching back 
gcc_pcie_N_pipe_clk_src to PHY pipe clk .

>> 
>> Signed-off-by: Prasad Malisetty <pmaliset@codeaurora.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?
> 
Will check and confirm whether above change will be applicable to future 
targets or not.

>> +		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?
> 
Yes
>> +
>> +		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)?
> 
Yes
>> +
>> +		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?
> 
Yes
>> +	}
>> +
>>  	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?
> 
TCXO is POR value.

> 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?
> 
PHY init will be successful but PCIe link will not be initialized.
yes, this change is only applicable to 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?
> 
Changes are in validation stage. will submit them soon in coming 
releases.
Just mentioned the purpose of mux settings.

> 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
>> 

      reply	other threads:[~2021-07-16  6:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 16:00 [PATCH v3 0/4] Add DT bindings and DT nodes for PCIe and PHY in SC7280 Prasad Malisetty
2021-06-22 16:00 ` [PATCH v3 1/4] dt-bindings: pci: qcom: Document PCIe bindings for SC720 Prasad Malisetty
2021-06-22 16:00 ` [PATCH v3 2/4] arm64: dts: qcom: sc7280: Add PCIe and PHY related nodes Prasad Malisetty
2021-06-22 16:00 ` [PATCH v3 3/4] arm64: dts: qcom: sc7280: Add PCIe nodes for IDP board Prasad Malisetty
2021-06-22 16:00 ` [PATCH v3 4/4] PCIe: qcom: Add support to control pipe clk mux Prasad Malisetty
2021-07-05  6:18   ` Prasad Malisetty
2021-07-12 16:03   ` Bjorn Andersson
2021-07-16  6:53     ` Prasad Malisetty [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0e037b9c6cb58d6ac9f47de9c5aabaf@codeaurora.org \
    --to=pmaliset@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mka@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=sallenki@codeaurora.org \
    --cc=sanm@codeaurora.org \
    --cc=svarbanov@mm-sol.com \
    --cc=swboyd@chromium.org \
    --cc=vbadigan@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).