All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Thomas Abraham <ta.omasab@gmail.com>, cpufreq@vger.kernel.org
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, t.figa@samsung.com,
	kgene.kim@samsung.com, shawn.guo@linaro.org,
	viresh.kumar@linaro.org
Subject: Re: [PATCH 1/6] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
Date: Sun, 12 Jan 2014 14:39:48 +0100	[thread overview]
Message-ID: <52D29B24.3070601@gmail.com> (raw)
In-Reply-To: <1389283165-17708-2-git-send-email-thomas.ab@samsung.com>

Hi Thomas,

Please see my comments inline.

On 09.01.2014 16:59, Thomas Abraham wrote:
[snip]
> @@ -69,12 +71,26 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
>   		 new_freq / 1000, volt ? volt / 1000 : -1);
>
>   	/* scaling up?  scale voltage before frequency */
> -	if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
> +	if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
> +				new_freq >= safe_frequency) {
>   		ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
>   		if (ret) {
>   			pr_err("failed to scale voltage up: %d\n", ret);
>   			return ret;
>   		}
> +	} else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
> +		/*
> +		 * the scaled up voltage level for the new_freq is lower
> +		 * than the safe voltage level. so set safe_voltage
> +		 * as the intermediate voltage level and revert it
> +		 * back after the frequency has been changed.
> +		 */
> +		ret = regulator_set_voltage(cpu_reg, safe_voltage,
> +						safe_voltage);

Shouldn't the tolerance be used here as well?

> +		if (ret) {
> +			pr_err("failed to set safe voltage: %d\n", ret);
> +			return ret;
> +		}
>   	}
>
>   	ret = clk_set_rate(cpu_clk, freq_exact);
> @@ -94,6 +110,19 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
>   		}
>   	}
>
> +	/*
> +	 * if safe voltage was applied during voltage scale up, then set
> +	 * the correct target voltage now.
> +	 */
> +	if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
> +					new_freq < safe_frequency) {
> +		ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> +		if (ret) {
> +			pr_err("failed to scale voltage up: %d\n", ret);
> +			return ret;
> +		}
> +	}
> +

I believe that it would be enough to reuse the if block of scaling down 
instead of repeating the same code, just the condition must be slightly 
modified:

-	/* scaling down?  scale voltage after frequency */
-	if (!IS_ERR(cpu_reg) && new_freq < old_freq) {
+	/*
+	 * scaling down or below safe frequency?
+	 * scale voltage after frequency
+	 */
+	if (!IS_ERR(cpu_reg)
+	    && (new_freq < old_freq || new_freq < safe_frequency)) {

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
Date: Sun, 12 Jan 2014 14:39:48 +0100	[thread overview]
Message-ID: <52D29B24.3070601@gmail.com> (raw)
In-Reply-To: <1389283165-17708-2-git-send-email-thomas.ab@samsung.com>

Hi Thomas,

Please see my comments inline.

On 09.01.2014 16:59, Thomas Abraham wrote:
[snip]
> @@ -69,12 +71,26 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
>   		 new_freq / 1000, volt ? volt / 1000 : -1);
>
>   	/* scaling up?  scale voltage before frequency */
> -	if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
> +	if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
> +				new_freq >= safe_frequency) {
>   		ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
>   		if (ret) {
>   			pr_err("failed to scale voltage up: %d\n", ret);
>   			return ret;
>   		}
> +	} else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
> +		/*
> +		 * the scaled up voltage level for the new_freq is lower
> +		 * than the safe voltage level. so set safe_voltage
> +		 * as the intermediate voltage level and revert it
> +		 * back after the frequency has been changed.
> +		 */
> +		ret = regulator_set_voltage(cpu_reg, safe_voltage,
> +						safe_voltage);

Shouldn't the tolerance be used here as well?

> +		if (ret) {
> +			pr_err("failed to set safe voltage: %d\n", ret);
> +			return ret;
> +		}
>   	}
>
>   	ret = clk_set_rate(cpu_clk, freq_exact);
> @@ -94,6 +110,19 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
>   		}
>   	}
>
> +	/*
> +	 * if safe voltage was applied during voltage scale up, then set
> +	 * the correct target voltage now.
> +	 */
> +	if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
> +					new_freq < safe_frequency) {
> +		ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> +		if (ret) {
> +			pr_err("failed to scale voltage up: %d\n", ret);
> +			return ret;
> +		}
> +	}
> +

I believe that it would be enough to reuse the if block of scaling down 
instead of repeating the same code, just the condition must be slightly 
modified:

-	/* scaling down?  scale voltage after frequency */
-	if (!IS_ERR(cpu_reg) && new_freq < old_freq) {
+	/*
+	 * scaling down or below safe frequency?
+	 * scale voltage after frequency
+	 */
+	if (!IS_ERR(cpu_reg)
+	    && (new_freq < old_freq || new_freq < safe_frequency)) {

Best regards,
Tomasz

  parent reply	other threads:[~2014-01-12 13:39 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 15:59 [PATCH 0/6] cpufreq: use cpufreq-cpu0 driver for exynos4210 based platforms Thomas Abraham
2014-01-09 15:59 ` Thomas Abraham
2014-01-09 15:59 ` [PATCH 1/6] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions Thomas Abraham
2014-01-09 15:59   ` Thomas Abraham
2014-01-10 12:03   ` Lukasz Majewski
2014-01-10 12:03     ` Lukasz Majewski
2014-01-12 13:39   ` Tomasz Figa [this message]
2014-01-12 13:39     ` Tomasz Figa
2014-01-13  3:14   ` Shawn Guo
2014-01-13  3:14     ` Shawn Guo
2014-01-13 14:21     ` Thomas Abraham
2014-01-13 14:21       ` Thomas Abraham
2014-01-13 14:28       ` Shawn Guo
2014-01-13 14:28         ` Shawn Guo
2014-01-09 15:59 ` [PATCH 2/6] clk: samsung: add infrastructure to register CPU clocks Thomas Abraham
2014-01-09 15:59   ` Thomas Abraham
2014-01-10 12:04   ` Lukasz Majewski
2014-01-10 12:04     ` Lukasz Majewski
2014-01-10 12:19     ` Thomas Abraham
2014-01-10 12:19       ` Thomas Abraham
2014-01-10 13:25       ` Lukasz Majewski
2014-01-10 13:25         ` Lukasz Majewski
2014-01-11  4:43         ` Thomas Abraham
2014-01-11  4:43           ` Thomas Abraham
2014-01-12  1:47           ` Tomasz Figa
2014-01-12  1:47             ` Tomasz Figa
2014-01-12  8:04             ` Lukasz Majewski
2014-01-12  8:04               ` Lukasz Majewski
2014-01-13 13:15             ` Thomas Abraham
2014-01-13 13:15               ` Thomas Abraham
2014-01-09 15:59 ` [PATCH 3/6] clk: samsung: register cpu clock provider for exynos4210 SoC Thomas Abraham
2014-01-09 15:59   ` Thomas Abraham
2014-01-10 12:04   ` Lukasz Majewski
2014-01-10 12:04     ` Lukasz Majewski
2014-01-10 12:37     ` Thomas Abraham
2014-01-10 12:37       ` Thomas Abraham
2014-01-10 14:18       ` Lukasz Majewski
2014-01-10 14:18         ` Lukasz Majewski
2014-01-11  5:25         ` Thomas Abraham
2014-01-11  5:25           ` Thomas Abraham
2014-01-12  2:19           ` Tomasz Figa
2014-01-12  2:19             ` Tomasz Figa
2014-01-12  8:23             ` Lukasz Majewski
2014-01-12  8:23               ` Lukasz Majewski
2014-01-12 12:05               ` Tomasz Figa
2014-01-12 12:05                 ` Tomasz Figa
2014-01-12 12:41                 ` Lukasz Majewski
2014-01-12 12:41                   ` Lukasz Majewski
2014-01-12 12:58                   ` Tomasz Figa
2014-01-12 12:58                     ` Tomasz Figa
2014-01-13 14:12                     ` Thomas Abraham
2014-01-13 14:12                       ` Thomas Abraham
2014-01-13 14:07             ` Thomas Abraham
2014-01-13 14:07               ` Thomas Abraham
2014-01-09 15:59 ` [PATCH 4/6] cpufreq: exynos: remove Exynos4210 specific cpufreq driver support Thomas Abraham
2014-01-09 15:59   ` Thomas Abraham
2014-01-10 10:20   ` Lukasz Majewski
2014-01-10 10:20     ` Lukasz Majewski
2014-01-09 15:59 ` [PATCH 5/6] arm: exynos4-dt: statically add platform device for cpufreq-cpu0 platform driver Thomas Abraham
2014-01-09 15:59   ` Thomas Abraham
2014-01-10 10:23   ` Lukasz Majewski
2014-01-10 10:23     ` Lukasz Majewski
2014-01-13  3:17   ` Shawn Guo
2014-01-13  3:17     ` Shawn Guo
2014-01-09 15:59 ` [PATCH 6/6] arm: dts: add cpu nodes for Exynos4210 SoC Thomas Abraham
2014-01-09 15:59   ` Thomas Abraham
2014-01-10 10:32   ` Lukasz Majewski
2014-01-10 10:32     ` Lukasz Majewski
2014-01-10 12:06     ` Thomas Abraham
2014-01-10 12:06       ` Thomas Abraham
2014-01-10 10:32 ` [PATCH 0/6] cpufreq: use cpufreq-cpu0 driver for exynos4210 based platforms Lukasz Majewski
2014-01-10 10:32   ` Lukasz Majewski
2014-01-10 11:59   ` Thomas Abraham
2014-01-10 11:59     ` Thomas Abraham
2014-01-12  2:26     ` Tomasz Figa
2014-01-12  2:26       ` Tomasz Figa
2014-01-13 14:27       ` Thomas Abraham
2014-01-13 14:27         ` Thomas Abraham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52D29B24.3070601@gmail.com \
    --to=tomasz.figa@gmail.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=shawn.guo@linaro.org \
    --cc=t.figa@samsung.com \
    --cc=ta.omasab@gmail.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.