lkml.org 
[lkml]   [2014]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe:Re: [PATCH 06/12] clk: mmp: add mmp private gate clock


At 2014-09-04 01:55:37, "Mike Turquette" <mturquette@linaro.org> wrote:
>Quoting Chao Xie (2014-08-25 21:38:18)
>> From: Chao Xie <chao.xie@marvell.com>
>>
>> Some SOCes have this kind of the gate clock
>> 1. There are some bits to control the gate not only one bit.
>> 2. Some clocks has operations of "out of reset" and "enable".
>> To enable clock, we need do "out of reset" and "enable".
>> To disable clock, we may not need "set to reset". It depends
>> on the SOCes' design.
>
>Are there any other IP blocks affected by the "out of reset" and "set to
>reset" states? I wonder if you might benefit from the reset controller
>framework? For example see,
>
>drivers/clk/qcom/gcc-apq8084.c
>
><snip>

>
Thanks to point it out.
To use the reset framework, there are some problem.
1. the reset bit is combined with the clocks disable/enable bits in same register. Seperating setting them means spinlock
protection and 2 operations for read-update the bits.


except that, i think reset framework can bring some benefits.


Even without the reset bit, we still need the gate clocks.
The enable/disable is not a bit operation, and it is bits operation for some devices.
In fact i want to use it to replace the old clk-apbc and clk-apmu clocks.

>> +static int mmp_clk_gate_enable(struct clk_hw *hw)
>> +{
>> + struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
>> + struct clk *clk = hw->clk;
>> + unsigned long flags = 0;
>> + unsigned long rate;
>> + u32 tmp;
>> +
>> + if (gate->lock)
>> + spin_lock_irqsave(gate->lock, flags);
>> +
>> + tmp = readl(gate->reg);
>> + tmp &= ~gate->mask;
>> + tmp |= gate->val_enable;
>> + writel(tmp, gate->reg);
>> +
>> + if (gate->lock)
>> + spin_unlock_irqrestore(gate->lock, flags);
>> +
>> + if (gate->flags & MMP_CLK_GATE_NEED_DELAY) {
>> + rate = __clk_get_rate(clk);
>> + /* Need delay 2 cycles. */
>> + udelay(2000000/rate);
>
>How long are these delays? Long enough to warrant using clk_prepare
>instead of clk_enable? Are these clocks enabled from interrupt context?

>
For power optimization, some clocks need to be enabled/disable in interrupt context.
The worst delay is rate=32KHZ, so the delay is 62.5us.

>Regards,
>Mike


\
 
 \ /
  Last update: 2014-09-04 06:41    [W:0.116 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site