[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <356199897fb2022342a76bc872b703d5@codeaurora.org>
Date: Thu, 24 Nov 2016 18:16:02 +0530
From: Abhishek Sahu <absahu@...eaurora.org>
To: Stephen Boyd <sboyd@...eaurora.org>
Cc: andy.gross@...aro.org, david.brown@...aro.org, robh+dt@...nel.org,
pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, mturquette@...libre.com,
galak@...eaurora.org, pradeepb@...eaurora.org,
mmcclint@...eaurora.org, varada@...eaurora.org,
sricharan@...eaurora.org, architt@...eaurora.org,
ntelkar@...eaurora.org, linux-arm-msm@...r.kernel.org,
linux-soc@...r.kernel.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 4/7] clk: qcom: ipq4019: Added all the frequencies for
apps cpu
On 2016-11-02 06:54, Stephen Boyd wrote:
> On 09/21, Abhishek Sahu wrote:
>> The APPS CPU clock does not contain all the frequencies in its
>> frequency table so this patch adds the same.
>>
>> Signed-off-by: Abhishek Sahu <absahu@...eaurora.org>
>> ---
>> drivers/clk/qcom/gcc-ipq4019.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/qcom/gcc-ipq4019.c
>> b/drivers/clk/qcom/gcc-ipq4019.c
>> index 211c68c..160e0cf 100644
>> --- a/drivers/clk/qcom/gcc-ipq4019.c
>> +++ b/drivers/clk/qcom/gcc-ipq4019.c
>> @@ -565,10 +565,20 @@ static struct clk_rcg2 sdcc1_apps_clk_src = {
>> };
>>
>> static const struct freq_tbl ftbl_gcc_apps_clk[] = {
>> - F(48000000, P_XO, 1, 0, 0),
>> + F(48000000, P_XO, 1, 0, 0),
>> F(200000000, P_FEPLL200, 1, 0, 0),
>> + F(380000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(409000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(444000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(484000000, P_DDRPLLAPSS, 1, 0, 0),
>> F(500000000, P_FEPLL500, 1, 0, 0),
>> + F(507000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(532000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(560000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(592000000, P_DDRPLLAPSS, 1, 0, 0),
>> F(626000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(666000000, P_DDRPLLAPSS, 1, 0, 0),
>> + F(710000000, P_DDRPLLAPSS, 1, 0, 0),
>> { }
>> };
>
> Can't we have the determine_rate callback know the speeds of the
> "fixed" PLLs and use those first if the rate hits exactly? And
> then if that doesn't happen go try ddrpllapps and set the rate on
> it? I'm hoping we can get rid of this frequency table.
This clock is being registered with QCOM clk_rcg2 operations which
already has determine_rate callback based on this frequency table.
Currently all the frequencies are being generated without HID
divider but in future, we can have some frequency which will use
dividers also.
--
Abhishek Sahu
Powered by blists - more mailing lists