Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1460267 > unrolled thread

[PATCH v2 09/10] clk: qcom: Add .is_enabled ops for clk-alpha-pll

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 09/10] clk: qcom: Add .is_enabled ops for clk-alpha-pll Rajendra Nayak <rnayak@codeaurora.org> - 2016-08-11 10:50 +0200
    Re: [PATCH v2 09/10] clk: qcom: Add .is_enabled ops for clk-alpha-pll Stephen Boyd <sboyd@codeaurora.org> - 2016-08-24 08:30 +0200
      Re: [PATCH v2 09/10] clk: qcom: Add .is_enabled ops for clk-alpha-pll Rajendra Nayak <rnayak@codeaurora.org> - 2016-08-25 11:20 +0200

#1460267 — [PATCH v2 09/10] clk: qcom: Add .is_enabled ops for clk-alpha-pll

This would be useful in subsequent patches when the .set_rate operation
would need to identify if the PLL is actually enabled

Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
 drivers/clk/qcom/clk-alpha-pll.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 854487e..2184dc1 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -198,6 +198,23 @@ static void clk_alpha_pll_hwfsm_disable(struct clk_hw *hw)
 	wait_for_pll_disable(pll, PLL_ACTIVE_FLAG);
 }
 
+static int clk_alpha_pll_is_enabled(struct clk_hw *hw)
+{
+	int ret;
+	u32 val, off;
+	struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+
+	off = pll->offset;
+	ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, &val);
+	if (ret)
+		return ret;
+
+	if (val & PLL_LOCK_DET)
+		return 1;
+	else
+		return 0;
+}
+
 static int clk_alpha_pll_enable(struct clk_hw *hw)
 {
 	int ret;
@@ -398,6 +415,7 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw, unsigned long rate,
 const struct clk_ops clk_alpha_pll_ops = {
 	.enable = clk_alpha_pll_enable,
 	.disable = clk_alpha_pll_disable,
+	.is_enabled = clk_alpha_pll_is_enabled,
 	.recalc_rate = clk_alpha_pll_recalc_rate,
 	.round_rate = clk_alpha_pll_round_rate,
 	.set_rate = clk_alpha_pll_set_rate,
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[toc] | [next] | [standalone]

#1469100

On 08/11, Rajendra Nayak wrote:
> This would be useful in subsequent patches when the .set_rate operation
> would need to identify if the PLL is actually enabled
> 
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> ---

Hmmm I suspect I never implemented the is_enabled op because that
will happen to turn off clks during late init that shouldn't
otherwise be disabled because the framework now can see that some
PLL is enabled out of the bootloader. Is that happening now? We
really should fix the framework to make this not be a problem,
mostly by finishing off the clk handoff patches that Mike posted
a while back. But either way, I'm worried with these patches that
implement is_enabled ops.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1469995

On 08/24/2016 11:58 AM, Stephen Boyd wrote:
> On 08/11, Rajendra Nayak wrote:
>> This would be useful in subsequent patches when the .set_rate operation
>> would need to identify if the PLL is actually enabled
>>
>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>> ---
> 
> Hmmm I suspect I never implemented the is_enabled op because that
> will happen to turn off clks during late init that shouldn't
> otherwise be disabled because the framework now can see that some
> PLL is enabled out of the bootloader. Is that happening now? We
> really should fix the framework to make this not be a problem,
> mostly by finishing off the clk handoff patches that Mike posted
> a while back. But either way, I'm worried with these patches that
> implement is_enabled ops.

I did not see any, but will try and test some more to see if we indeed
run into such issues

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web