linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sivaprakash Murugesan <sivaprak@codeaurora.org>
To: Stephen Boyd <sboyd@kernel.org>,
	agross@kernel.org, bjorn.andersson@linaro.org,
	devicetree@vger.kernel.org, jassisinghbrar@gmail.com,
	linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, mturquette@baylibre.com,
	robh+dt@kernel.org
Subject: Re: [PATCH V3 3/8] clk: qcom: Add A53 PLL support for ipq6018 devices
Date: Wed, 22 Apr 2020 16:14:33 +0530	[thread overview]
Message-ID: <4025e5c3-b532-d235-f73b-2b86055bdde2@codeaurora.org> (raw)
In-Reply-To: <158754602745.132238.14379194464345140559@swboyd.mtv.corp.google.com>

Hi Stephen,

On 4/22/2020 2:30 PM, Stephen Boyd wrote:
> Quoting Sivaprakash Murugesan (2020-04-13 19:55:17)
>> The CPUs on Qualcomm IPQ6018 platform is primarily clocked by A53 PLL.
>> This patch adds support for the A53 PLL on IPQ6018 devices which can
>> support CPU frequencies above 1Ghz.
>>
>> Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org>
>> ---
>>   drivers/clk/qcom/a53-pll.c | 136 ++++++++++++++++++++++++++++++++++++---------
>>   1 file changed, 111 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/clk/qcom/a53-pll.c b/drivers/clk/qcom/a53-pll.c
>> index 45cfc57..a95351c 100644
>> --- a/drivers/clk/qcom/a53-pll.c
>> +++ b/drivers/clk/qcom/a53-pll.c
>> @@ -11,11 +11,40 @@
>>   #include <linux/platform_device.h>
>>   #include <linux/regmap.h>
>>   #include <linux/module.h>
>> +#include <linux/of_device.h>
> Why does this driver need to change to use of_device APIs?
we can use devm APIs and avoid this in next patch.
>
>>   
>>   #include "clk-pll.h"
>>   #include "clk-regmap.h"
>> +#include "clk-alpha-pll.h"
>>   
>> -static const struct pll_freq_tbl a53pll_freq[] = {
>> +struct a53_alpha_pll {
>> +       struct alpha_pll_config *pll_config;
>> +       struct clk_alpha_pll *pll;
>> +};
>> +
>> +union a53pll {
>> +       struct clk_pll *pll;
>> +       struct a53_alpha_pll alpha_pll;
>> +};
>> +
>> +struct a53pll_data {
>> +#define PLL_IS_ALPHA BIT(0)
>> +       u8 flags;
>> +       union a53pll a53pll;
> Why is there a union? Can't we have different clk ops for the two types
> of PLLs and then use container_of to get it from the clk ops?
ok.
>
>> +};
>> +
>> +static const u8 ipq_pll_offsets[] = {
>> +       [PLL_OFF_L_VAL] = 0x08,
>> +       [PLL_OFF_ALPHA_VAL] = 0x10,
>> +       [PLL_OFF_USER_CTL] = 0x18,
>> +       [PLL_OFF_CONFIG_CTL] = 0x20,
>> +       [PLL_OFF_CONFIG_CTL_U] = 0x24,
>> +       [PLL_OFF_STATUS] = 0x28,
>> +       [PLL_OFF_TEST_CTL] = 0x30,
>> +       [PLL_OFF_TEST_CTL_U] = 0x34,
>> +};
>> +
>> +static const struct pll_freq_tbl msm8996_a53pll_freq[] = {
>>          {  998400000, 52, 0x0, 0x1, 0 },
>>          { 1094400000, 57, 0x0, 0x1, 0 },
>>          { 1152000000, 62, 0x0, 0x1, 0 },
>> @@ -26,6 +55,64 @@ static const struct pll_freq_tbl a53pll_freq[] = {
>>          { }
>>   };
>>   
>> +static struct clk_pll msm8996_pll = {
>> +       .mode_reg = 0x0,
>> +       .l_reg = 0x04,
>> +       .m_reg = 0x08,
>> +       .n_reg = 0x0c,
>> +       .config_reg = 0x14,
>> +       .status_reg = 0x1c,
>> +       .status_bit = 16,
>> +       .freq_tbl = msm8996_a53pll_freq,
>> +       .clkr.hw.init = &(struct clk_init_data){
>> +               .name = "a53pll",
>> +               .flags = CLK_IS_CRITICAL,
>> +               .parent_data = &(const struct clk_parent_data){
>> +                       .fw_name = "xo",
>> +                       .name = "xo",
>> +               },
>> +               .num_parents = 1,
>> +               .ops = &clk_pll_sr2_ops,
>> +       },
>> +};
>> +
>> +static struct clk_alpha_pll ipq6018_pll = {
>> +       .offset = 0x0,
>> +       .regs = ipq_pll_offsets,
>> +       .flags = SUPPORTS_DYNAMIC_UPDATE,
>> +       .clkr = {
>> +               .enable_reg = 0x0,
>> +               .enable_mask = BIT(0),
>> +               .hw.init = &(struct clk_init_data){
>> +                       .name = "a53pll",
>> +                       .flags = CLK_IS_CRITICAL,
>> +                       .parent_data = &(const struct clk_parent_data){
>> +                               .fw_name = "xo",
>> +                       },
>> +                       .num_parents = 1,
>> +                       .ops = &clk_alpha_pll_huayra_ops,
>> +               },
>> +       },
>> +};
>> +
>> +static struct alpha_pll_config ipq6018_pll_config = {
> Can this be const?
yeah it can be. will fix up in next patch.
>
>> +       .l = 0x37,
>> +       .config_ctl_val = 0x04141200,
>> +       .config_ctl_hi_val = 0x0,
>> +       .early_output_mask = BIT(3),
>> +       .main_output_mask = BIT(0),
>> +};
>> +
>> +static struct a53pll_data msm8996pll_data = {
>> +       .a53pll.pll = &msm8996_pll,
>> +};
>> +
>> +static struct a53pll_data ipq6018pll_data = {
>> +       .flags = PLL_IS_ALPHA,
>> +       .a53pll.alpha_pll.pll = &ipq6018_pll,
>> +       .a53pll.alpha_pll.pll_config = &ipq6018_pll_config,
>> +};
>> +
>>   static const struct regmap_config a53pll_regmap_config = {
>>          .reg_bits               = 32,
>>          .reg_stride             = 4,
>> @@ -39,14 +126,16 @@ static int qcom_a53pll_probe(struct platform_device *pdev)
>>          struct device *dev = &pdev->dev;
>>          struct regmap *regmap;
>>          struct resource *res;
>> -       struct clk_pll *pll;
>> +       const struct a53pll_data *pll_data;
>> +       struct clk_regmap *clkr;
>>          void __iomem *base;
>> -       struct clk_init_data init = { };
>>          int ret;
>>   
>> -       pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
>> -       if (!pll)
>> -               return -ENOMEM;
>> +       pll_data = of_device_get_match_data(dev);
> Use device_get_match_data() please.
ok.
>
>> +       if (!pll_data) {
>> +               dev_err(dev, "failed to get platform data\n");
> No error message please.
ok.
>
>> +               return -ENODEV;
>> +       }
>>   
>>          res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>          base = devm_ioremap_resource(dev, res);
>> @@ -57,30 +146,26 @@ static int qcom_a53pll_probe(struct platform_device *pdev)
>>          if (IS_ERR(regmap))
>>                  return PTR_ERR(regmap);
>>   
>> -       pll->l_reg = 0x04;
>> -       pll->m_reg = 0x08;
>> -       pll->n_reg = 0x0c;
>> -       pll->config_reg = 0x14;
>> -       pll->mode_reg = 0x00;
>> -       pll->status_reg = 0x1c;
>> -       pll->status_bit = 16;
>> -       pll->freq_tbl = a53pll_freq;
>> -
>> -       init.name = "a53pll";
>> -       init.parent_names = (const char *[]){ "xo" };
>> -       init.num_parents = 1;
>> -       init.ops = &clk_pll_sr2_ops;
>> -       init.flags = CLK_IS_CRITICAL;
> Please document why a clk is critical.
ok
>
>> -       pll->clkr.hw.init = &init;
>> -
>> -       ret = devm_clk_register_regmap(dev, &pll->clkr);
>> +       if (pll_data->flags & PLL_IS_ALPHA) {
>> +               struct clk_alpha_pll *alpha_pll =
>> +                       pll_data->a53pll.alpha_pll.pll;
>> +               struct alpha_pll_config *alpha_pll_config =
>> +                       pll_data->a53pll.alpha_pll.pll_config;
>> +
>> +               clk_alpha_pll_configure(alpha_pll, regmap, alpha_pll_config);
>> +               clkr = &pll_data->a53pll.alpha_pll.pll->clkr;
>> +       } else {
>> +               clkr = &pll_data->a53pll.pll->clkr;
>> +       }
> Sorry, the design is confusing.

The basic idea is to add support for various PLLs available to clock the 
A53 core.

if this messing up the code, can the alpha pll support be moved to a 
separate file?

It would be very helpful if you provide your input on this.

  reply	other threads:[~2020-04-22 10:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14  2:55 [PATCH V3 0/8] Add APSS clock controller support for IPQ6018 Sivaprakash Murugesan
2020-04-14  2:55 ` [PATCH V3 1/8] dt-bindings: mailbox: Add YAML schemas for QCOM APCS global block Sivaprakash Murugesan
2020-04-20 20:59   ` Rob Herring
2020-05-04  6:14     ` Sivaprakash Murugesan
2020-04-14  2:55 ` [PATCH V3 2/8] dt-bindings: clock: Add YAML schemas for QCOM A53 PLL Sivaprakash Murugesan
2020-04-20 21:01   ` Rob Herring
2020-05-04  6:13     ` Sivaprakash Murugesan
2020-04-20 21:03   ` Rob Herring
2020-04-14  2:55 ` [PATCH V3 3/8] clk: qcom: Add A53 PLL support for ipq6018 devices Sivaprakash Murugesan
2020-04-22  9:00   ` Stephen Boyd
2020-04-22 10:44     ` Sivaprakash Murugesan [this message]
2020-05-14 20:40       ` Stephen Boyd
2020-05-24  9:36         ` Sivaprakash Murugesan
2020-04-14  2:55 ` [PATCH V3 4/8] clk: qcom: Add DT bindings for ipq6018 apss clock controller Sivaprakash Murugesan
2020-04-14  2:55 ` [PATCH V3 5/8] clk: qcom: Add ipq " Sivaprakash Murugesan
2020-04-22  9:04   ` Stephen Boyd
2020-05-04  6:10     ` Sivaprakash Murugesan
2020-04-14  2:55 ` [PATCH V3 6/8] dt-bindings: mailbox: Add dt-bindings for ipq6018 apcs global block Sivaprakash Murugesan
2020-04-20 21:05   ` Rob Herring
2020-04-14  2:55 ` [PATCH V3 7/8] mailbox: qcom: Add ipq6018 apcs compatible Sivaprakash Murugesan
2020-04-14  2:55 ` [PATCH V3 8/8] arm64: dts: ipq6018: Add a53 pll and apcs clock Sivaprakash Murugesan

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=4025e5c3-b532-d235-f73b-2b86055bdde2@codeaurora.org \
    --to=sivaprak@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).