Thread (13 messages) 13 messages, 5 authors, 2012-10-11

[PATCH 2/3] clk: ux500: Support prcmu ape opp voltage clock

From: Ulf Hansson <hidden>
Date: 2012-09-27 07:43:35
Also in: lkml

Hi Mike,

On 26 September 2012 21:25, Mike Turquette [off-list ref] wrote:
Quoting Ulf Hansson (2012-09-25 00:56:56)
quoted
Hi Mike,

Thanks for your input!

On 24 September 2012 17:35, Mike Turquette [off-list ref] wrote:
quoted
Quoting Ulf Hansson (2012-09-24 07:43:18)
quoted
From: Ulf Hansson <redacted>

Some scalable prcmu clocks needs to be handled in conjuction with the
ape opp 100 voltage. A new prcmu clock type clk_prcmu_opp_volt_scalable
is implemented to handle this.

Signed-off-by: Ulf Hansson <redacted>
---
 drivers/clk/ux500/clk-prcmu.c |   55 +++++++++++++++++++++++++++++++++++++++++
 drivers/clk/ux500/clk.h       |    6 +++++
 2 files changed, 61 insertions(+)
diff --git a/drivers/clk/ux500/clk-prcmu.c b/drivers/clk/ux500/clk-prcmu.c
index 930cdfe..04577ca 100644
--- a/drivers/clk/ux500/clk-prcmu.c
+++ b/drivers/clk/ux500/clk-prcmu.c
@@ -133,6 +133,40 @@ out_error:
                hw->init->name);
 }

+static int clk_prcmu_opp_volt_prepare(struct clk_hw *hw)
+{
+       int err;
+       struct clk_prcmu *clk = to_clk_prcmu(hw);
+
+       err = prcmu_request_ape_opp_100_voltage(true);
+       if (err) {
+               pr_err("clk_prcmu: %s failed to request APE OPP VOLT for %s.\n",
+                       __func__, hw->init->name);
+               return err;
+       }
+
+       err = prcmu_request_clock(clk->cg_sel, true);
+       if (err)
+               prcmu_request_ape_opp_100_voltage(false);
+
+       return err;
+}
+
+static void clk_prcmu_opp_volt_unprepare(struct clk_hw *hw)
+{
+       struct clk_prcmu *clk = to_clk_prcmu(hw);
+
+       if (prcmu_request_clock(clk->cg_sel, false))
+               goto out_error;
+       if (prcmu_request_ape_opp_100_voltage(false))
+               goto out_error;
+       return;
+
+out_error:
+       pr_err("clk_prcmu: %s failed to disable %s.\n", __func__,
+               hw->init->name);
+}
Hello Ulf,

I was hoping to use the rate-change notifiers for voltage scaling, as in
my clk reentrancy/dvfs RFCs.  Using prepare/unprepare to set voltage for
non-scalable clocks is probably OK; do you plan to scale voltage when
your clocks change rate?  If so then you will need more than just
prepare/unprepare.
I see, you have a good point here. Although right now this clock will
never change rate except during "init". Prepare/unprepare is thus
enough.

For the u8500 platform the sdmmc clock is the parent for all the
mmc/sd/sdio controllers. So, to no introduce a very complex
clockhandling mechanism (using rate-change notifiers would help a bit,
but is not enough), the clock is not supposed to be changed after
init. Proper dividing of the clock is handled internally by each
controller instead.
The internal dividers could be modeled as clk nodes, which themselves
could have notifier handlers that scale voltage.  So perhaps the MMC
controller driver for your platform should define the appropriate leaf
clks?
I am not sure I completely follow you here, but let me try to answer
your suggestions.
The internal dividers are supposed to be handled only by the mmc host
driver since it is IP specific. I don't think it is viable to add
another clock type/node for this, but maybe that is not what you are
suggesting either. :-)

In my case for ux500 we use the mmci host driver. It is an ARM cross
SoC device driver, and I believe adding clock notifiers in the driver
to handle the voltage scale would complicate things quite a bit. It
seems a lot easier to let the clock driver handle this, especially
since the frequency will remain fixed after initialization. So in the
end I see now need and benefit for adding the clock notifiers in the
mmci host driver.

Kind regards
Ulf Hansson
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help