[PATCH RFT] regulator: palmas: Don't update tstep register for SMPS3 and SMPS7

[PATCH RFT] regulator: palmas: Don't update tstep register for SMPS3 and SMPS7

[Axel Lin]

SMPS3 and SMPS7 do not have tstep_addr setting, so current code actually 
writes 0 to PALMAS_SMPS12_CTRL(0x0) register when set_ramp_delay callback
is called for SMPS3 and SMPS7.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
 drivers/regulator/palmas-regulator.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index f26344e..cfa143a 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -438,6 +438,10 @@ static int palmas_smps_set_ramp_delay(struct regulator_dev *rdev,
 	unsigned int addr = palmas_regs_info[id].tstep_addr;
 	int ret;
 
+	/* SMPS3 and SMPS7 do not have tstep_addr setting */
+	if (!addr)
+		return 0;
+
 	if (ramp_delay <= 0)
 		reg = 0;
 	else if (ramp_delay < 2500)
-- 
1.7.10.4

Re: [PATCH RFT] regulator: palmas: Don't update tstep register for SMPS3 and SMPS7

[Laxman Dewangan]

On Friday 19 April 2013 09:11 AM, Axel Lin wrote:
> SMPS3 and SMPS7 do not have tstep_addr setting, so current code actually
> writes 0 to PALMAS_SMPS12_CTRL(0x0) register when set_ramp_delay callback
> is called for SMPS3 and SMPS7.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
> ---
>   drivers/regulator/palmas-regulator.c |    4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
> index f26344e..cfa143a 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -438,6 +438,10 @@ static int palmas_smps_set_ramp_delay(struct regulator_dev *rdev,
>   	unsigned int addr = palmas_regs_info[id].tstep_addr;
>   	int ret;
>   
> +	/* SMPS3 and SMPS7 do not have tstep_addr setting */
> +	if (!addr)
> +		return 0;
> +

I avoided to compare the tstep_addr because it can be 0 offset also but 
seeing TPS65913 and TPS80036 (which are palma devices),  seeing that 
valid tstep is always non-zero.
Table are populated for offset and there is base register address for 
group of the configuration like smps12_ctl offset is 0 and base is 0x120 
(TPS65913).

I think similar check need to be there in probe also as part of 
cleanups, in place of checking the reg_id, we can check the tstep.