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
>>
prev parent 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).