[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <243ab835-bc91-6cc6-a9ce-7be6763dc89e@somainline.org>
Date: Thu, 17 Jun 2021 21:37:12 +0200
From: Konrad Dybcio <konrad.dybcio@...ainline.org>
To: Robert Foss <robert.foss@...aro.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Jonathan Marek <jonathan@...ek.ca>,
Taniya Das <tdas@...eaurora.org>,
MSM <linux-arm-msm@...r.kernel.org>,
"open list:COMMON CLK FRAMEWORK" <linux-clk@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Vinod Koul <vinod.koul@...aro.org>
Subject: Re: [RFC v1 06/11] clk: qcom: Add display clock controller driver for
SM8350
>>> +
>>> +static struct pll_vco vco_table[] = {
>>> + { 249600000, 1750000000, 0 },
>>> +};
>>> +
>>> +static const struct alpha_pll_config disp_cc_pll0_config = {
>>> + .l = 0x47,
>> Is the ".cal_l = 0x44," part from downstream not necessary?
> Yes it is. I went back and forth about 'cal_l', but in the end the
> only value it is ever set to is 0x44, which is also what the default
> value is. So there is no need for representing it explicitly at the
> moment.
Interesting, maybe it'll be required for next SoCs..
>>> +};
>>> +
>>> +static const struct alpha_pll_config disp_cc_pll1_config = {
>>> + .l = 0x1F,
>> Ditto
> Sorry, ditto what?
Aah, sorry I cut out a ".cal_l = 0x44" line while adding my comments..
Konrad
Powered by blists - more mailing lists