All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: andy.gross@linaro.org, arnd@arndb.de, bjorn.andersson@linaro.org,
	david.brown@linaro.org, enric.balletbo@collabora.com,
	heiko@sntech.de, horms+renesas@verge.net.au,
	jagan@amarulasolutions.com, jassisinghbrar@gmail.com,
	jorge.ramirez-ortiz@linaro.org, mark.rutland@arm.com,
	mturquette@baylibre.com, olof@lixom.net, robh+dt@kernel.org,
	sibis@codeaurora.org, will.deacon@arm.com
Cc: vkoul@kernel.org, niklas.cassel@linaro.org,
	georgi.djakov@linaro.org, amit.kucheria@linaro.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, khasim.mohammed@linaro.org
Subject: Re: [PATCH v2 05/14] clk: qcom: apcs-msm8916: get parent clock names from DT
Date: Fri, 22 Feb 2019 10:11:42 -0800	[thread overview]
Message-ID: <155085910216.77512.12604271825136479370@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <1548700381-22376-6-git-send-email-jorge.ramirez-ortiz@linaro.org>

Quoting Jorge Ramirez-Ortiz (2019-01-28 10:32:52)
> @@ -61,6 +65,25 @@ static int qcom_apcs_msm8916_clk_probe(struct platform_device *pdev)
>         if (!a53cc)
>                 return -ENOMEM;
>  
> +       /* check if the parent names are present in the device tree */

This looks odd.

> +       ret = devm_clk_bulk_get(parent, ARRAY_SIZE(pclks), pclks);
> +       if (ret == -EPROBE_DEFER)
> +               return ret;

Why can't we use of_clk_parent_fill() if we know this is always a DT
platform?  The parent clks may not be registered at the time of probe?
Maybe this series should wait for the parent registration stuff I'm
working on so that this can be made simpler.

> +
> +       if (!ret) {
> +               gpll0_a53cc[0] = __clk_get_name(pclks[0].clk);
> +               gpll0_a53cc[1] = __clk_get_name(pclks[1].clk);
> +               a53cc->pclk = pclks[1].clk;
> +       } else {
> +               /* support old binding where only pll was explicitily defined */
> +               a53cc->pclk = devm_clk_get(parent, NULL);
> +               if (IS_ERR(a53cc->pclk)) {
> +                       ret = PTR_ERR(a53cc->pclk);
> +                       dev_err(dev, "failed to get clk: %d\n", ret);
> +                       return ret;
> +               }
> +       }
> +
>         init.name = "a53mux";
>         init.parent_names = gpll0_a53cc;
>         init.num_parents = ARRAY_SIZE(gpll0_a53cc);

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: andy.gross@linaro.org, arnd@arndb.de, bjorn.andersson@linaro.org,
	david.brown@linaro.org, enric.balletbo@collabora.com,
	heiko@sntech.de, horms+renesas@verge.net.au,
	jagan@amarulasolutions.com, jassisinghbrar@gmail.com,
	jorge.ramirez-ortiz@linaro.org, mark.rutland@arm.com,
	mturquette@baylibre.com, olof@lixom.net, robh+dt@kernel.org,
	sibis@codeaurora.org, will.deacon@arm.com
Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	khasim.mohammed@linaro.org, linux-kernel@vger.kernel.org,
	amit.kucheria@linaro.org, linux-clk@vger.kernel.org,
	vkoul@kernel.org, niklas.cassel@linaro.org,
	georgi.djakov@linaro.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 05/14] clk: qcom: apcs-msm8916: get parent clock names from DT
Date: Fri, 22 Feb 2019 10:11:42 -0800	[thread overview]
Message-ID: <155085910216.77512.12604271825136479370@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <1548700381-22376-6-git-send-email-jorge.ramirez-ortiz@linaro.org>

Quoting Jorge Ramirez-Ortiz (2019-01-28 10:32:52)
> @@ -61,6 +65,25 @@ static int qcom_apcs_msm8916_clk_probe(struct platform_device *pdev)
>         if (!a53cc)
>                 return -ENOMEM;
>  
> +       /* check if the parent names are present in the device tree */

This looks odd.

> +       ret = devm_clk_bulk_get(parent, ARRAY_SIZE(pclks), pclks);
> +       if (ret == -EPROBE_DEFER)
> +               return ret;

Why can't we use of_clk_parent_fill() if we know this is always a DT
platform?  The parent clks may not be registered at the time of probe?
Maybe this series should wait for the parent registration stuff I'm
working on so that this can be made simpler.

> +
> +       if (!ret) {
> +               gpll0_a53cc[0] = __clk_get_name(pclks[0].clk);
> +               gpll0_a53cc[1] = __clk_get_name(pclks[1].clk);
> +               a53cc->pclk = pclks[1].clk;
> +       } else {
> +               /* support old binding where only pll was explicitily defined */
> +               a53cc->pclk = devm_clk_get(parent, NULL);
> +               if (IS_ERR(a53cc->pclk)) {
> +                       ret = PTR_ERR(a53cc->pclk);
> +                       dev_err(dev, "failed to get clk: %d\n", ret);
> +                       return ret;
> +               }
> +       }
> +
>         init.name = "a53mux";
>         init.parent_names = gpll0_a53cc;
>         init.num_parents = ARRAY_SIZE(gpll0_a53cc);

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-02-22 18:11 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 18:32 [PATCH v2 00/14] Support CPU frequency scaling on QCS404 Jorge Ramirez-Ortiz
2019-01-28 18:32 ` Jorge Ramirez-Ortiz
2019-01-28 18:32 ` [PATCH v2 01/14] clk: qcom: gcc: limit GPLL0_AO_OUT operating frequency Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-02-22 18:07   ` Stephen Boyd
2019-02-22 18:07     ` Stephen Boyd
2019-01-28 18:32 ` [PATCH v2 02/14] mbox: qcom: add APCS child device for QCS404 Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-02-22 18:09   ` Stephen Boyd
2019-02-22 18:09     ` Stephen Boyd
2019-01-28 18:32 ` [PATCH v2 03/14] mbox: qcom: replace integer with valid macro Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-28 18:32 ` [PATCH v2 04/14] dt-bindings: mailbox: qcom: Add clock-name optional property Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-30 15:50   ` Rob Herring
2019-01-30 15:50     ` Rob Herring
2019-01-30 15:50     ` Rob Herring
2019-01-28 18:32 ` [PATCH v2 05/14] clk: qcom: apcs-msm8916: get parent clock names from DT Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-02-22 18:11   ` Stephen Boyd [this message]
2019-02-22 18:11     ` Stephen Boyd
2019-04-22 11:44     ` Jorge Ramirez
2019-04-22 11:44       ` Jorge Ramirez
2019-04-25 21:29       ` Stephen Boyd
2019-04-25 21:29         ` Stephen Boyd
2019-04-25 21:42         ` Jorge Ramirez
2019-04-25 21:42           ` Jorge Ramirez
2019-01-28 18:32 ` [PATCH v2 06/14] clk: qcom: hfpll: " Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-28 18:32 ` [PATCH v2 07/14] clk: qcom: hfpll: register as clock provider Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-02-22 18:06   ` Stephen Boyd
2019-02-22 18:06     ` Stephen Boyd
2019-01-28 18:32 ` [PATCH v2 08/14] clk: qcom: hfpll: CLK_IGNORE_UNUSED Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-02-22 18:12   ` Stephen Boyd
2019-02-22 18:12     ` Stephen Boyd
2019-01-28 18:32 ` [PATCH v2 09/14] arm64: dts: qcom: msm8916: Add the clocks for the APCS mux/divider Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-28 18:32 ` [PATCH v2 10/14] arm64: dts: qcom: qcs404: Add OPP table Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-30  4:41   ` Vinod Koul
2019-01-30  4:41     ` Vinod Koul
2019-01-30  9:08     ` Jorge Ramirez
2019-01-30  9:08       ` Jorge Ramirez
2019-01-28 18:32 ` [PATCH v2 11/14] arm64: dts: qcom: qcs404: Add HFPLL node Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-28 18:32 ` [PATCH v2 12/14] arm64: dts: qcom: qcs404: Add the clocks for APCS mux/divider Jorge Ramirez-Ortiz
2019-01-28 18:32   ` Jorge Ramirez-Ortiz
2019-01-28 18:33 ` [PATCH v2 13/14] arm64: dts: qcom: qcs404: Add cpufreq support Jorge Ramirez-Ortiz
2019-01-28 18:33   ` Jorge Ramirez-Ortiz
2019-01-28 18:33 ` [PATCH v2 14/14] arm64: defconfig: Enable HFPLL Jorge Ramirez-Ortiz
2019-01-28 18:33   ` Jorge Ramirez-Ortiz

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=155085910216.77512.12604271825136479370@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=amit.kucheria@linaro.org \
    --cc=andy.gross@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=david.brown@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=enric.balletbo@collabora.com \
    --cc=georgi.djakov@linaro.org \
    --cc=heiko@sntech.de \
    --cc=horms+renesas@verge.net.au \
    --cc=jagan@amarulasolutions.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=jorge.ramirez-ortiz@linaro.org \
    --cc=khasim.mohammed@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=niklas.cassel@linaro.org \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=sibis@codeaurora.org \
    --cc=vkoul@kernel.org \
    --cc=will.deacon@arm.com \
    /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.