[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <161730590437.2260335.9611290766189379085@swboyd.mtv.corp.google.com>
Date: Thu, 01 Apr 2021 12:38:24 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Konrad Dybcio <konrad.dybcio@...ainline.org>,
Rob Herring <robh@...nel.org>
Cc: ~postmarketos/upstreaming@...ts.sr.ht, martin.botka@...ainline.org,
angelogioacchino.delregno@...ainline.org,
marijn.suijten@...ainline.org, Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Taniya Das <tdas@...eaurora.org>,
linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 9/9] clk: qcom: gcc-msm8994: Add a quirk for a different SDCC configuration
Quoting Konrad Dybcio (2021-03-24 10:12:34)
>
> On 24.03.2021 18:11, Rob Herring wrote:
> > On Sat, Mar 13, 2021 at 03:19:18AM +0100, Konrad Dybcio wrote:
> >> Some devices come with a different SDCC clock configuration,
> >> account for that.
> >>
> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@...ainline.org>
> >> ---
> >> .../bindings/clock/qcom,gcc-msm8994.yaml | 4 ++++
> >> drivers/clk/qcom/gcc-msm8994.c | 16 ++++++++++++++++
> >> 2 files changed, 20 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
> >> index f8067fb1bbd6..9db0800a4ee4 100644
> >> --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
> >> +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
> >> @@ -49,6 +49,10 @@ properties:
> >> description:
> >> Protected clock specifier list as per common clock binding.
> >>
> >> + qcom,sdcc2-clk-src-40mhz:
> >> + description: SDCC2_APPS clock source runs at 40MHz.
> >> + type: boolean
> > Why don't you have some input clock you can get the rate from?
>
>
> This is a SONY-custom hardware change and that's as much information as I can get. Schematics are not available and it's solely based on the downstream kernel source.
>
Presumably we can add the extra frequencies to the frequency plan array
and not need this extra property in DT. The consumer driver should be
able to pick the correct frequency.
Powered by blists - more mailing lists