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, 24 May 2018 10:00:40 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock
 source

On 23-05-18, 19:00, Dmitry Osipenko wrote:
> PLL_C is running at 600MHz which is significantly higher than the 216MHz
> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
> running on that PLL. Let's use PLL_C as intermediate clock source, making
> CPU snappier a tad during of the frequency transition.
> 
> Signed-off-by: Dmitry Osipenko <digetx@...il.com>
> ---
>  drivers/cpufreq/tegra20-cpufreq.c | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra20-cpufreq.c b/drivers/cpufreq/tegra20-cpufreq.c
> index 3ad6bded6efc..4bf5ba7da40b 100644
> --- a/drivers/cpufreq/tegra20-cpufreq.c
> +++ b/drivers/cpufreq/tegra20-cpufreq.c
> @@ -25,12 +25,13 @@
>  #include <linux/types.h>
>  
>  #define PLL_P_FREQ	216000
> +#define PLL_C_FREQ	600000
>  
>  static struct cpufreq_frequency_table freq_table[] = {
>  	{ .frequency = 216000 },
>  	{ .frequency = 312000 },
>  	{ .frequency = 456000 },
> -	{ .frequency = 608000 },
> +	{ .frequency = 600000 },
>  	{ .frequency = 760000 },
>  	{ .frequency = 816000 },
>  	{ .frequency = 912000 },
> @@ -44,6 +45,7 @@ struct tegra20_cpufreq {
>  	struct clk *cpu_clk;
>  	struct clk *pll_x_clk;
>  	struct clk *pll_p_clk;
> +	struct clk *pll_c_clk;
>  	bool pll_x_prepared;
>  };
>  
> @@ -58,7 +60,10 @@ static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
>  	if (index == 0 || policy->cur == PLL_P_FREQ)
>  		return 0;
>  
> -	return PLL_P_FREQ;
> +	if (index == 3 || policy->cur == PLL_C_FREQ)
> +		return 0;

So we can choose between two different intermediate frequencies ? And
I didn't like the way magic number 3 is used here. Its prone to errors
and we better use a macro or something else here.

Like instead of doing index == 3, what about freq_table[index].freq ==
PLL_C_FREQ ? Same for the previous patch as well.

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ