All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.