linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] [CPUFREQ] s3c64xx: Add VDDINT voltage scaling
Date: Mon, 05 Dec 2011 19:45:43 +0100	[thread overview]
Message-ID: <2739091.DkZC0oOhCv@flatron> (raw)
In-Reply-To: <1323109322-24130-2-git-send-email-broonie@opensource.wolfsonmicro.com>

On Monday 05 of December 2011 18:22:02 Mark Brown wrote:
> Save a bit more power by scaling VDDINT as well as VDDARM when we have a
> regulator for it. Don't worry too much if we don't have one, and just log
> errors when scaling as they're unlikely to happen in practice without the
> system being in great trouble and proper handling would complicate the
> code quite a bit.
> 
> The documentation on the operating points is somewhat patchy but I've been
> running happily on my systems with the current set of values which is
> cobbled together from what I have. One possible issue is that systems
> which run with ARMCLK in sync mode seem to need a higher VDDINT. However
> these systems would need to explicitly hook up the VDDINT regulator so
> the risk to them should be low; I don't have such a system to test on.

I would oppose here. According to my information, VDDint depends on peripheral 
clock frequencies not ARM frequency and it should be 1.25V (min 1.15, max 1.3) 
for HCLK at 133 MHz and 1.05V (min 0.95, max 1.3) for HCLK running at 66 MHz.

Anyway, the behavior will probably vary from board to board, so I would rather 
think about extending s3c64xx-cpufreq driver to allow per board 
frequency/voltage configuration., which would also include settings optimized 
for your boards in their board-specific code.

This would also solve a major problem of current s3c64xx-cpufreq 
implementation, namely crashing boards running in synchronous mode, because of 
odd frequencies specified, like 200 MHz (achievable with PLL set to 800 MHz), 
while the requirement is to keep the ARM frequency a multiple of HCLK when 
running synchronously.

I have two boards running in synchronous mode (Samsung Galaxy GT-i5700 phone 
and FriendlyARM Tiny6410 board), I might be able to test things related to 
synchronous mode.

> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  drivers/cpufreq/s3c64xx-cpufreq.c |   33 
++++++++++++++++++++++++++++-----
>  1 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c
> b/drivers/cpufreq/s3c64xx-cpufreq.c index a5e72cb..ca1a249 100644
> --- a/drivers/cpufreq/s3c64xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c64xx-cpufreq.c
> @@ -21,20 +21,22 @@
> 
>  static struct clk *armclk;
>  static struct regulator *vddarm;
> +static struct regulator *vddint;
>  static unsigned long regulator_latency;
> 
>  #ifdef CONFIG_CPU_S3C6410
>  struct s3c64xx_dvfs {
>  	unsigned int vddarm_min;
>  	unsigned int vddarm_max;
> +	unsigned int vddint_min;
>  };
> 
>  static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = {
> -	[0] = { 1000000, 1150000 },
> -	[1] = { 1050000, 1150000 },
> -	[2] = { 1100000, 1150000 },
> -	[3] = { 1200000, 1350000 },
> -	[4] = { 1300000, 1350000 },
> +	[0] = { 1000000, 1150000, 1050000 },
> +	[1] = { 1050000, 1150000, 1150000 },
> +	[2] = { 1100000, 1150000, 1200000 },
> +	[3] = { 1200000, 1350000, 1200000 },
> +	[4] = { 1300000, 1350000, 1200000 },
>  };
> 
>  static struct cpufreq_frequency_table s3c64xx_freq_table[] = {
> @@ -107,6 +109,16 @@ static int s3c64xx_cpufreq_set_target(struct
> cpufreq_policy *policy, freqs.new, ret);
>  			goto err;
>  		}
> +
> +		if (vddint) {
> +			ret = regulator_set_voltage(vddint,
> +						    dvfs->vddint_min,
> +						    13500000);
> +			if (ret != 0) {
> +				pr_err("Failed to set VDDINT for %dkHz: %d\n",
> +				       freqs.new, ret);
> +			}
> +		}
>  	}
>  #endif
> 
> @@ -129,6 +141,16 @@ static int s3c64xx_cpufreq_set_target(struct
> cpufreq_policy *policy, freqs.new, ret);
>  			goto err_clk;
>  		}
> +
> +		if (vddint) {
> +			ret = regulator_set_voltage(vddint,
> +						    dvfs->vddint_min,
> +						    13500000);
> +			if (ret != 0) {
> +				pr_err("Failed to set VDDINT for %dkHz: %d\n",
> +				       freqs.new, ret);
> +			}
> +		}
>  	}
>  #endif
> 
> @@ -259,6 +281,7 @@ static int s3c64xx_cpufreq_driver_init(struct
> cpufreq_policy *policy) if (ret != 0) {
>  		pr_err("Failed to configure frequency table: %d\n",
>  		       ret);
> +		regulator_put(vddint);
>  		regulator_put(vddarm);
>  		clk_put(armclk);
>  	}

  reply	other threads:[~2011-12-05 18:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05 18:22 [PATCH 1/2] [CPUFREQ] s3c64xx: Use pr_fmt() for consistent log messages Mark Brown
2011-12-05 18:22 ` [PATCH 2/2] [CPUFREQ] s3c64xx: Add VDDINT voltage scaling Mark Brown
2011-12-05 18:45   ` Tomasz Figa [this message]
2011-12-05 18:57     ` Mark Brown
2011-12-05 19:11       ` Tomasz Figa
2011-12-05 19:25         ` Mark Brown
2011-12-05 19:45           ` Tomasz Figa
2011-12-05 19:50             ` Mark Brown

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=2739091.DkZC0oOhCv@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).