linux-kernel - Re: [PATCH 7/9] clk: sunxi-ng: mux: Add clk notifier functions

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:	Wed, 27 Jul 2016 15:32:58 +0800
From:	Chen-Yu Tsai <wens@...e.org>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	Chen-Yu Tsai <wens@...e.org>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>, dev <dev@...ux-sunxi.org>,
	linux-clk <linux-clk@...r.kernel.org>,
	devicetree <devicetree@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/9] clk: sunxi-ng: mux: Add clk notifier functions

On Wed, Jul 27, 2016 at 3:30 PM, Maxime Ripard
<maxime.ripard@...e-electrons.com> wrote:
> On Tue, Jul 26, 2016 at 03:04:29PM +0800, Chen-Yu Tsai wrote:
>> On sunxi we support cpufreq by changing the clock rate of PLL-CPU.
>> It's possible the clock output of the PLL goes out of the CPU's
>> operational limits when the PLL's multipliers / dividers are changed
>> and it hasn't stabilized yet. This would result in the CPU hanging.
>>
>> To circumvent this, we temporarily switch the CPU mux clock to another
>> stable clock before the rate change, and switch it back after the PLL
>> stabilizes. This is done with clk notifiers registered on the PLL.
>>
>> This patch adds common functions for notifiers to reparent mux clocks.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
>> ---
>>  drivers/clk/sunxi-ng/ccu_mux.c | 36 ++++++++++++++++++++++++++++++++++++
>>  drivers/clk/sunxi-ng/ccu_mux.h | 14 ++++++++++++++
>>  2 files changed, 50 insertions(+)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
>> index f96eabb5d1f3..8a6e9065cb85 100644
>> --- a/drivers/clk/sunxi-ng/ccu_mux.c
>> +++ b/drivers/clk/sunxi-ng/ccu_mux.c
>> @@ -8,7 +8,9 @@
>>   * the License, or (at your option) any later version.
>>   */
>>
>> +#include <linux/clk.h>
>>  #include <linux/clk-provider.h>
>> +#include <linux/delay.h>
>>
>>  #include "ccu_gate.h"
>>  #include "ccu_mux.h"
>> @@ -199,3 +201,37 @@ const struct clk_ops ccu_mux_ops = {
>>       .determine_rate = __clk_mux_determine_rate,
>>       .recalc_rate    = ccu_mux_recalc_rate,
>>  };
>> +
>> +/*
>> + * This clock notifier is called when the frequency of the of the parent
>> + * PLL clock is to be changed. The idea is to switch the parent to a
>> + * stable clock, such as the main oscillator, while the PLL frequency
>> + * stabilizes.
>> + */
>> +static int ccu_mux_notifier_cb(struct notifier_block *nb,
>> +                            unsigned long event, void *data)
>> +{
>> +     struct ccu_mux_nb *mux = to_ccu_mux_nb(nb);
>> +     int ret = 0;
>> +
>> +     if (event == PRE_RATE_CHANGE) {
>> +             mux->original_index = ccu_mux_helper_get_parent(mux->common,
>> +                                                             mux->cm);
>> +             ret = ccu_mux_helper_set_parent(mux->common, mux->cm,
>> +                                             mux->bypass_index);
>> +     } else if (event == POST_RATE_CHANGE) {
>> +             ret = ccu_mux_helper_set_parent(mux->common, mux->cm,
>> +                                             mux->original_index);
>> +     }
>> +
>> +     udelay(mux->delay_us);
>
> Are you sure we need that delay?
>
> set_rate will end and notify you once the PLL rate is stable, so it
> looks redundant.

The delay requirement is on the cpu mux clk, not the PLL. The
datasheet says you should wait for up to 8 clock cycles after
changing the parent. Not sure how this factors with the CPU
actually doing the waiting though.

So this is separate from the PLL lock delay.

ChenYu