[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=X4gW3cpFPTL7KmocP1z7fK1fSRjg7BYjA7D_Uu7p5gnQ@mail.gmail.com>
Date: Wed, 22 Jan 2020 16:46:08 -0800
From: Doug Anderson <dianders@...omium.org>
To: Taniya Das <tdas@...eaurora.org>
Cc: Andy Gross <agross@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
inux-arm-msm@...r.kernel.org,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Matthias Kaehlcke <mka@...omium.org>,
Stephen Boyd <swboyd@...omium.org>,
Rajendra Nayak <rnayak@...eaurora.org>
Subject: Re: [PATCH] arm64: dts: sc7180: Add clock controller nodes
Hi,
On Fri, Dec 27, 2019 at 12:38 AM Taniya Das <tdas@...eaurora.org> wrote:
>
> Add the display, video & graphics clock controller nodes supported on
> SC7180.
>
> Signed-off-by: Taniya Das <tdas@...eaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
Can you add these to your patch?
#include <dt-bindings/clock/qcom,dispcc-sc7180.h>
#include <dt-bindings/clock/qcom,gpucc-sc7180.h>
...otherwise the first user of each of the clocks will need to add the
#include and depending on what order patches landed things can get
weird. I think it's cleaner to assume that there will soon be a user
and proactively add the #includes.
NOTE: at least one user of your patch can be found at
<https://lore.kernel.org/r/1579621928-18619-1-git-send-email-harigovi@codeaurora.org>.
They don't add the #includes which means they don't compile atop your
patch.
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 3676bfd..3bb7b65 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -931,6 +931,18 @@
> };
> };
>
> + gpucc: clock-controller@...0000 {
> + compatible = "qcom,sc7180-gpucc";
> + reg = <0 0x05090000 0 0x9000>;
> + clocks = <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_GPU_GPLL0_CLK_SRC>,
> + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
> + clock-names = "bi_tcxo", "gpll0_main", "gpll0_div";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> qspi: spi@...c000 {
> compatible = "qcom,qspi-v1";
> reg = <0 0x088dc000 0 0x600>;
> @@ -1043,6 +1055,27 @@
> };
> };
>
> + videocc: clock-controller@...0000 {
> + compatible = "qcom,sc7180-videocc";
> + reg = <0 0x0ab00000 0 0x10000>;
> + clocks = <&rpmhcc RPMH_CXO_CLK>;
> + clock-names = "bi_tcxo";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> + dispcc: clock-controller@...0000 {
> + compatible = "qcom,sc7180-dispcc";
> + reg = <0 0x0af00000 0 0x200000>;
> + clocks = <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_DISP_GPLL0_CLK_SRC>;
> + clock-names = "bi_tcxo", "gpll0";
The above doesn't match your code unless I'm missing a patch
somewhere. Specifically I find that if I use your dts patch together
with the upstream code I get a nice crash at bootup. I tracked it
down to the fact that the code uses the name "gcc_disp_gpll0_clk_src"
but your dts uses the name "gpll0". Specifically this bit of code:
static const struct clk_parent_data disp_cc_parent_data_3[] = {
{ .fw_name = "bi_tcxo" },
{ .hw = &disp_cc_pll0.clkr.hw },
{ .fw_name = "gcc_disp_gpll0_clk_src" },
{ .hw = &disp_cc_pll0_out_even.clkr.hw },
{ .fw_name = "core_bi_pll_test_se", .name = "core_bi_pll_test_se" },
};
static const struct clk_parent_data disp_cc_parent_data_4[] = {
{ .fw_name = "bi_tcxo" },
{ .fw_name = "gcc_disp_gpll0_clk_src" },
{ .fw_name = "core_bi_pll_test_se", .name = "core_bi_pll_test_se" },
};
If I either change the code to use "gpll0" or change your dts to use
"gcc_disp_gpll0_clk_src" I can avoid the crash.
I believe there is a similar problem with the gpucc with
"gcc_gpu_gpll0_div_clk_src" / "gpll0_div".
-Doug
Powered by blists - more mailing lists