All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Keerthy <j-keerthy@ti.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-omap@vger.kernel.org
Subject: Re: Palmas regulator broken (was Re: [PATCH] ARM: tegra: TN7: relax some regulators)
Date: Fri, 20 Jun 2014 08:54:54 -0500	[thread overview]
Message-ID: <20140620135454.GA10566@kahuna> (raw)
In-Reply-To: <20140620132310.GA11936@kahuna>

On 08:23-20140620, Nishanth Menon wrote:
> + l-o,
> 	http://marc.info/?t=140316427500004&r=1&w=2 full thread
> 
> Minor change in subject to indicate palmas regulator fail
> 
> On 18:49-20140620, Alexandre Courbot wrote:
> > On 06/20/2014 06:41 PM, Mark Brown wrote:
> > >* PGP Signed by an unknown key
> > >
> > >On Fri, Jun 20, 2014 at 03:44:46PM +0900, Alexandre Courbot wrote:
> > >
> > >>dbabd624d
> > >>regulator: palmas: Reemove open coded functions with helper functions
> > >
> > >>Keerthy, Nishanth, could it be that there is still something wrong with the
> > >>REGULATOR_LINEAR_RANGE() definitions?
> > >
> > >>This seems to be the cause for our trouble, but the other questions might
> > >>still stand, in case there is interest in discussing them.
> > >
> > >There was a bug fix to the Palmas driver which just went to Linus the
> > >other day, are you sure this isn't fixed in mainline (or -next, it's
> > >been in -next for a week or something)?
> > 
> > If you are talking about
> > 
> > 6b7f2d82d5
> > regulator: palmas: Fix SMPS list for 0V
> > 
> > then it is in my tree. There is actually no difference on
> > palmas-regulator.c between my tree and the current -next (or Linus'
> > tree for that instance).
> > 
> > So it seems to be something else we are dealing with here.
> 
> Your quote earlier in the thread
> "
> _regulator_is_enabled() *also* returns false
> "
> 
> Got me curious. Looking at the patch:
> dbabd624d4eec50b623bab070d1e39a854b2d65c (regulator: palmas: Reemove
> open coded functions with helper functions)
> I noticed the following change
> palmas_is_enabled_smps -> regulator_is_enabled_regmap
> 
> So I decided to search for enable_reg in palmas-regulator.c and I think
> it needs valid enable_reg, mask, value for regulator_is_enabled_regmap to work
> :).
> 
> Maybe to be sure, we could print the following:
> PALMAS_SMPS8_VOLTAGE, PALMAS_SMPS8_CTRL, PALMAS_SMPS8_TSTEP,
> 
> Anyways, I quickly boot tested the following on DRA7evm (which also uses Palmas):
> [    1.933939] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.944210] smps123: 850 <--> 1250 mV at 1060 mV 
> [    1.950717] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.960754] smps45: 850 <--> 1150 mV at 1060 mV 
> [    1.967048] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.977072] smps6: 850 <--> 1650 mV at 1060 mV 
> [    1.983077] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.992994] smps7: 850 <--> 1030 mV at 1030 mV 
> [    1.999238] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    2.009161] smps8: 850 <--> 1250 mV at 1060 mV 
> [    2.015304] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> 
> It does seem to me that either set_mode also should use core functions
> OR you still need a palmas specific is_enable, enable/disable functions
> (contrary to the claim of the patch in question - which I think
>  introduced regressions).
> 
> Otherwise, completely untested diff below - can you  give this a shot?
> 
> diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
> index b982f0f..bbfe22f 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -964,6 +964,20 @@ static int palmas_regulators_probe(struct platform_device *pdev)
>  				return ret;
>  			pmic->current_reg_mode[id] = reg &
>  					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
> +
> +			dev_err(&pdev->dev, "enable_reg = 0x%02x, mask =0x%02x\n",
> +				pmic->desc[id].enable_reg,
> +				pmic->desc[id].enable_mask);
> +			pmic->desc[id].enable_reg =
> +					PALMAS_BASE_TO_REG(PALMAS_LDO_BASE,
> +						palmas_regs_info[id].ctrl_addr);
> +			pmic->desc[id].enable_mask =
> +					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
> +			/*
> +			 * The following completely ignores
> +			 * pmic->current_reg_mode[id] (set_mode)
> +			 */
> +			pmic->desc[id].enable_val = SMPS_CTRL_MODE_ON;
>  		}
>  
>  		pmic->desc[id].type = REGULATOR_VOLTAGE;

rev 2 of the diff - this does depened on the fact that regulator_desc is
not memdup-ed by regulator code - that lets us do a bit of a trickery ;)
- and I dropped the prints.. Unrelated: This makes me wonder why
palmas_is_enabled_ldo at all?

Keerthy, Mark,
what do you think of the following (esp the flip of desc value):
diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index b982f0f..f01d9c5 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -299,7 +299,7 @@ static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
 	struct palmas_pmic *pmic = rdev_get_drvdata(dev);
 	int id = rdev_get_id(dev);
 	unsigned int reg;
-	bool rail_enable = true;
+	bool rail_enable = true, enable_val = true;
 
 	palmas_smps_read(pmic->palmas, palmas_regs_info[id].ctrl_addr, &reg);
 	reg &= ~PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
@@ -318,6 +318,7 @@ static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
 		reg |= SMPS_CTRL_MODE_PWM;
 		break;
 	default:
+		enable_val = false;
 		return -EINVAL;
 	}
 
@@ -325,6 +326,11 @@ static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
 	if (rail_enable)
 		palmas_smps_write(pmic->palmas,
 			palmas_regs_info[id].ctrl_addr, reg);
+
+	/* Switch the enable value to ensure this is used for enable */
+	if (enable_val)
+		pmic->desc[id].enable_val = pmic->current_reg_mode[id];
+
 	return 0;
 }
 
@@ -964,6 +970,14 @@ static int palmas_regulators_probe(struct platform_device *pdev)
 				return ret;
 			pmic->current_reg_mode[id] = reg &
 					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
+
+			pmic->desc[id].enable_reg =
+					PALMAS_BASE_TO_REG(PALMAS_LDO_BASE,
+						palmas_regs_info[id].ctrl_addr);
+			pmic->desc[id].enable_mask =
+					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
+			/* set_mode overrides this value */
+			pmic->desc[id].enable_val = SMPS_CTRL_MODE_ON;
 		}
 
 		pmic->desc[id].type = REGULATOR_VOLTAGE;
-- 
Regards,
Nishanth Menon

WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Keerthy <j-keerthy@ti.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<linux-omap@vger.kernel.org>
Subject: Re: Palmas regulator broken (was Re: [PATCH] ARM: tegra: TN7: relax some regulators)
Date: Fri, 20 Jun 2014 08:54:54 -0500	[thread overview]
Message-ID: <20140620135454.GA10566@kahuna> (raw)
In-Reply-To: <20140620132310.GA11936@kahuna>

On 08:23-20140620, Nishanth Menon wrote:
> + l-o,
> 	http://marc.info/?t=140316427500004&r=1&w=2 full thread
> 
> Minor change in subject to indicate palmas regulator fail
> 
> On 18:49-20140620, Alexandre Courbot wrote:
> > On 06/20/2014 06:41 PM, Mark Brown wrote:
> > >* PGP Signed by an unknown key
> > >
> > >On Fri, Jun 20, 2014 at 03:44:46PM +0900, Alexandre Courbot wrote:
> > >
> > >>dbabd624d
> > >>regulator: palmas: Reemove open coded functions with helper functions
> > >
> > >>Keerthy, Nishanth, could it be that there is still something wrong with the
> > >>REGULATOR_LINEAR_RANGE() definitions?
> > >
> > >>This seems to be the cause for our trouble, but the other questions might
> > >>still stand, in case there is interest in discussing them.
> > >
> > >There was a bug fix to the Palmas driver which just went to Linus the
> > >other day, are you sure this isn't fixed in mainline (or -next, it's
> > >been in -next for a week or something)?
> > 
> > If you are talking about
> > 
> > 6b7f2d82d5
> > regulator: palmas: Fix SMPS list for 0V
> > 
> > then it is in my tree. There is actually no difference on
> > palmas-regulator.c between my tree and the current -next (or Linus'
> > tree for that instance).
> > 
> > So it seems to be something else we are dealing with here.
> 
> Your quote earlier in the thread
> "
> _regulator_is_enabled() *also* returns false
> "
> 
> Got me curious. Looking at the patch:
> dbabd624d4eec50b623bab070d1e39a854b2d65c (regulator: palmas: Reemove
> open coded functions with helper functions)
> I noticed the following change
> palmas_is_enabled_smps -> regulator_is_enabled_regmap
> 
> So I decided to search for enable_reg in palmas-regulator.c and I think
> it needs valid enable_reg, mask, value for regulator_is_enabled_regmap to work
> :).
> 
> Maybe to be sure, we could print the following:
> PALMAS_SMPS8_VOLTAGE, PALMAS_SMPS8_CTRL, PALMAS_SMPS8_TSTEP,
> 
> Anyways, I quickly boot tested the following on DRA7evm (which also uses Palmas):
> [    1.933939] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.944210] smps123: 850 <--> 1250 mV at 1060 mV 
> [    1.950717] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.960754] smps45: 850 <--> 1150 mV at 1060 mV 
> [    1.967048] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.977072] smps6: 850 <--> 1650 mV at 1060 mV 
> [    1.983077] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    1.992994] smps7: 850 <--> 1030 mV at 1030 mV 
> [    1.999238] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> [    2.009161] smps8: 850 <--> 1250 mV at 1060 mV 
> [    2.015304] palmas-pmic 48070000.i2c:tps659038@58:tps659038_pmic: enable_reg = 0x00, mask =0x00
> 
> It does seem to me that either set_mode also should use core functions
> OR you still need a palmas specific is_enable, enable/disable functions
> (contrary to the claim of the patch in question - which I think
>  introduced regressions).
> 
> Otherwise, completely untested diff below - can you  give this a shot?
> 
> diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
> index b982f0f..bbfe22f 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -964,6 +964,20 @@ static int palmas_regulators_probe(struct platform_device *pdev)
>  				return ret;
>  			pmic->current_reg_mode[id] = reg &
>  					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
> +
> +			dev_err(&pdev->dev, "enable_reg = 0x%02x, mask =0x%02x\n",
> +				pmic->desc[id].enable_reg,
> +				pmic->desc[id].enable_mask);
> +			pmic->desc[id].enable_reg =
> +					PALMAS_BASE_TO_REG(PALMAS_LDO_BASE,
> +						palmas_regs_info[id].ctrl_addr);
> +			pmic->desc[id].enable_mask =
> +					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
> +			/*
> +			 * The following completely ignores
> +			 * pmic->current_reg_mode[id] (set_mode)
> +			 */
> +			pmic->desc[id].enable_val = SMPS_CTRL_MODE_ON;
>  		}
>  
>  		pmic->desc[id].type = REGULATOR_VOLTAGE;

rev 2 of the diff - this does depened on the fact that regulator_desc is
not memdup-ed by regulator code - that lets us do a bit of a trickery ;)
- and I dropped the prints.. Unrelated: This makes me wonder why
palmas_is_enabled_ldo at all?

Keerthy, Mark,
what do you think of the following (esp the flip of desc value):
diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index b982f0f..f01d9c5 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -299,7 +299,7 @@ static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
 	struct palmas_pmic *pmic = rdev_get_drvdata(dev);
 	int id = rdev_get_id(dev);
 	unsigned int reg;
-	bool rail_enable = true;
+	bool rail_enable = true, enable_val = true;
 
 	palmas_smps_read(pmic->palmas, palmas_regs_info[id].ctrl_addr, &reg);
 	reg &= ~PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
@@ -318,6 +318,7 @@ static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
 		reg |= SMPS_CTRL_MODE_PWM;
 		break;
 	default:
+		enable_val = false;
 		return -EINVAL;
 	}
 
@@ -325,6 +326,11 @@ static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
 	if (rail_enable)
 		palmas_smps_write(pmic->palmas,
 			palmas_regs_info[id].ctrl_addr, reg);
+
+	/* Switch the enable value to ensure this is used for enable */
+	if (enable_val)
+		pmic->desc[id].enable_val = pmic->current_reg_mode[id];
+
 	return 0;
 }
 
@@ -964,6 +970,14 @@ static int palmas_regulators_probe(struct platform_device *pdev)
 				return ret;
 			pmic->current_reg_mode[id] = reg &
 					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
+
+			pmic->desc[id].enable_reg =
+					PALMAS_BASE_TO_REG(PALMAS_LDO_BASE,
+						palmas_regs_info[id].ctrl_addr);
+			pmic->desc[id].enable_mask =
+					PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
+			/* set_mode overrides this value */
+			pmic->desc[id].enable_val = SMPS_CTRL_MODE_ON;
 		}
 
 		pmic->desc[id].type = REGULATOR_VOLTAGE;
-- 
Regards,
Nishanth Menon

  reply	other threads:[~2014-06-20 13:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19  7:49 [PATCH] ARM: tegra: TN7: relax some regulators Alexandre Courbot
2014-06-19  7:49 ` Alexandre Courbot
2014-06-19 15:59 ` Stephen Warren
2014-06-19 17:56   ` Mark Brown
     [not found]     ` <20140619175643.GR5099-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-20  5:26       ` Alexandre Courbot
2014-06-20  5:26         ` Alexandre Courbot
     [not found]         ` <53A3C613.8030207-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-20  6:44           ` Alexandre Courbot
2014-06-20  6:44             ` Alexandre Courbot
     [not found]             ` <53A3D85E.7030704-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-06-20  9:41               ` Mark Brown
2014-06-20  9:41                 ` Mark Brown
     [not found]                 ` <20140620094119.GT5099-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-20  9:49                   ` Alexandre Courbot
2014-06-20  9:49                     ` Alexandre Courbot
2014-06-20 13:23                     ` Palmas regulator broken (was Re: [PATCH] ARM: tegra: TN7: relax some regulators) Nishanth Menon
2014-06-20 13:23                       ` Nishanth Menon
2014-06-20 13:54                       ` Nishanth Menon [this message]
2014-06-20 13:54                         ` Nishanth Menon
2014-06-20 14:14                         ` Alexandre Courbot
     [not found]                           ` <CAAVeFuJ=JTNkwDKBvuoyL=ARQs_UJb_MHzL9S8gOc8EU98znPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-06-20 17:27                             ` Nishanth Menon
2014-06-20 17:27                               ` Nishanth Menon
2014-06-20 10:16         ` [PATCH] ARM: tegra: TN7: relax some regulators Mark Brown
     [not found]           ` <20140620101618.GU5099-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-06-20 10:33             ` Alexandre Courbot
2014-06-20 10:33               ` Alexandre Courbot

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=20140620135454.GA10566@kahuna \
    --to=nm@ti.com \
    --cc=acourbot@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=j-keerthy@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    /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.