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

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: <CAE-0n538LKQpeY_NKQF-VM3nHVxEE0B_pN4aN=sQ8iQzK+Yyxw@mail.gmail.com>
Date:   Fri, 16 Jul 2021 21:37:22 +0200
From:   Stephen Boyd <swboyd@...omium.org>
To:     Prasad Malisetty <pmaliset@...eaurora.org>, agross@...nel.org,
        bhelgaas@...gle.com, bjorn.andersson@...aro.org,
        lorenzo.pieralisi@....com, robh+dt@...nel.org, svarbanov@...sol.com
Cc:     devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        dianders@...omium.org, mka@...omium.org, vbadigan@...eaurora.org,
        sallenki@...eaurora.org
Subject: Re: [PATCH v4 4/4] PCIe: qcom: Add support to control pipe clk src

Quoting Prasad Malisetty (2021-07-16 06:58:47)
> This is a new requirement for sc7280 SoC.
> To enable gdsc gcc_pcie_1_pipe_clk_src should be TCXO.

Why? Can you add that detail here? Presumably it's something like the
GDSC needs a running clk to send a reset through the flops or something
like that.

> after PHY initialization gcc_pcie_1_pipe_clk_src needs
> to switch from TCXO to gcc_pcie_1_pipe_clk.
>
> 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..9e0e4ab 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -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")) {
> +               res->gcc_pcie_1_pipe_clk_src = devm_clk_get(dev, "pipe_mux");
> +               if (IS_ERR(res->gcc_pcie_1_pipe_clk_src))
> +                       return PTR_ERR(res->gcc_pcie_1_pipe_clk_src);
> +
> +               res->phy_pipe_clk = devm_clk_get(dev, "phy_pipe");
> +               if (IS_ERR(res->phy_pipe_clk))
> +                       return PTR_ERR(res->phy_pipe_clk);
> +
> +               res->ref_clk_src = devm_clk_get(dev, "ref");
> +               if (IS_ERR(res->ref_clk_src))
> +                       return PTR_ERR(res->ref_clk_src);
> +       }
> +
>         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->gcc_pcie_1_pipe_clk_src, res->phy_pipe_clk);

Is anything wrong if we call clk_set_parent() here when this driver is
running on previous SoCs where the parent is assigned via DT? Also,
shouldn't we make sure the parent is XO at driver probe time so that
powering on the GDSC works properly?

It all feels like a kludge though given that the GDSC is the one that
requires the clock to be running at XO and we're working around that in
the pcie driver instead of sticking that logic into the GDSC. What do we
do if the GDSC is already enabled out of boot instead of being the power
on reset (POR) configuration?

>
>         return clk_prepare_enable(res->pipe_clk);
>  }