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: Palmas regulator broken (was Re: [PATCH] ARM: tegra: TN7: relax some regulators)
Date: Fri, 20 Jun 2014 08:23:10 -0500 [thread overview]
Message-ID: <20140620132310.GA11936@kahuna> (raw)
In-Reply-To: <53A4039B.7000504@nvidia.com>
+ 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;
--
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: Palmas regulator broken (was Re: [PATCH] ARM: tegra: TN7: relax some regulators)
Date: Fri, 20 Jun 2014 08:23:10 -0500 [thread overview]
Message-ID: <20140620132310.GA11936@kahuna> (raw)
In-Reply-To: <53A4039B.7000504@nvidia.com>
+ 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;
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2014-06-20 13:23 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 ` Nishanth Menon [this message]
2014-06-20 13:23 ` Palmas regulator broken (was Re: [PATCH] ARM: tegra: TN7: relax some regulators) Nishanth Menon
2014-06-20 13:54 ` Nishanth Menon
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=20140620132310.GA11936@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.