public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan@nvidia.com>
To: Axel Lin <axel.lin@ingics.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Graeme Gregory <gg@slimlogic.co.uk>,
	Liam Girdwood <lgirdwood@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFT] regulator: palmas: Fix off-by-one for ramp_delay and register value mapping
Date: Mon, 22 Apr 2013 14:45:47 +0530	[thread overview]
Message-ID: <5174FFC3.70603@nvidia.com> (raw)
In-Reply-To: <1366563522.10770.1.camel@phoenix>

On Sunday 21 April 2013 10:28 PM, Axel Lin wrote:
> In probe(), we have below code to set ramp_delay:
> e.g. When reg is 2, current code set
> pmic->desc[id].ramp_delay = palmas_smps_ramp_delay[reg & 0x3];
>                            = 5000
> which means ramp_delay = 5000 is mapping to reg value = 2;
>
> However, in palmas_smps_set_ramp_delay()
>          ramp_delay = 5000 is mapping to reg value = 1.
>
> This patch fixes the off-by-one value range checking for ramp_delay in
> palmas_smps_set_ramp_delay().
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
> ---
> Hi Laxman,
> I don't have the datasheet, so please check if this fix is correct.
>
> Thanks,
> Axel
>   drivers/regulator/palmas-regulator.c |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
> index 8fed60c..e3e8373 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -447,9 +447,9 @@ static int palmas_smps_set_ramp_delay(struct regulator_dev *rdev,
>   
>   	if (ramp_delay <= 0)
>   		reg = 0;
> -	else if (ramp_delay < 2500)
> +	else if (ramp_delay <= 2500)From 6f6875db93eeff52d39623dd68522e1875cf5ef1 Mon Sep 17 00:00:00 2001
> From: Axel Lin <axel.lin@ingics.com>
> Date: Mon, 22 Apr 2013 00:50:55 +0800
> Subject: [PATCH RFT] regulator: palmas: Fix off-by-one for ramp_delay and register value mapping
>
> In probe(), we have below code to set ramp_delay:
> e.g. When reg is 2, current code set
> pmic->desc[id].ramp_delay = palmas_smps_ramp_delay[reg & 0x3];
>                            = 5000
> which means ramp_delay = 5000 is mapping to reg value = 2;
>
> However, in palmas_smps_set_ramp_delay()
>          ramp_delay = 5000 is mapping to reg value = 1.
>
> This patch fixes the off-by-one value range checking for ramp_delay in
> palmas_smps_set_ramp_delay().
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
> ---
> Hi Laxman,
> I don't have the datasheet, so please check if this fix is correct.
>

Datasheet says:
Time Step (TSTEP) selection, when changing the
output voltage, the new value is reached through
successive voltage steps (if not bypassed). The
equivalent programmable slew rate of the output
voltage is:
TSTEP[1:0]: 00 Jump (no slope control)
TSTEP[1:0]: 01 10mV/us
TSTEP[1:0]: 10 5mV/us (default)
TSTEP[1:0]: 11 2.5mV/us


      reply	other threads:[~2013-04-22  9:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-21 16:58 [PATCH RFT] regulator: palmas: Fix off-by-one for ramp_delay and register value mapping Axel Lin
2013-04-22  9:15 ` Laxman Dewangan [this message]

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=5174FFC3.70603@nvidia.com \
    --to=ldewangan@nvidia.com \
    --cc=axel.lin@ingics.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=gg@slimlogic.co.uk \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.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