linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taniya Das <tdas@codeaurora.org>
To: Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>
Cc: Andy Gross <andy.gross@linaro.org>,
	David Brown <david.brown@linaro.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/3] clk: qcom: rcg2: Add support for hardware control mode
Date: Tue, 30 Jul 2019 16:20:08 +0530	[thread overview]
Message-ID: <2bb31636-e7de-50e6-b4fb-826b6e7e7c04@codeaurora.org> (raw)
In-Reply-To: <20190716231845.832F82064B@mail.kernel.org>

Hello Stephen,

On 7/17/2019 4:48 AM, Stephen Boyd wrote:
> Quoting Taniya Das (2019-07-15 21:19:02)
>> Hello Stephen,
>>
>> Thanks for your review.
>>
>> On 7/16/2019 4:22 AM, Stephen Boyd wrote:
>>> Quoting Taniya Das (2019-05-08 11:24:54)
>>>> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
>>>> index 57dbac9..5bb6d45 100644
>>>> --- a/drivers/clk/qcom/clk-rcg2.c
>>>> +++ b/drivers/clk/qcom/clk-rcg2.c
>>>> @@ -289,6 +289,9 @@ static int __clk_rcg2_configure(struct clk_rcg2 *rcg, const struct freq_tbl *f)
>>>>           cfg |= rcg->parent_map[index].cfg << CFG_SRC_SEL_SHIFT;
>>>>           if (rcg->mnd_width && f->n && (f->m != f->n))
>>>>                   cfg |= CFG_MODE_DUAL_EDGE;
>>>> +       if (rcg->flags & HW_CLK_CTRL_MODE)
>>>> +               cfg |= CFG_HW_CLK_CTRL_MASK;
>>>> +
>>>
>>> Above this we have commit bdc3bbdd40ba ("clk: qcom: Clear hardware clock
>>> control bit of RCG") that clears this bit. Is it possible to always set
>>> this bit and then have an override flag used in sdm845 that says to
>>> _not_ set this bit? Presumably on earlier platforms writing the bit is a
>>> no-op so it's safe to write the bit on those platforms.
>>>
>>> This way, if it's going to be the default we can avoid setting the flag
>>> and only set the flag on older platforms where it shouldn't be done for
>>> some reason.
>>>
>>
>> Not all the subsystem clock controllers might have this hardware control
>> bit set from design. Thus we want to set them based on the flag.
> 
> Yes but what's the percentage of clks that are going to set this flag
> vs. not set this flag? If that is low right now then it's fine but if it
> eventually becomes the standard mechanism it will be easier to opt-out
> of the feature if necessary instead of opt-in.
> 

Currently all the RCGs in GCC need to clear the bit and few RCGs from
the other CCs(DISPCC/VIDEOCC) where the bit is not set from HW requires 
this bit to be set. Thus we want to use this flag mechanism to have the 
flexibility to set.

Once it is a standard we could cleanup to remove this.



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

  reply	other threads:[~2019-07-30 10:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 18:24 [PATCH v1 0/3] clk: qcom: Misc updates for Root Clock Generators Taniya Das
2019-05-08 18:24 ` [PATCH v1 1/3] clk: qcom: rcg: Return failure for RCG update Taniya Das
2019-07-15 22:52   ` Stephen Boyd
2019-05-08 18:24 ` [PATCH v1 2/3] clk: qcom: rcg2: Add support for hardware control mode Taniya Das
2019-07-15 22:52   ` Stephen Boyd
2019-07-16  4:19     ` Taniya Das
2019-07-16 23:18       ` Stephen Boyd
2019-07-30 10:50         ` Taniya Das [this message]
2019-07-30 15:38           ` Stephen Boyd
2019-05-08 18:24 ` [PATCH v1 3/3] clk: qcom: rcg: update the DFS macro for RCG Taniya Das
2019-05-09 17:27   ` Stephen Boyd
2019-05-10  2:58     ` Taniya Das
2019-05-10 17:54       ` Stephen Boyd
2019-05-13  3:44         ` Taniya Das
2019-07-15 22:44           ` Stephen Boyd
2019-07-16  4:22             ` Taniya Das
2019-07-16 23:22               ` Stephen Boyd
2019-07-30 10:51                 ` Taniya Das
2019-07-30 15:40                   ` Stephen Boyd

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=2bb31636-e7de-50e6-b4fb-826b6e7e7c04@codeaurora.org \
    --to=tdas@codeaurora.org \
    --cc=andy.gross@linaro.org \
    --cc=david.brown@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rnayak@codeaurora.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).