linux-kernel - Re:Re: [PATCH 06/12] clk: mmp: add mmp private gate clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Sep 2014 12:02:11 +0800 (CST)
From:	"Chao Xie" <xiechao_mail@....com>
To:	"Mike Turquette" <mturquette@...aro.org>
Cc:	"Chao Xie" <chao.xie@...vell.com>, haojian.zhuang@...il.com,
	haojian.zhuang@...aro.org, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH 06/12] clk: mmp: add mmp private gate clock



At 2014-09-04 01:55:37, "Mike Turquette" <mturquette@...aro.org> wrote:
>Quoting Chao Xie (2014-08-25 21:38:18)
>> From: Chao Xie <chao.xie@...vell.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