[PATCH 0/9] regulator: Enable suspend configuration

[PATCH 0/9] regulator: Enable suspend configuration

[Keerthy]

The series adds suspend configuration for tps65218 and tps65217 PMICs.

Boot tested on am437x-sk-evm, am437x-gp-evm, am335x-bone, am335x-boneblack

Keerthy (2):
  regulator: of: setup initial suspend state
  ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make dcdc3 dcdc5 and dcdc6
    enable during suspend

Russ Dill (1):
  regulator: tps65217: Enable suspend configuration

Tero Kristo (6):
  regulator: tps65218: Enable suspend configuration
  regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
  ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff
    mode
  mfd: tps65218: add version check to the PMIC probe
  regulator: tps65218: do not disable DCDC3 during poweroff on broken
    PMICs
  ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff
    mode

 arch/arm/boot/dts/am437x-gp-evm.dts    | 13 ++++++
 arch/arm/boot/dts/am437x-sk-evm.dts    | 30 ++++++++++++
 drivers/mfd/tps65218.c                 |  9 ++++
 drivers/regulator/of_regulator.c       |  3 ++
 drivers/regulator/tps65217-regulator.c | 74 ++++++++++++++++++++++++++----
 drivers/regulator/tps65218-regulator.c | 84 +++++++++++++++++++++++++++++-----
 include/linux/mfd/tps65218.h           |  8 ++++
 7 files changed, 201 insertions(+), 20 deletions(-)

-- 
1.9.1

[PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Keerthy]

From: Russ Dill <Russ.Dill@ti.com>

This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/regulator/tps65217-regulator.c | 74 +++++++++++++++++++++++++++++-----
 1 file changed, 65 insertions(+), 9 deletions(-)

diff --git a/drivers/regulator/tps65217-regulator.c b/drivers/regulator/tps65217-regulator.c
index adbe4fc..c15659c 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -28,7 +28,7 @@
 #include <linux/mfd/tps65217.h>
 
 #define TPS65217_REGULATOR(_name, _id, _of_match, _ops, _n, _vr, _vm, _em, \
-                           _t, _lr, _nlr) \
+			   _t, _lr, _nlr,  _sr, _sm)	\
 	{						\
 		.name		= _name,		\
 		.id		= _id,			\
@@ -45,6 +45,8 @@
 		.volt_table	= _t,			\
 		.linear_ranges	= _lr,			\
 		.n_linear_ranges = _nlr,		\
+		.bypass_reg	= _sr,			\
+		.bypass_mask	= _sm,			\
 	}						\
 
 static const unsigned int LDO1_VSEL_table[] = {
@@ -118,6 +120,42 @@ static int tps65217_pmic_set_voltage_sel(struct regulator_dev *dev,
 	return ret;
 }
 
+struct tps65217_regulator_data {
+	int strobe;
+};
+
+static struct tps65217_regulator_data regulator_data[TPS65217_NUM_REGULATOR];
+
+static int tps65217_pmic_set_suspend_enable(struct regulator_dev *dev)
+{
+	struct tps65217 *tps = rdev_get_drvdata(dev);
+	unsigned int rid = rdev_get_id(dev);
+
+	if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
+		return -EINVAL;
+
+	return tps65217_clear_bits(tps, dev->desc->bypass_reg,
+				   dev->desc->bypass_mask,
+				   TPS65217_PROTECT_L1);
+}
+
+static int tps65217_pmic_set_suspend_disable(struct regulator_dev *dev)
+{
+	struct tps65217 *tps = rdev_get_drvdata(dev);
+	unsigned int rid = rdev_get_id(dev);
+
+	if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
+		return -EINVAL;
+
+	if (!regulator_data[rid].strobe)
+		return -EINVAL;
+
+	return tps65217_set_bits(tps, dev->desc->bypass_reg,
+				 dev->desc->bypass_mask,
+				 regulator_data[rid].strobe,
+				 TPS65217_PROTECT_L1);
+}
+
 /* Operations permitted on DCDCx, LDO2, LDO3 and LDO4 */
 static struct regulator_ops tps65217_pmic_ops = {
 	.is_enabled		= regulator_is_enabled_regmap,
@@ -127,6 +165,8 @@ static struct regulator_ops tps65217_pmic_ops = {
 	.set_voltage_sel	= tps65217_pmic_set_voltage_sel,
 	.list_voltage		= regulator_list_voltage_linear_range,
 	.map_voltage		= regulator_map_voltage_linear_range,
+	.set_suspend_enable	= tps65217_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65217_pmic_set_suspend_disable,
 };
 
 /* Operations permitted on LDO1 */
@@ -138,41 +178,50 @@ static struct regulator_ops tps65217_pmic_ldo1_ops = {
 	.set_voltage_sel	= tps65217_pmic_set_voltage_sel,
 	.list_voltage		= regulator_list_voltage_table,
 	.map_voltage		= regulator_map_voltage_ascend,
+	.set_suspend_enable	= tps65217_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65217_pmic_set_suspend_disable,
 };
 
 static const struct regulator_desc regulators[] = {
 	TPS65217_REGULATOR("DCDC1", TPS65217_DCDC_1, "dcdc1",
 			   tps65217_pmic_ops, 64, TPS65217_REG_DEFDCDC1,
 			   TPS65217_DEFDCDCX_DCDC_MASK, TPS65217_ENABLE_DC1_EN,
-			   NULL, tps65217_uv1_ranges, 2),
+			   NULL, tps65217_uv1_ranges, 2, TPS65217_REG_SEQ1,
+			   TPS65217_SEQ1_DC1_SEQ_MASK),
 	TPS65217_REGULATOR("DCDC2", TPS65217_DCDC_2, "dcdc2",
 			   tps65217_pmic_ops, 64, TPS65217_REG_DEFDCDC2,
 			   TPS65217_DEFDCDCX_DCDC_MASK, TPS65217_ENABLE_DC2_EN,
 			   NULL, tps65217_uv1_ranges,
-			   ARRAY_SIZE(tps65217_uv1_ranges)),
+			   ARRAY_SIZE(tps65217_uv1_ranges), TPS65217_REG_SEQ1,
+			   TPS65217_SEQ1_DC2_SEQ_MASK),
 	TPS65217_REGULATOR("DCDC3", TPS65217_DCDC_3, "dcdc3",
 			   tps65217_pmic_ops, 64, TPS65217_REG_DEFDCDC3,
 			   TPS65217_DEFDCDCX_DCDC_MASK, TPS65217_ENABLE_DC3_EN,
-			   NULL, tps65217_uv1_ranges, 1),
+			   NULL, tps65217_uv1_ranges, 1, TPS65217_REG_SEQ2,
+			   TPS65217_SEQ2_DC3_SEQ_MASK),
 	TPS65217_REGULATOR("LDO1", TPS65217_LDO_1, "ldo1",
 			   tps65217_pmic_ldo1_ops, 16, TPS65217_REG_DEFLDO1,
 			   TPS65217_DEFLDO1_LDO1_MASK, TPS65217_ENABLE_LDO1_EN,
-			   LDO1_VSEL_table, NULL, 0),
+			   LDO1_VSEL_table, NULL, 0, TPS65217_REG_SEQ2,
+			   TPS65217_SEQ2_LDO1_SEQ_MASK),
 	TPS65217_REGULATOR("LDO2", TPS65217_LDO_2, "ldo2", tps65217_pmic_ops,
 			   64, TPS65217_REG_DEFLDO2,
 			   TPS65217_DEFLDO2_LDO2_MASK, TPS65217_ENABLE_LDO2_EN,
 			   NULL, tps65217_uv1_ranges,
-			   ARRAY_SIZE(tps65217_uv1_ranges)),
+			   ARRAY_SIZE(tps65217_uv1_ranges), TPS65217_REG_SEQ3,
+			   TPS65217_SEQ3_LDO2_SEQ_MASK),
 	TPS65217_REGULATOR("LDO3", TPS65217_LDO_3, "ldo3", tps65217_pmic_ops,
 			   32, TPS65217_REG_DEFLS1, TPS65217_DEFLDO3_LDO3_MASK,
 			   TPS65217_ENABLE_LS1_EN | TPS65217_DEFLDO3_LDO3_EN,
 			   NULL, tps65217_uv2_ranges,
-			   ARRAY_SIZE(tps65217_uv2_ranges)),
+			   ARRAY_SIZE(tps65217_uv2_ranges), TPS65217_REG_SEQ3,
+			   TPS65217_SEQ3_LDO3_SEQ_MASK),
 	TPS65217_REGULATOR("LDO4", TPS65217_LDO_4, "ldo4", tps65217_pmic_ops,
 			   32, TPS65217_REG_DEFLS2, TPS65217_DEFLDO4_LDO4_MASK,
 			   TPS65217_ENABLE_LS2_EN | TPS65217_DEFLDO4_LDO4_EN,
 			   NULL, tps65217_uv2_ranges,
-			   ARRAY_SIZE(tps65217_uv2_ranges)),
+			   ARRAY_SIZE(tps65217_uv2_ranges), TPS65217_REG_SEQ4,
+			   TPS65217_SEQ4_LDO4_SEQ_MASK),
 };
 
 static int tps65217_regulator_probe(struct platform_device *pdev)
@@ -181,7 +230,8 @@ static int tps65217_regulator_probe(struct platform_device *pdev)
 	struct tps65217_board *pdata = dev_get_platdata(tps->dev);
 	struct regulator_dev *rdev;
 	struct regulator_config config = { };
-	int i;
+	int i, ret;
+	unsigned int val;
 
 	if (tps65217_chip_id(tps) != TPS65217) {
 		dev_err(&pdev->dev, "Invalid tps chip version\n");
@@ -200,6 +250,12 @@ static int tps65217_regulator_probe(struct platform_device *pdev)
 
 		rdev = devm_regulator_register(&pdev->dev, &regulators[i],
 					       &config);
+
+		/* Store default strobe info */
+		ret = tps65217_reg_read(tps, regulators[i].bypass_reg, &val);
+
+		regulator_data[i].strobe = val & regulators[i].bypass_mask;
+
 		if (IS_ERR(rdev)) {
 			dev_err(tps->dev, "failed to register %s regulator\n",
 				pdev->name);
-- 
1.9.1

Re: [PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Mon, Jun 20, 2016 at 02:13:30PM +0530, Keerthy wrote:

> +static struct tps65217_regulator_data regulator_data[TPS65217_NUM_REGULATOR];

Why is this a static global?

> +		/* Store default strobe info */
> +		ret = tps65217_reg_read(tps, regulators[i].bypass_reg, &val);
> +
> +		regulator_data[i].strobe = val & regulators[i].bypass_mask;
> +

Not sure what this is doing...  I think this needs splitting up a bit,
it looks like it's a bit more than just adding the ops (which should be
generic things), that bit seems OK but there's these other bits in
there as well.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Keerthy]

On Wednesday 22 June 2016 12:38 AM, Mark Brown wrote:
> On Mon, Jun 20, 2016 at 02:13:30PM +0530, Keerthy wrote:
>
>> +static struct tps65217_regulator_data regulator_data[TPS65217_NUM_REGULATOR];
>
> Why is this a static global?
>
>> +		/* Store default strobe info */
>> +		ret = tps65217_reg_read(tps, regulators[i].bypass_reg, &val);
>> +
>> +		regulator_data[i].strobe = val & regulators[i].bypass_mask;
>> +
>
> Not sure what this is doing...  I think this needs splitting up a bit,
> it looks like it's a bit more than just adding the ops (which should be
> generic things), that bit seems OK but there's these other bits in
> there as well.

Okay. Let me explain a bit more here:

The TPS65217 has a pre-defined power-up / power-down sequence which in a 
typical application does not need
to be changed. However, it is possible to define custom sequences under 
I2C control. The power-up sequence is
defined by strobes and delay times. Each output rail is assigned to a 
strobe to determine the order in which the
rails are enabled.

Every regulator of tps65217 PMIC has sequence registers and every 
regulator has a default strobe value
and gets disabled when a particular power down sequence occurs.

So as to keep it on during suspend we write value 0 to strobe so that 
the regulator is out of all sequencers and is not impacted by any power 
down sequence. We are saving the default strobe value during probe so 
that when we want to regulator to be enabled during suspend we write 0 
to strobe and when we want it to get disabled during suspend we write 
the default saved strobe value.

Hence saving it in a static array and using it later in the ops 
functions to disable or enable regulator during suspend.

>

Re: [PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On Wed, Jun 22, 2016 at 03:44:02PM +0530, Keerthy wrote:

> Hence saving it in a static array and using it later in the ops functions to
> disable or enable regulator during suspend.

Why a static array and not part of the dynamically allocated driver
data?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Keerthy]

On Wednesday 22 June 2016 03:46 PM, Mark Brown wrote:
> On Wed, Jun 22, 2016 at 03:44:02PM +0530, Keerthy wrote:
>
>> Hence saving it in a static array and using it later in the ops functions to
>> disable or enable regulator during suspend.
>
> Why a static array and not part of the dynamically allocated driver
> data?

Okay. That can be done.
I can introduce another integer pointer to struct tps65217 which 
currently holds the driver data.

I will allocate memory for TPS65217_NUM_REGULATOR strobes during 
regulator probe. Is this approach okay?

>

Re: [PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

On Wed, Jun 22, 2016 at 03:56:33PM +0530, Keerthy wrote:

> I will allocate memory for TPS65217_NUM_REGULATOR strobes during regulator
> probe. Is this approach okay?

It should be I think.  Some more comments or changelog explaining what's
going on with the sequencing would also help.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Keerthy]

On Thursday 23 June 2016 03:56 PM, Mark Brown wrote:
> On Wed, Jun 22, 2016 at 03:56:33PM +0530, Keerthy wrote:
>
>> I will allocate memory for TPS65217_NUM_REGULATOR strobes during regulator
>> probe. Is this approach okay?
>
> It should be I think.  Some more comments or changelog explaining what's
> going on with the sequencing would also help.

Sure. I will do that. Thanks for the feedback.

>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/9] regulator: of: setup initial suspend state

[Keerthy]

Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/regulator/of_regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index cd828db..4f613ec 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -163,6 +163,9 @@ static void of_get_regulation_constraints(struct device_node *np,
 					"regulator-suspend-microvolt", &pval))
 			suspend_state->uV = pval;
 
+		if (i == PM_SUSPEND_MEM)
+			constraints->initial_state = PM_SUSPEND_MEM;
+
 		of_node_put(suspend_np);
 		suspend_state = NULL;
 		suspend_np = NULL;
-- 
1.9.1

Applied "regulator: of: setup initial suspend state" to the regulator tree

[Mark Brown]

The patch

   regulator: of: setup initial suspend state

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From a0f78bc89c0396d14b6102c6f72485e14c8821f3 Mon Sep 17 00:00:00 2001
From: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
Date: Mon, 20 Jun 2016 14:13:31 +0530
Subject: [PATCH] regulator: of: setup initial suspend state

Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.

Signed-off-by: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/regulator/of_regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index cd828dbf9d52..4f613ec99500 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -163,6 +163,9 @@ static void of_get_regulation_constraints(struct device_node *np,
 					"regulator-suspend-microvolt", &pval))
 			suspend_state->uV = pval;
 
+		if (i == PM_SUSPEND_MEM)
+			constraints->initial_state = PM_SUSPEND_MEM;
+
 		of_node_put(suspend_np);
 		suspend_state = NULL;
 		suspend_np = NULL;
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/9] regulator: tps65218: Enable suspend configuration

[Keerthy]

From: Tero Kristo <t-kristo@ti.com>

This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/regulator/tps65218-regulator.c | 72 ++++++++++++++++++++++++++++------
 include/linux/mfd/tps65218.h           |  2 +
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
index a5e5634..8eca1eb 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -31,7 +31,7 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4,
 			   DCDC5, DCDC6, LDO1, LS3 };
 
 #define TPS65218_REGULATOR(_name, _id, _type, _ops, _n, _vr, _vm, _er, _em, \
-			    _cr, _cm, _lr, _nlr, _delay, _fuv)		\
+			   _cr, _cm, _lr, _nlr, _delay, _fuv, _sr, _sm)	\
 	{							\
 		.name			= _name,		\
 		.id			= _id,			\
@@ -49,7 +49,9 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4,
 		.linear_ranges		= _lr,			\
 		.n_linear_ranges	= _nlr,			\
 		.ramp_delay		= _delay,		\
-		.fixed_uV		= _fuv			\
+		.fixed_uV		= _fuv,			\
+		.bypass_reg	= _sr,				\
+		.bypass_mask	= _sm,				\
 	}							\
 
 #define TPS65218_INFO(_id, _nm, _min, _max)	\
@@ -157,6 +159,36 @@ static int tps65218_pmic_disable(struct regulator_dev *dev)
 				   dev->desc->enable_mask, TPS65218_PROTECT_L1);
 }
 
+static int tps65218_pmic_set_suspend_enable(struct regulator_dev *dev)
+{
+	struct tps65218 *tps = rdev_get_drvdata(dev);
+	unsigned int rid = rdev_get_id(dev);
+
+	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
+		return -EINVAL;
+
+	return tps65218_clear_bits(tps, dev->desc->bypass_reg,
+				   dev->desc->bypass_mask,
+				   TPS65218_PROTECT_L1);
+}
+
+static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
+{
+	struct tps65218 *tps = rdev_get_drvdata(dev);
+	unsigned int rid = rdev_get_id(dev);
+
+	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
+		return -EINVAL;
+
+	if (!tps->info[rid]->strobe)
+		return -EINVAL;
+
+	return tps65218_set_bits(tps, dev->desc->bypass_reg,
+				 dev->desc->bypass_mask,
+				 tps->info[rid]->strobe,
+				 TPS65218_PROTECT_L1);
+}
+
 /* Operations permitted on DCDC1, DCDC2 */
 static struct regulator_ops tps65218_dcdc12_ops = {
 	.is_enabled		= regulator_is_enabled_regmap,
@@ -167,6 +199,8 @@ static struct regulator_ops tps65218_dcdc12_ops = {
 	.list_voltage		= regulator_list_voltage_linear_range,
 	.map_voltage		= regulator_map_voltage_linear_range,
 	.set_voltage_time_sel	= regulator_set_voltage_time_sel,
+	.set_suspend_enable	= tps65218_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65218_pmic_set_suspend_disable,
 };
 
 /* Operations permitted on DCDC3, DCDC4 and LDO1 */
@@ -178,6 +212,8 @@ static struct regulator_ops tps65218_ldo1_dcdc34_ops = {
 	.set_voltage_sel	= tps65218_pmic_set_voltage_sel,
 	.list_voltage		= regulator_list_voltage_linear_range,
 	.map_voltage		= regulator_map_voltage_linear_range,
+	.set_suspend_enable	= tps65218_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65218_pmic_set_suspend_disable,
 };
 
 static const int ls3_currents[] = { 100, 200, 500, 1000 };
@@ -247,6 +283,8 @@ static struct regulator_ops tps65218_dcdc56_pmic_ops = {
 	.is_enabled		= regulator_is_enabled_regmap,
 	.enable			= tps65218_pmic_enable,
 	.disable		= tps65218_pmic_disable,
+	.set_suspend_enable	= tps65218_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65218_pmic_set_suspend_disable,
 };
 
 static const struct regulator_desc regulators[] = {
@@ -254,42 +292,47 @@ static const struct regulator_desc regulators[] = {
 			   tps65218_dcdc12_ops, 64, TPS65218_REG_CONTROL_DCDC1,
 			   TPS65218_CONTROL_DCDC1_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC1_EN, 0, 0, dcdc1_dcdc2_ranges,
-			   2, 4000, 0),
+			   2, 4000, 0, TPS65218_REG_SEQ3,
+			   TPS65218_SEQ3_DC1_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC2", TPS65218_DCDC_2, REGULATOR_VOLTAGE,
 			   tps65218_dcdc12_ops, 64, TPS65218_REG_CONTROL_DCDC2,
 			   TPS65218_CONTROL_DCDC2_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC2_EN, 0, 0, dcdc1_dcdc2_ranges,
-			   2, 4000, 0),
+			   2, 4000, 0, TPS65218_REG_SEQ3,
+			   TPS65218_SEQ3_DC2_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC3", TPS65218_DCDC_3, REGULATOR_VOLTAGE,
 			   tps65218_ldo1_dcdc34_ops, 64,
 			   TPS65218_REG_CONTROL_DCDC3,
 			   TPS65218_CONTROL_DCDC3_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC3_EN, 0, 0, ldo1_dcdc3_ranges, 2,
-			   0, 0),
+			   0, 0, TPS65218_REG_SEQ4, TPS65218_SEQ4_DC3_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC4", TPS65218_DCDC_4, REGULATOR_VOLTAGE,
 			   tps65218_ldo1_dcdc34_ops, 53,
 			   TPS65218_REG_CONTROL_DCDC4,
 			   TPS65218_CONTROL_DCDC4_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC4_EN, 0, 0, dcdc4_ranges, 2,
-			   0, 0),
+			   0, 0, TPS65218_REG_SEQ4, TPS65218_SEQ4_DC4_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC5", TPS65218_DCDC_5, REGULATOR_VOLTAGE,
 			   tps65218_dcdc56_pmic_ops, 1, -1, -1,
 			   TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC5_EN, 0, 0,
-			   NULL, 0, 0, 1000000),
+			   NULL, 0, 0, 1000000, TPS65218_REG_SEQ5,
+			   TPS65218_SEQ5_DC5_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC6", TPS65218_DCDC_6, REGULATOR_VOLTAGE,
 			   tps65218_dcdc56_pmic_ops, 1, -1, -1,
 			   TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC6_EN, 0, 0,
-			   NULL, 0, 0, 1800000),
+			   NULL, 0, 0, 1800000, TPS65218_REG_SEQ5,
+			   TPS65218_SEQ5_DC6_SEQ_MASK),
 	TPS65218_REGULATOR("LDO1", TPS65218_LDO_1, REGULATOR_VOLTAGE,
 			   tps65218_ldo1_dcdc34_ops, 64,
 			   TPS65218_REG_CONTROL_LDO1,
 			   TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
 			   TPS65218_ENABLE2_LDO1_EN, 0, 0, ldo1_dcdc3_ranges,
-			   2, 0, 0),
+			   2, 0, 0, TPS65218_REG_SEQ6,
+			   TPS65218_SEQ6_LDO1_SEQ_MASK),
 	TPS65218_REGULATOR("LS3", TPS65218_LS_3, REGULATOR_CURRENT,
 			   tps65218_ls3_ops, 0, 0, 0, TPS65218_REG_ENABLE2,
 			   TPS65218_ENABLE2_LS3_EN, TPS65218_REG_CONFIG2,
-			   TPS65218_CONFIG2_LS3ILIM_MASK, NULL, 0, 0, 0),
+			   TPS65218_CONFIG2_LS3ILIM_MASK, NULL, 0, 0, 0, 0, 0),
 };
 
 static int tps65218_regulator_probe(struct platform_device *pdev)
@@ -300,7 +343,8 @@ static int tps65218_regulator_probe(struct platform_device *pdev)
 	struct regulator_dev *rdev;
 	const struct of_device_id	*match;
 	struct regulator_config config = { };
-	int id;
+	int id, ret;
+	unsigned int val;
 
 	match = of_match_device(tps65218_of_match, &pdev->dev);
 	if (!match)
@@ -327,6 +371,12 @@ static int tps65218_regulator_probe(struct platform_device *pdev)
 		return PTR_ERR(rdev);
 	}
 
+	ret = tps65218_reg_read(tps, regulators[id].bypass_reg, &val);
+	if (ret)
+		return ret;
+
+	tps->info[id]->strobe = val & regulators[id].bypass_mask;
+
 	return 0;
 }
 
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index d58f3b5..7fdf532 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -246,6 +246,7 @@ enum tps65218_irqs {
  * @name:		Voltage regulator name
  * @min_uV:		minimum micro volts
  * @max_uV:		minimum micro volts
+ * @strobe:		sequencing strobe value for the regulator
  *
  * This data is used to check the regualtor voltage limits while setting.
  */
@@ -254,6 +255,7 @@ struct tps_info {
 	const char *name;
 	int min_uV;
 	int max_uV;
+	int strobe;
 };
 
 /**
-- 
1.9.1

Applied "regulator: tps65218: Enable suspend configuration" to the regulator tree

[Mark Brown]

The patch

   regulator: tps65218: Enable suspend configuration

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From b9a0d359413d7f4e078d81cd59f9d851a6febb7a Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Fri, 24 Jun 2016 13:58:08 +0530
Subject: [PATCH] regulator: tps65218: Enable suspend configuration

TPS65218 has a pre-defined power-up / power-down sequence which in
a typical application does not need to be changed. However, it is possible
to define custom sequences under I2C control. The power-up sequence is
defined by strobes and delay times. Each output rail is assigned to a
strobe to determine the order in which the rails are enabled.

Every regulator has sequence registers and every regulator has a default
strobe value and gets disabled when a particular power down sequence
occurs.

To keep a regulator on during suspend we write value 0 to strobe so
that the regulator is out of all sequencers and is not impacted by any
power down sequence. Hence saving the default strobe value during probe
so that when we want to regulator to be enabled during suspend we write 0
to strobe and when we want it to get disabled during suspend we write
the default saved strobe value.
This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/regulator/tps65218-regulator.c | 72 ++++++++++++++++++++++++++++------
 include/linux/mfd/tps65218.h           |  2 +
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
index a5e5634eeb9e..8eca1eb4f219 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -31,7 +31,7 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4,
 			   DCDC5, DCDC6, LDO1, LS3 };
 
 #define TPS65218_REGULATOR(_name, _id, _type, _ops, _n, _vr, _vm, _er, _em, \
-			    _cr, _cm, _lr, _nlr, _delay, _fuv)		\
+			   _cr, _cm, _lr, _nlr, _delay, _fuv, _sr, _sm)	\
 	{							\
 		.name			= _name,		\
 		.id			= _id,			\
@@ -49,7 +49,9 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4,
 		.linear_ranges		= _lr,			\
 		.n_linear_ranges	= _nlr,			\
 		.ramp_delay		= _delay,		\
-		.fixed_uV		= _fuv			\
+		.fixed_uV		= _fuv,			\
+		.bypass_reg	= _sr,				\
+		.bypass_mask	= _sm,				\
 	}							\
 
 #define TPS65218_INFO(_id, _nm, _min, _max)	\
@@ -157,6 +159,36 @@ static int tps65218_pmic_disable(struct regulator_dev *dev)
 				   dev->desc->enable_mask, TPS65218_PROTECT_L1);
 }
 
+static int tps65218_pmic_set_suspend_enable(struct regulator_dev *dev)
+{
+	struct tps65218 *tps = rdev_get_drvdata(dev);
+	unsigned int rid = rdev_get_id(dev);
+
+	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
+		return -EINVAL;
+
+	return tps65218_clear_bits(tps, dev->desc->bypass_reg,
+				   dev->desc->bypass_mask,
+				   TPS65218_PROTECT_L1);
+}
+
+static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
+{
+	struct tps65218 *tps = rdev_get_drvdata(dev);
+	unsigned int rid = rdev_get_id(dev);
+
+	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
+		return -EINVAL;
+
+	if (!tps->info[rid]->strobe)
+		return -EINVAL;
+
+	return tps65218_set_bits(tps, dev->desc->bypass_reg,
+				 dev->desc->bypass_mask,
+				 tps->info[rid]->strobe,
+				 TPS65218_PROTECT_L1);
+}
+
 /* Operations permitted on DCDC1, DCDC2 */
 static struct regulator_ops tps65218_dcdc12_ops = {
 	.is_enabled		= regulator_is_enabled_regmap,
@@ -167,6 +199,8 @@ static struct regulator_ops tps65218_dcdc12_ops = {
 	.list_voltage		= regulator_list_voltage_linear_range,
 	.map_voltage		= regulator_map_voltage_linear_range,
 	.set_voltage_time_sel	= regulator_set_voltage_time_sel,
+	.set_suspend_enable	= tps65218_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65218_pmic_set_suspend_disable,
 };
 
 /* Operations permitted on DCDC3, DCDC4 and LDO1 */
@@ -178,6 +212,8 @@ static struct regulator_ops tps65218_ldo1_dcdc34_ops = {
 	.set_voltage_sel	= tps65218_pmic_set_voltage_sel,
 	.list_voltage		= regulator_list_voltage_linear_range,
 	.map_voltage		= regulator_map_voltage_linear_range,
+	.set_suspend_enable	= tps65218_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65218_pmic_set_suspend_disable,
 };
 
 static const int ls3_currents[] = { 100, 200, 500, 1000 };
@@ -247,6 +283,8 @@ static struct regulator_ops tps65218_dcdc56_pmic_ops = {
 	.is_enabled		= regulator_is_enabled_regmap,
 	.enable			= tps65218_pmic_enable,
 	.disable		= tps65218_pmic_disable,
+	.set_suspend_enable	= tps65218_pmic_set_suspend_enable,
+	.set_suspend_disable	= tps65218_pmic_set_suspend_disable,
 };
 
 static const struct regulator_desc regulators[] = {
@@ -254,42 +292,47 @@ static const struct regulator_desc regulators[] = {
 			   tps65218_dcdc12_ops, 64, TPS65218_REG_CONTROL_DCDC1,
 			   TPS65218_CONTROL_DCDC1_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC1_EN, 0, 0, dcdc1_dcdc2_ranges,
-			   2, 4000, 0),
+			   2, 4000, 0, TPS65218_REG_SEQ3,
+			   TPS65218_SEQ3_DC1_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC2", TPS65218_DCDC_2, REGULATOR_VOLTAGE,
 			   tps65218_dcdc12_ops, 64, TPS65218_REG_CONTROL_DCDC2,
 			   TPS65218_CONTROL_DCDC2_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC2_EN, 0, 0, dcdc1_dcdc2_ranges,
-			   2, 4000, 0),
+			   2, 4000, 0, TPS65218_REG_SEQ3,
+			   TPS65218_SEQ3_DC2_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC3", TPS65218_DCDC_3, REGULATOR_VOLTAGE,
 			   tps65218_ldo1_dcdc34_ops, 64,
 			   TPS65218_REG_CONTROL_DCDC3,
 			   TPS65218_CONTROL_DCDC3_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC3_EN, 0, 0, ldo1_dcdc3_ranges, 2,
-			   0, 0),
+			   0, 0, TPS65218_REG_SEQ4, TPS65218_SEQ4_DC3_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC4", TPS65218_DCDC_4, REGULATOR_VOLTAGE,
 			   tps65218_ldo1_dcdc34_ops, 53,
 			   TPS65218_REG_CONTROL_DCDC4,
 			   TPS65218_CONTROL_DCDC4_MASK, TPS65218_REG_ENABLE1,
 			   TPS65218_ENABLE1_DC4_EN, 0, 0, dcdc4_ranges, 2,
-			   0, 0),
+			   0, 0, TPS65218_REG_SEQ4, TPS65218_SEQ4_DC4_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC5", TPS65218_DCDC_5, REGULATOR_VOLTAGE,
 			   tps65218_dcdc56_pmic_ops, 1, -1, -1,
 			   TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC5_EN, 0, 0,
-			   NULL, 0, 0, 1000000),
+			   NULL, 0, 0, 1000000, TPS65218_REG_SEQ5,
+			   TPS65218_SEQ5_DC5_SEQ_MASK),
 	TPS65218_REGULATOR("DCDC6", TPS65218_DCDC_6, REGULATOR_VOLTAGE,
 			   tps65218_dcdc56_pmic_ops, 1, -1, -1,
 			   TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC6_EN, 0, 0,
-			   NULL, 0, 0, 1800000),
+			   NULL, 0, 0, 1800000, TPS65218_REG_SEQ5,
+			   TPS65218_SEQ5_DC6_SEQ_MASK),
 	TPS65218_REGULATOR("LDO1", TPS65218_LDO_1, REGULATOR_VOLTAGE,
 			   tps65218_ldo1_dcdc34_ops, 64,
 			   TPS65218_REG_CONTROL_LDO1,
 			   TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
 			   TPS65218_ENABLE2_LDO1_EN, 0, 0, ldo1_dcdc3_ranges,
-			   2, 0, 0),
+			   2, 0, 0, TPS65218_REG_SEQ6,
+			   TPS65218_SEQ6_LDO1_SEQ_MASK),
 	TPS65218_REGULATOR("LS3", TPS65218_LS_3, REGULATOR_CURRENT,
 			   tps65218_ls3_ops, 0, 0, 0, TPS65218_REG_ENABLE2,
 			   TPS65218_ENABLE2_LS3_EN, TPS65218_REG_CONFIG2,
-			   TPS65218_CONFIG2_LS3ILIM_MASK, NULL, 0, 0, 0),
+			   TPS65218_CONFIG2_LS3ILIM_MASK, NULL, 0, 0, 0, 0, 0),
 };
 
 static int tps65218_regulator_probe(struct platform_device *pdev)
@@ -300,7 +343,8 @@ static int tps65218_regulator_probe(struct platform_device *pdev)
 	struct regulator_dev *rdev;
 	const struct of_device_id	*match;
 	struct regulator_config config = { };
-	int id;
+	int id, ret;
+	unsigned int val;
 
 	match = of_match_device(tps65218_of_match, &pdev->dev);
 	if (!match)
@@ -327,6 +371,12 @@ static int tps65218_regulator_probe(struct platform_device *pdev)
 		return PTR_ERR(rdev);
 	}
 
+	ret = tps65218_reg_read(tps, regulators[id].bypass_reg, &val);
+	if (ret)
+		return ret;
+
+	tps->info[id]->strobe = val & regulators[id].bypass_mask;
+
 	return 0;
 }
 
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index d58f3b5f585a..7fdf5326f34e 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -246,6 +246,7 @@ enum tps65218_irqs {
  * @name:		Voltage regulator name
  * @min_uV:		minimum micro volts
  * @max_uV:		minimum micro volts
+ * @strobe:		sequencing strobe value for the regulator
  *
  * This data is used to check the regualtor voltage limits while setting.
  */
@@ -254,6 +255,7 @@ struct tps_info {
 	const char *name;
 	int min_uV;
 	int max_uV;
+	int strobe;
 };
 
 /**
-- 
2.8.1

[PATCH 4/9] ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make dcdc3 dcdc5 and dcdc6 enable during suspend

[Keerthy]

dcdc3, dcdc5, dcdc6 supply ddr and rtc respectively. These
are required to be on during suspend. Hence set the state accordingly.

Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 10 ++++++++++
 arch/arm/boot/dts/am437x-sk-evm.dts | 27 +++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 84832bf..7b7ccc0 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -537,7 +537,11 @@
 			regulator-max-microvolt = <1500000>;
 			regulator-boot-on;
 			regulator-always-on;
+			regulator-state-mem {
+				regulator-on-in-suspend;
+			};
 		};
+
 		dcdc5: regulator-dcdc5 {
 			compatible = "ti,tps65218-dcdc5";
 			regulator-name = "v1_0bat";
@@ -545,6 +549,9 @@
 			regulator-max-microvolt = <1000000>;
 			regulator-boot-on;
 			regulator-always-on;
+			regulator-state-mem {
+				regulator-on-in-suspend;
+			};
 		};
 
 		dcdc6: regulator-dcdc6 {
@@ -554,6 +561,9 @@
 			regulator-max-microvolt = <1800000>;
 			regulator-boot-on;
 			regulator-always-on;
+			regulator-state-mem {
+				regulator-on-in-suspend;
+			};
 		};
 
 		ldo1: regulator-ldo1 {
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index d82dd6e..03e3d02 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -454,6 +454,9 @@
 			regulator-max-microvolt = <1500000>;
 			regulator-boot-on;
 			regulator-always-on;
+			regulator-state-mem {
+				regulator-on-in-suspend;
+			};
 		};
 
 		dcdc4: regulator-dcdc4 {
@@ -465,6 +468,30 @@
 			regulator-always-on;
 		};
 
+		dcdc5: regulator-dcdc5 {
+			compatible = "ti,tps65218-dcdc5";
+			regulator-name = "v1_0bat";
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1000000>;
+			regulator-boot-on;
+			regulator-always-on;
+			regulator-state-mem {
+				regulator-on-in-suspend;
+			};
+		};
+
+		dcdc6: regulator-dcdc6 {
+			compatible = "ti,tps65218-dcdc6";
+			regulator-name = "v1_8bat";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-boot-on;
+			regulator-always-on;
+			regulator-state-mem {
+				regulator-on-in-suspend;
+			};
+		};
+
 		ldo1: regulator-ldo1 {
 			compatible = "ti,tps65218-ldo1";
 			regulator-name = "v1_8d";
-- 
1.9.1

Re: [PATCH 4/9] ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make dcdc3 dcdc5 and dcdc6 enable during suspend

[Tony Lindgren]

* Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [160620 01:46]:
> dcdc3, dcdc5, dcdc6 supply ddr and rtc respectively. These
> are required to be on during suspend. Hence set the state accordingly.

Are these dts changes safe for me to apply separately?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/9] ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make dcdc3 dcdc5 and dcdc6 enable during suspend

[Tony Lindgren]

* Keerthy <j-keerthy@ti.com> [160620 01:46]:
> dcdc3, dcdc5, dcdc6 supply ddr and rtc respectively. These
> are required to be on during suspend. Hence set the state accordingly.

Actually, please fix up the subject lines for the dts patches too :)

Instead of "ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make..."
how about something like "ARM: dts: Allow dcdc enable during
suspend for am43xx"?

Regards,

Tony

[PATCH 5/9] regulator: tps65218: force set power-up/down strobe to 3 for dcdc3

[Keerthy]

From: Tero Kristo <t-kristo@ti.com>

The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/regulator/tps65218-regulator.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
index 8eca1eb..d1e631d 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -180,8 +180,12 @@ static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
 	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
 		return -EINVAL;
 
-	if (!tps->info[rid]->strobe)
-		return -EINVAL;
+	if (!tps->info[rid]->strobe) {
+		if (rid == TPS65218_DCDC_3)
+			tps->info[rid]->strobe = 3;
+		else
+			return -EINVAL;
+	}
 
 	return tps65218_set_bits(tps, dev->desc->bypass_reg,
 				 dev->desc->bypass_mask,
-- 
1.9.1

Applied "regulator: tps65218: force set power-up/down strobe to 3 for dcdc3" to the regulator tree

[Mark Brown]

The patch

   regulator: tps65218: force set power-up/down strobe to 3 for dcdc3

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 3fb2ef111d6f799f3da8860c1a90ef3d9c36ea55 Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Fri, 24 Jun 2016 13:58:09 +0530
Subject: [PATCH] regulator: tps65218: force set power-up/down strobe to 3 for
 dcdc3

The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/regulator/tps65218-regulator.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
index 8eca1eb4f219..d1e631d64a20 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -180,8 +180,12 @@ static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
 	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
 		return -EINVAL;
 
-	if (!tps->info[rid]->strobe)
-		return -EINVAL;
+	if (!tps->info[rid]->strobe) {
+		if (rid == TPS65218_DCDC_3)
+			tps->info[rid]->strobe = 3;
+		else
+			return -EINVAL;
+	}
 
 	return tps65218_set_bits(tps, dev->desc->bypass_reg,
 				 dev->desc->bypass_mask,
-- 
2.8.1

[PATCH 6/9] ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode

[Keerthy]

From: Tero Kristo <t-kristo@ti.com>

Without this, the memory will remain active during poweroff consuming
extra power.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 7b7ccc0..a9b09b4 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -540,6 +540,9 @@
 			regulator-state-mem {
 				regulator-on-in-suspend;
 			};
+			regulator-state-disk {
+				regulator-off-in-suspend;
+			};
 		};
 
 		dcdc5: regulator-dcdc5 {
-- 
1.9.1

[PATCH 7/9] mfd: tps65218: add version check to the PMIC probe

[Keerthy]

From: Tero Kristo <t-kristo@ti.com>

Version information will be needed to handle some error cases under the
regulator driver, so store the information once during MFD probe.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/mfd/tps65218.c       | 9 +++++++++
 include/linux/mfd/tps65218.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 80b9dc3..ba610ad 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -219,6 +219,7 @@ static int tps65218_probe(struct i2c_client *client,
 	struct tps65218 *tps;
 	const struct of_device_id *match;
 	int ret;
+	unsigned int chipid;
 
 	match = of_match_device(of_tps65218_match_table, &client->dev);
 	if (!match) {
@@ -250,6 +251,14 @@ static int tps65218_probe(struct i2c_client *client,
 	if (ret < 0)
 		return ret;
 
+	ret = tps65218_reg_read(tps, TPS65218_REG_CHIPID, &chipid);
+	if (ret) {
+		dev_err(tps->dev, "Failed to read chipid: %d\n", ret);
+		return ret;
+	}
+
+	tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
+
 	ret = of_platform_populate(client->dev.of_node, NULL, NULL,
 				   &client->dev);
 	if (ret < 0)
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index 7fdf532..85e464e 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -267,6 +267,7 @@ struct tps_info {
 struct tps65218 {
 	struct device *dev;
 	unsigned int id;
+	u8 rev;
 
 	struct mutex tps_lock;		/* lock guarding the data structure */
 	/* IRQ Data */
-- 
1.9.1

Re: [PATCH 7/9] mfd: tps65218: add version check to the PMIC probe

[Keerthy]

On Monday 20 June 2016 02:13 PM, Keerthy wrote:
> From: Tero Kristo <t-kristo@ti.com>
>
> Version information will be needed to handle some error cases under the
> regulator driver, so store the information once during MFD probe.

+ Lee Jones.

>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
>   drivers/mfd/tps65218.c       | 9 +++++++++
>   include/linux/mfd/tps65218.h | 1 +
>   2 files changed, 10 insertions(+)
>
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 80b9dc3..ba610ad 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -219,6 +219,7 @@ static int tps65218_probe(struct i2c_client *client,
>   	struct tps65218 *tps;
>   	const struct of_device_id *match;
>   	int ret;
> +	unsigned int chipid;
>
>   	match = of_match_device(of_tps65218_match_table, &client->dev);
>   	if (!match) {
> @@ -250,6 +251,14 @@ static int tps65218_probe(struct i2c_client *client,
>   	if (ret < 0)
>   		return ret;
>
> +	ret = tps65218_reg_read(tps, TPS65218_REG_CHIPID, &chipid);
> +	if (ret) {
> +		dev_err(tps->dev, "Failed to read chipid: %d\n", ret);
> +		return ret;
> +	}
> +
> +	tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
> +
>   	ret = of_platform_populate(client->dev.of_node, NULL, NULL,
>   				   &client->dev);
>   	if (ret < 0)
> diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
> index 7fdf532..85e464e 100644
> --- a/include/linux/mfd/tps65218.h
> +++ b/include/linux/mfd/tps65218.h
> @@ -267,6 +267,7 @@ struct tps_info {
>   struct tps65218 {
>   	struct device *dev;
>   	unsigned int id;
> +	u8 rev;
>
>   	struct mutex tps_lock;		/* lock guarding the data structure */
>   	/* IRQ Data */
>

Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Mark Brown]

The patch

   mfd: tps65218: add version check to the PMIC probe

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From f11fa1796a4b4f8c6d4ced37e8824276ec57057d Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Wed, 10 Aug 2016 17:53:54 +0530
Subject: [PATCH] mfd: tps65218: add version check to the PMIC probe

Version information will be needed to handle some error cases under the
regulator driver, so store the information once during MFD probe.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/mfd/tps65218.c       | 9 +++++++++
 include/linux/mfd/tps65218.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 80b9dc363cd8..ba610adbdbff 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -219,6 +219,7 @@ static int tps65218_probe(struct i2c_client *client,
 	struct tps65218 *tps;
 	const struct of_device_id *match;
 	int ret;
+	unsigned int chipid;
 
 	match = of_match_device(of_tps65218_match_table, &client->dev);
 	if (!match) {
@@ -250,6 +251,14 @@ static int tps65218_probe(struct i2c_client *client,
 	if (ret < 0)
 		return ret;
 
+	ret = tps65218_reg_read(tps, TPS65218_REG_CHIPID, &chipid);
+	if (ret) {
+		dev_err(tps->dev, "Failed to read chipid: %d\n", ret);
+		return ret;
+	}
+
+	tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
+
 	ret = of_platform_populate(client->dev.of_node, NULL, NULL,
 				   &client->dev);
 	if (ret < 0)
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index 7fdf5326f34e..85e464e32c43 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -267,6 +267,7 @@ struct tps_info {
 struct tps65218 {
 	struct device *dev;
 	unsigned int id;
+	u8 rev;
 
 	struct mutex tps_lock;		/* lock guarding the data structure */
 	/* IRQ Data */
-- 
2.8.1

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Lee Jones]

On Wed, 10 Aug 2016, Mark Brown wrote:

> The patch
> 
>    mfd: tps65218: add version check to the PMIC probe

Why did you take this patch?

I now have a merge conflict.

Did you provide a pull-request that I can use to resolve?

> has been applied to the regulator tree at
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
> From f11fa1796a4b4f8c6d4ced37e8824276ec57057d Mon Sep 17 00:00:00 2001
> From: Tero Kristo <t-kristo@ti.com>
> Date: Wed, 10 Aug 2016 17:53:54 +0530
> Subject: [PATCH] mfd: tps65218: add version check to the PMIC probe
> 
> Version information will be needed to handle some error cases under the
> regulator driver, so store the information once during MFD probe.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/mfd/tps65218.c       | 9 +++++++++
>  include/linux/mfd/tps65218.h | 1 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 80b9dc363cd8..ba610adbdbff 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -219,6 +219,7 @@ static int tps65218_probe(struct i2c_client *client,
>  	struct tps65218 *tps;
>  	const struct of_device_id *match;
>  	int ret;
> +	unsigned int chipid;
>  
>  	match = of_match_device(of_tps65218_match_table, &client->dev);
>  	if (!match) {
> @@ -250,6 +251,14 @@ static int tps65218_probe(struct i2c_client *client,
>  	if (ret < 0)
>  		return ret;
>  
> +	ret = tps65218_reg_read(tps, TPS65218_REG_CHIPID, &chipid);
> +	if (ret) {
> +		dev_err(tps->dev, "Failed to read chipid: %d\n", ret);
> +		return ret;
> +	}
> +
> +	tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
> +
>  	ret = of_platform_populate(client->dev.of_node, NULL, NULL,
>  				   &client->dev);
>  	if (ret < 0)
> diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
> index 7fdf5326f34e..85e464e32c43 100644
> --- a/include/linux/mfd/tps65218.h
> +++ b/include/linux/mfd/tps65218.h
> @@ -267,6 +267,7 @@ struct tps_info {
>  struct tps65218 {
>  	struct device *dev;
>  	unsigned int id;
> +	u8 rev;
>  
>  	struct mutex tps_lock;		/* lock guarding the data structure */
>  	/* IRQ Data */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> On Wed, 10 Aug 2016, Mark Brown wrote:

> > The patch

> >    mfd: tps65218: add version check to the PMIC probe

> Why did you take this patch?

You acked it, that's saying that you're OK with the patch and are
expecting someone else to apply it.

> I now have a merge conflict.

> Did you provide a pull-request that I can use to resolve?

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/tps65218-ver-check

for you to fetch changes up to f11fa1796a4b4f8c6d4ced37e8824276ec57057d:

  mfd: tps65218: add version check to the PMIC probe (2016-08-10 18:21:55 +0100)

----------------------------------------------------------------
mfd: tps65218: Add hardware version check

This will be used for quirks by some function drivers.

----------------------------------------------------------------
Tero Kristo (1):
      mfd: tps65218: add version check to the PMIC probe

 drivers/mfd/tps65218.c       | 9 +++++++++
 include/linux/mfd/tps65218.h | 1 +
 2 files changed, 10 insertions(+)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Lee Jones]

On Wed, 31 Aug 2016, Mark Brown wrote:

> On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> > On Wed, 10 Aug 2016, Mark Brown wrote:
> 
> > > The patch
> 
> > >    mfd: tps65218: add version check to the PMIC probe
> 
> > Why did you take this patch?
> 
> You acked it, that's saying that you're OK with the patch and are
> expecting someone else to apply it.

No it doesn't, you made that up. :)

I know when you and some others Ack a patch, that's what you mean, but
you've been working with me for long enough to know that's not what I
mean when I Ack a patch.  I do it as an indication that I've reviewed
the patch and I'm happy with it.  Most MFD patches that have
dependencies tend to come through the MFD tree.  If that's not the
case, my Ack is usually backed up with a "I expect this patch to go
through the X tree".

> > I now have a merge conflict.
> 
> > Did you provide a pull-request that I can use to resolve?
> 
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

Thanks.

>   Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/tps65218-ver-check
> 
> for you to fetch changes up to f11fa1796a4b4f8c6d4ced37e8824276ec57057d:
> 
>   mfd: tps65218: add version check to the PMIC probe (2016-08-10 18:21:55 +0100)
> 
> ----------------------------------------------------------------
> mfd: tps65218: Add hardware version check
> 
> This will be used for quirks by some function drivers.
> 
> ----------------------------------------------------------------
> Tero Kristo (1):
>       mfd: tps65218: add version check to the PMIC probe
> 
>  drivers/mfd/tps65218.c       | 9 +++++++++
>  include/linux/mfd/tps65218.h | 1 +
>  2 files changed, 10 insertions(+)



-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Wed, Aug 31, 2016 at 03:50:18PM +0100, Lee Jones wrote:
> On Wed, 31 Aug 2016, Mark Brown wrote:

> > You acked it, that's saying that you're OK with the patch and are
> > expecting someone else to apply it.

> No it doesn't, you made that up. :)

> I know when you and some others Ack a patch, that's what you mean, but

That's the standard meaning I'm afraid, you're going to confuse people
if you do that.  I'd suggest using a different tag if you want to do
this, probably make one up.

> you've been working with me for long enough to know that's not what I
> mean when I Ack a patch.  I do it as an indication that I've reviewed
> the patch and I'm happy with it.  Most MFD patches that have

Sorry but I'm not actually reading most of these threads, I've not seen
this behaviour.  Mostly I just look at the relevant patches, especially
on the resends where presumably this has been happening.  Not sure why I
even saw the ack here, perhaps I had some question about the versioning
API.  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Lee Jones]

On Wed, 31 Aug 2016, Mark Brown wrote:

> On Wed, Aug 31, 2016 at 03:50:18PM +0100, Lee Jones wrote:
> > On Wed, 31 Aug 2016, Mark Brown wrote:
> 
> > > You acked it, that's saying that you're OK with the patch and are
> > > expecting someone else to apply it.
> 
> > No it doesn't, you made that up. :)
> 
> > I know when you and some others Ack a patch, that's what you mean, but
> 
> That's the standard meaning I'm afraid, you're going to confuse people
> if you do that.  I'd suggest using a different tag if you want to do
> this, probably make one up.

Reviewed-by-BUT-DONT-TAKE-IT-YOU-FIEND: <me>

:)

Temporary-Acked-by-[to go through MFD tree]: <me>

Suggestions?

> > you've been working with me for long enough to know that's not what I
> > mean when I Ack a patch.  I do it as an indication that I've reviewed
> > the patch and I'm happy with it.  Most MFD patches that have
> 
> Sorry but I'm not actually reading most of these threads, I've not seen
> this behaviour.  Mostly I just look at the relevant patches, especially
> on the resends where presumably this has been happening.  Not sure why I
> even saw the ack here, perhaps I had some question about the versioning
> API.  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

On Thu, Sep 01, 2016 at 09:23:08AM +0100, Lee Jones wrote:
> On Wed, 31 Aug 2016, Mark Brown wrote:

> > That's the standard meaning I'm afraid, you're going to confuse people
> > if you do that.  I'd suggest using a different tag if you want to do
> > this, probably make one up.

> Reviewed-by-BUT-DONT-TAKE-IT-YOU-FIEND: <me>

> :)

> Temporary-Acked-by-[to go through MFD tree]: <me>

> Suggestions?

Reviwed-for-MFD-by: ?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Lee Jones]

On Thu, 01 Sep 2016, Mark Brown wrote:

> On Thu, Sep 01, 2016 at 09:23:08AM +0100, Lee Jones wrote:
> > On Wed, 31 Aug 2016, Mark Brown wrote:
> 
> > > That's the standard meaning I'm afraid, you're going to confuse people
> > > if you do that.  I'd suggest using a different tag if you want to do
> > > this, probably make one up.
> 
> > Reviewed-by-BUT-DONT-TAKE-IT-YOU-FIEND: <me>
> 
> > :)
> 
> > Temporary-Acked-by-[to go through MFD tree]: <me>
> 
> > Suggestions?
> 
> Reviwed-for-MFD-by: ?

Okay, done.  Thanks for your suggestion.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Russell King - ARM Linux]

On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> On Wed, 10 Aug 2016, Mark Brown wrote:
> 
> > The patch
> > 
> >    mfd: tps65218: add version check to the PMIC probe
> 
> Why did you take this patch?

I think folk need to start to understand the purpose of the To: and Cc:
lines in emails.

To: means you're sending the message _to_ the recipient, expecting them
to be the _primary_ receiver of the message, and to _process_ the message
in some way.  In the case of a patch, that may be applying the change.

Cc: means you're providing the recipient with a copy of the message, "for
their information" and you're not expecting them to take action.

If you think that there's no difference between To: and Cc: then ask
yourself this question: what's the point of having the two headers,
why not list all recipients under one single header.

Mark was in the To: line, therefore it is perfectly reasonable for him
to apply the patch when it gets acked, since the original author sent
it _TO_ Mark implicitly asking him to apply it.

If you have a problem with that, then you need to say something in
reply to the patch, or you need to instruct folk who send patches for
bits of your subsystem not to place others in the To: field who may
pick up the patch.

However, there is a tendency with some people's mailers (including
yours) which keeps the recipients of the To: and Cc: from the message
being replied to, and copies them to the reply as-is.  That totally
screws up the meaning of the To: and Cc: headers, and is really
really really really annoying for people who are in the To: field
but who aren't being asked to do anything in the replies.  (Fix your
bloody mailer not to do this please!)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Lee Jones]

On Wed, 31 Aug 2016, Russell King - ARM Linux wrote:

> On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> > On Wed, 10 Aug 2016, Mark Brown wrote:
> > 
> > > The patch
> > > 
> > >    mfd: tps65218: add version check to the PMIC probe
> > 
> > Why did you take this patch?
> 
> I think folk need to start to understand the purpose of the To: and Cc:
> lines in emails.
> 
> To: means you're sending the message _to_ the recipient, expecting them
> to be the _primary_ receiver of the message, and to _process_ the message
> in some way.  In the case of a patch, that may be applying the change.
> 
> Cc: means you're providing the recipient with a copy of the message, "for
> their information" and you're not expecting them to take action.
> 
> If you think that there's no difference between To: and Cc: then ask
> yourself this question: what's the point of having the two headers,
> why not list all recipients under one single header.
> 
> Mark was in the To: line, therefore it is perfectly reasonable for him
> to apply the patch when it gets acked, since the original author sent
> it _TO_ Mark implicitly asking him to apply it.
> 
> If you have a problem with that, then you need to say something in
> reply to the patch, or you need to instruct folk who send patches for
> bits of your subsystem not to place others in the To: field who may
> pick up the patch.

It's not up to submitters which repo patches get applied to.  They are
free to make a verbal (written) request and if it's justified then we
can choose to agree to it or not.  For instance, a submitter is more
likely to know if a dependency was recently taken in via a particular
tree than a Maintainer, since it's almost impossible to keep track
each and every patch and all it's possible dependants.

I personally review/accept patches based solely on the subsystem(s)
touched and the actions of particular Maintainers, knowing firstly how
they operate.  Actioning patches based on whether a contributor uses
the To: or Cc: lines seems very fragile and prone to unnecessary
complications.

> However, there is a tendency with some people's mailers (including
> yours) which keeps the recipients of the To: and Cc: from the message
> being replied to, and copies them to the reply as-is.  That totally
> screws up the meaning of the To: and Cc: headers, and is really
> really really really annoying for people who are in the To: field
> but who aren't being asked to do anything in the replies.  (Fix your
> bloody mailer not to do this please!)

I use the Mutt's default configuration for 'reply-to-all' in all
cases.  I really don't have time to manually reorganise something as
trivial as To: and Cc: lines.  I find them irrelevant in this
setting.  Any time spent on trivial activities such as these adds
further delay to patch-reviews.  Some of us have day jobs too you
know. ;)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Russell King - ARM Linux]

On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote:
> On Wed, 31 Aug 2016, Russell King - ARM Linux wrote:
> 
> > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> > > On Wed, 10 Aug 2016, Mark Brown wrote:
> > > 
> > > > The patch
> > > > 
> > > >    mfd: tps65218: add version check to the PMIC probe
> > > 
> > > Why did you take this patch?
> > 
> > I think folk need to start to understand the purpose of the To: and Cc:
> > lines in emails.
> > 
> > To: means you're sending the message _to_ the recipient, expecting them
> > to be the _primary_ receiver of the message, and to _process_ the message
> > in some way.  In the case of a patch, that may be applying the change.
> > 
> > Cc: means you're providing the recipient with a copy of the message, "for
> > their information" and you're not expecting them to take action.
> > 
> > If you think that there's no difference between To: and Cc: then ask
> > yourself this question: what's the point of having the two headers,
> > why not list all recipients under one single header.
> > 
> > Mark was in the To: line, therefore it is perfectly reasonable for him
> > to apply the patch when it gets acked, since the original author sent
> > it _TO_ Mark implicitly asking him to apply it.
> > 
> > If you have a problem with that, then you need to say something in
> > reply to the patch, or you need to instruct folk who send patches for
> > bits of your subsystem not to place others in the To: field who may
> > pick up the patch.
> 
> It's not up to submitters which repo patches get applied to.  They are
> free to make a verbal (written) request and if it's justified then we
> can choose to agree to it or not.

Wrong.  It's up to submitters to send TO the person who they want to
apply the patch - that's how it's always worked.

What's become broken is this idea of "I absolutely own this area of the
kernel, all patches _must_ come through me."  That's never been the case.

There may be a good reason why the submitter doesn't want the normal
maintainer of an area of the kernel to take the patch, in which case
the submitter has every right to decide who should take their patch.
The wrong maintainer taking the patch can screw up the submitters
workflow, cause additional conflicts, or break dependencies.  The
submitter is the best person to decide who should apply their change.

> I use the Mutt's default configuration for 'reply-to-all' in all
> cases.  I really don't have time to manually reorganise something as
> trivial as To: and Cc: lines.  I find them irrelevant in this
> setting.  Any time spent on trivial activities such as these adds
> further delay to patch-reviews.  Some of us have day jobs too you
> know. ;)

Exactly - some of us don't have a lot of time, and some of us don't
read messages that aren't sent either To or Cc'd to us.  Some of us
also place messages that are Cc'd at a _much_ lower priority than
those which are sent To them.

If people want me to take some action with their message, they had
better put me in the To: line and _not_ the Cc, otherwise they're
risking me ignoring them for a long time.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Lee Jones]

On Thu, 01 Sep 2016, Russell King - ARM Linux wrote:

> On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote:
> > On Wed, 31 Aug 2016, Russell King - ARM Linux wrote:
> > 
> > > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> > > > On Wed, 10 Aug 2016, Mark Brown wrote:
> > > > 
> > > > > The patch
> > > > > 
> > > > >    mfd: tps65218: add version check to the PMIC probe
> > > > 
> > > > Why did you take this patch?
> > > 
> > > I think folk need to start to understand the purpose of the To: and Cc:
> > > lines in emails.
> > > 
> > > To: means you're sending the message _to_ the recipient, expecting them
> > > to be the _primary_ receiver of the message, and to _process_ the message
> > > in some way.  In the case of a patch, that may be applying the change.
> > > 
> > > Cc: means you're providing the recipient with a copy of the message, "for
> > > their information" and you're not expecting them to take action.
> > > 
> > > If you think that there's no difference between To: and Cc: then ask
> > > yourself this question: what's the point of having the two headers,
> > > why not list all recipients under one single header.
> > > 
> > > Mark was in the To: line, therefore it is perfectly reasonable for him
> > > to apply the patch when it gets acked, since the original author sent
> > > it _TO_ Mark implicitly asking him to apply it.
> > > 
> > > If you have a problem with that, then you need to say something in
> > > reply to the patch, or you need to instruct folk who send patches for
> > > bits of your subsystem not to place others in the To: field who may
> > > pick up the patch.
> > 
> > It's not up to submitters which repo patches get applied to.  They are
> > free to make a verbal (written) request and if it's justified then we
> > can choose to agree to it or not.
> 
> Wrong.  It's up to submitters to send TO the person who they want to
> apply the patch - that's how it's always worked.
> 
> What's become broken is this idea of "I absolutely own this area of the
> kernel, all patches _must_ come through me."  That's never been the case.
> 
> There may be a good reason why the submitter doesn't want the normal
> maintainer of an area of the kernel to take the patch, in which case
> the submitter has every right to decide who should take their patch.
> The wrong maintainer taking the patch can screw up the submitters
> workflow, cause additional conflicts, or break dependencies.  The
> submitter is the best person to decide who should apply their change.

I agree that the submitter is the best person to provide a compelling
case to re-route a patch's normal submission path.  I disagree that
they have the final say.  I've had a bunch of requests asking if a
patch can go in via a different repository due to convenience i.e.
their feature will magically start working once the set lands.  Myself
and the all of the Maintainers I regularly work with vehemently push
back on that, and insist the only 2 cases which will be considered are
a) to prevent merge-conflicts and b) in the case of a *build*
dependency.  If neither of those boxes are ticked, then we separate
the set and apply the patches pertaining to the subsystems we each
look maintain.

In the acceptable cases above, if I am the *lucky* person to route the
patches to Mainline (which 9 out of 10 times I am), I religiously send
pull-requests to the other Maintainers, so they can continue to avoid
merge conflicts, both in their own trees and in Linus' during the
merge-window.  If patches go through another tree, I usually insist
on an immutable branch to pull from, for the same reasons stated.

> > I use the Mutt's default configuration for 'reply-to-all' in all
> > cases.  I really don't have time to manually reorganise something as
> > trivial as To: and Cc: lines.  I find them irrelevant in this
> > setting.  Any time spent on trivial activities such as these adds
> > further delay to patch-reviews.  Some of us have day jobs too you
> > know. ;)
> 
> Exactly - some of us don't have a lot of time, and some of us don't
> read messages that aren't sent either To or Cc'd to us.  Some of us
> also place messages that are Cc'd at a _much_ lower priority than
> those which are sent To them.

I can live with that.

So far I have not been inhibited by this, AFAIK.

> If people want me to take some action with their message, they had
> better put me in the To: line and _not_ the Cc, otherwise they're
> risking me ignoring them for a long time.

I'm not sure many people work like that, sending or receiving.  In my
case I deal with every mail I receive, firstly by brain grepping --
skimming over the subject headers for mails I consider urgent.
Everything else gets marked as 'important' and is dealt with
chronologically.  No where in my workflow to do filter by, or consider
To: and Cc: fields.  That just sounds like too much effort.

Again, sorry if that messes with your workflow, truly, but I have more
important things to focus on.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Russell King - ARM Linux]

On Thu, Sep 01, 2016 at 12:19:18PM +0100, Lee Jones wrote:
> On Thu, 01 Sep 2016, Russell King - ARM Linux wrote:
> 
> > On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote:
> > > On Wed, 31 Aug 2016, Russell King - ARM Linux wrote:
> > > 
> > > > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> > > > > On Wed, 10 Aug 2016, Mark Brown wrote:
> > > > > 
> > > > > > The patch
> > > > > > 
> > > > > >    mfd: tps65218: add version check to the PMIC probe
> > > > > 
> > > > > Why did you take this patch?
> > > > 
> > > > I think folk need to start to understand the purpose of the To: and Cc:
> > > > lines in emails.
> > > > 
> > > > To: means you're sending the message _to_ the recipient, expecting them
> > > > to be the _primary_ receiver of the message, and to _process_ the message
> > > > in some way.  In the case of a patch, that may be applying the change.
> > > > 
> > > > Cc: means you're providing the recipient with a copy of the message, "for
> > > > their information" and you're not expecting them to take action.
> > > > 
> > > > If you think that there's no difference between To: and Cc: then ask
> > > > yourself this question: what's the point of having the two headers,
> > > > why not list all recipients under one single header.
> > > > 
> > > > Mark was in the To: line, therefore it is perfectly reasonable for him
> > > > to apply the patch when it gets acked, since the original author sent
> > > > it _TO_ Mark implicitly asking him to apply it.
> > > > 
> > > > If you have a problem with that, then you need to say something in
> > > > reply to the patch, or you need to instruct folk who send patches for
> > > > bits of your subsystem not to place others in the To: field who may
> > > > pick up the patch.
> > > 
> > > It's not up to submitters which repo patches get applied to.  They are
> > > free to make a verbal (written) request and if it's justified then we
> > > can choose to agree to it or not.
> > 
> > Wrong.  It's up to submitters to send TO the person who they want to
> > apply the patch - that's how it's always worked.
> > 
> > What's become broken is this idea of "I absolutely own this area of the
> > kernel, all patches _must_ come through me."  That's never been the case.
> > 
> > There may be a good reason why the submitter doesn't want the normal
> > maintainer of an area of the kernel to take the patch, in which case
> > the submitter has every right to decide who should take their patch.
> > The wrong maintainer taking the patch can screw up the submitters
> > workflow, cause additional conflicts, or break dependencies.  The
> > submitter is the best person to decide who should apply their change.
> 
> I agree that the submitter is the best person to provide a compelling
> case to re-route a patch's normal submission path.  I disagree that
> they have the final say.

I'm *not* saying that they have the final say - that's completely _your_
invention.  They are making the request, and people can still ignore,
refuse, or reply saying that they don't want to take it - all of those
are valid actions of someone listed in the To: header.  However, you
should not be surprised if a person listed in the To: header does action
the merge if they think that's the reasonable thing for them to do.

> > If people want me to take some action with their message, they had
> > better put me in the To: line and _not_ the Cc, otherwise they're
> > risking me ignoring them for a long time.
> 
> I'm not sure many people work like that, sending or receiving.  In my
> case I deal with every mail I receive, firstly by brain grepping --
> skimming over the subject headers for mails I consider urgent.
> Everything else gets marked as 'important' and is dealt with
> chronologically.  No where in my workflow to do filter by, or consider
> To: and Cc: fields.  That just sounds like too much effort.

My mutt is normally set with "~p | ~P" so I don't even see any message
that I'm not expicitly listed in the To or Cc anymore - that's because
if I don't do that, due to the number of emails I get, I can't track
_anything_.  That was highlighted by a security bug that came up earlier
this year that got totally buried in my mailbox and completely forgotten.
Since then, I've decided that it's just impossible for me to do anything
but filter away every mail that I'm not explicitly in those headers.

I asked Linus how he deals with his mail, and he's the same: he may be
subscribed to several mailing lists, but he doesn't _read_ any email
that he's not listed in the To or Cc fields, and even then he tries to
get rid of it as quickly as possible.

So, I'm doing kind of what Linus does to cope with his mail stream: if
you want me to read your message, you have to put me in the headers,
otherwise be prepared for me to ignore your message for a very long
time (possibly never read it.)  And as I've said, wanting me to do
something needs me in the To: header because I'll look at those with
a higher priority.  Mutt makes that nice and easy, giving a T (for
To), C (for Cc), and a + for personal messages in the index.

But... my point still stands.  This is how To and Cc have worked
universally, even before email.  There's plenty of articles on the net
describing the correct use of To, Cc, and Bcc, most of which back up my
point.  It's a basic English writing skill and it was important when
sending memos around a company to get it right.  Thankfully, memos
didn't need to be threaded unlike emails today.  However, the same
point _does_ still exist.  It's down to pure laziness that this is not
followed as it should be, and it's not surprising that things go wrong
as a result.

So, keep making unreasonable expectations of others and writing poor
emails if you like, just don't expect the outcome you wish every time,
as illustrated by what happened earlier in this thread!

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

[Lee Jones]

On Thu, 01 Sep 2016, Russell King - ARM Linux wrote:

> On Thu, Sep 01, 2016 at 12:19:18PM +0100, Lee Jones wrote:
> > On Thu, 01 Sep 2016, Russell King - ARM Linux wrote:
> > 
> > > On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote:
> > > > On Wed, 31 Aug 2016, Russell King - ARM Linux wrote:
> > > > 
> > > > > On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> > > > > > On Wed, 10 Aug 2016, Mark Brown wrote:
> > > > > > 
> > > > > > > The patch
> > > > > > > 
> > > > > > >    mfd: tps65218: add version check to the PMIC probe
> > > > > > 
> > > > > > Why did you take this patch?
> > > > > 
> > > > > I think folk need to start to understand the purpose of the To: and Cc:
> > > > > lines in emails.
> > > > > 
> > > > > To: means you're sending the message _to_ the recipient, expecting them
> > > > > to be the _primary_ receiver of the message, and to _process_ the message
> > > > > in some way.  In the case of a patch, that may be applying the change.
> > > > > 
> > > > > Cc: means you're providing the recipient with a copy of the message, "for
> > > > > their information" and you're not expecting them to take action.
> > > > > 
> > > > > If you think that there's no difference between To: and Cc: then ask
> > > > > yourself this question: what's the point of having the two headers,
> > > > > why not list all recipients under one single header.
> > > > > 
> > > > > Mark was in the To: line, therefore it is perfectly reasonable for him
> > > > > to apply the patch when it gets acked, since the original author sent
> > > > > it _TO_ Mark implicitly asking him to apply it.
> > > > > 
> > > > > If you have a problem with that, then you need to say something in
> > > > > reply to the patch, or you need to instruct folk who send patches for
> > > > > bits of your subsystem not to place others in the To: field who may
> > > > > pick up the patch.
> > > > 
> > > > It's not up to submitters which repo patches get applied to.  They are
> > > > free to make a verbal (written) request and if it's justified then we
> > > > can choose to agree to it or not.
> > > 
> > > Wrong.  It's up to submitters to send TO the person who they want to
> > > apply the patch - that's how it's always worked.
> > > 
> > > What's become broken is this idea of "I absolutely own this area of the
> > > kernel, all patches _must_ come through me."  That's never been the case.
> > > 
> > > There may be a good reason why the submitter doesn't want the normal
> > > maintainer of an area of the kernel to take the patch, in which case
> > > the submitter has every right to decide who should take their patch.
> > > The wrong maintainer taking the patch can screw up the submitters
> > > workflow, cause additional conflicts, or break dependencies.  The
> > > submitter is the best person to decide who should apply their change.
> > 
> > I agree that the submitter is the best person to provide a compelling
> > case to re-route a patch's normal submission path.  I disagree that
> > they have the final say.
> 
> I'm *not* saying that they have the final say - that's completely _your_
> invention.  They are making the request, and people can still ignore,
> refuse, or reply saying that they don't want to take it - all of those
> are valid actions of someone listed in the To: header.

Okay, we are in agreement then. :)

> However, you
> should not be surprised if a person listed in the To: header does action
> the merge if they think that's the reasonable thing for them to do.

I would never take a patch from another subsystem without permission
from its Maintainer.  And I would/do get pretty shirty when others do
the same to me.  It's not a terrestrial thing.  If we transcended into
a free-for-all, or to a lesser extent, patches touching the same file
are routed into multiple repos, then we run the risk of conflict at
merge time.  Hence why I go to all that effort to provide pull-
requests to immutable branches when I do so.

> > > If people want me to take some action with their message, they had
> > > better put me in the To: line and _not_ the Cc, otherwise they're
> > > risking me ignoring them for a long time.
> > 
> > I'm not sure many people work like that, sending or receiving.  In my
> > case I deal with every mail I receive, firstly by brain grepping --
> > skimming over the subject headers for mails I consider urgent.
> > Everything else gets marked as 'important' and is dealt with
> > chronologically.  No where in my workflow to do filter by, or consider
> > To: and Cc: fields.  That just sounds like too much effort.
> 
> My mutt is normally set with "~p | ~P" so I don't even see any message
> that I'm not expicitly listed in the To or Cc anymore - that's because
> if I don't do that, due to the number of emails I get, I can't track
> _anything_.  That was highlighted by a security bug that came up earlier
> this year that got totally buried in my mailbox and completely forgotten.
> Since then, I've decided that it's just impossible for me to do anything
> but filter away every mail that I'm not explicitly in those headers.

Apologies for misleading you a little.  I too do that.  I have lots of
filters which only place *relevant* mails in my 'Personal' folder,
which is the only mail folder I operate on.  All filters are
duplicated though -- again I do not differentiate between To: and Cc:
headers.

> I asked Linus how he deals with his mail, and he's the same: he may be
> subscribed to several mailing lists, but he doesn't _read_ any email
> that he's not listed in the To or Cc fields, and even then he tries to
> get rid of it as quickly as possible.

Yeah, likewise.

> So, I'm doing kind of what Linus does to cope with his mail stream: if
> you want me to read your message, you have to put me in the headers,
> otherwise be prepared for me to ignore your message for a very long
> time (possibly never read it.)  And as I've said, wanting me to do
> something needs me in the To: header because I'll look at those with
> a higher priority.  Mutt makes that nice and easy, giving a T (for
> To), C (for Cc), and a + for personal messages in the index.

I didn't know know about those bindings, but as I say, I probably
wouldn't use them anyway.  Do you seriously/actually use them?  Even
knowing full well that contributors do not use them as you expect?

> But... my point still stands.  This is how To and Cc have worked
> universally, even before email.  There's plenty of articles on the net
> describing the correct use of To, Cc, and Bcc, most of which back up my
> point.  It's a basic English writing skill and it was important when
> sending memos around a company to get it right.  Thankfully, memos
> didn't need to be threaded unlike emails today.  However, the same
> point _does_ still exist.  It's down to pure laziness that this is not
> followed as it should be, and it's not surprising that things go wrong
> as a result.

I think there is certainly a place for To: and Cc:, but it is my
*personal* (I'm not trying to preach to anyone) that they are a) not
used as perhaps they should be and b) due to (a) not much use, thus I
ignore them.

And yes, I agree, it's due to laziness/lack of time/the fact that they
are pretty pointless in an ML setting that the difference between To:
and Cc: are not seen as important enough to be handled differently.

> So, keep making unreasonable expectations of others and writing poor
> emails if you like, just don't expect the outcome you wish every time,
> as illustrated by what happened earlier in this thread!

Not quite sure how we arrived at this point, but it is my belief that
this misunderstanding didn't have anything to do with mail headers.
Mark and I resolved the real issue in another part of the thread.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 8/9] regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs

[Keerthy]

From: Tero Kristo <t-kristo@ti.com>

Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/regulator/tps65218-regulator.c | 8 ++++++++
 include/linux/mfd/tps65218.h           | 5 +++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
index d1e631d..eb0f5b1 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -180,6 +180,14 @@ static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
 	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
 		return -EINVAL;
 
+	/*
+	 * Certain revisions of TPS65218 will need to have DCDC3 regulator
+	 * enabled always, otherwise an immediate system reboot will occur
+	 * during poweroff.
+	 */
+	if (rid == TPS65218_DCDC_3 && tps->rev == TPS65218_REV_2_1)
+		return 0;
+
 	if (!tps->info[rid]->strobe) {
 		if (rid == TPS65218_DCDC_3)
 			tps->info[rid]->strobe = 3;
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index 85e464e..d1db952 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -63,6 +63,11 @@
 #define TPS65218_CHIPID_CHIP_MASK	0xF8
 #define TPS65218_CHIPID_REV_MASK	0x07
 
+#define TPS65218_REV_1_0		0x0
+#define TPS65218_REV_1_1		0x1
+#define TPS65218_REV_2_0		0x2
+#define TPS65218_REV_2_1		0x3
+
 #define TPS65218_INT1_VPRG		BIT(5)
 #define TPS65218_INT1_AC		BIT(4)
 #define TPS65218_INT1_PB		BIT(3)
-- 
1.9.1

Applied "regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs" to the regulator tree

[Mark Brown]

The patch

   regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 23a34f9d03a5d40a6234855bc069da370708cc9e Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Wed, 10 Aug 2016 17:53:55 +0530
Subject: [PATCH] regulator: tps65218: do not disable DCDC3 during poweroff on
 broken PMICs

Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/regulator/tps65218-regulator.c | 8 ++++++++
 include/linux/mfd/tps65218.h           | 5 +++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
index d1e631d64a20..eb0f5b13841a 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -180,6 +180,14 @@ static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
 	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
 		return -EINVAL;
 
+	/*
+	 * Certain revisions of TPS65218 will need to have DCDC3 regulator
+	 * enabled always, otherwise an immediate system reboot will occur
+	 * during poweroff.
+	 */
+	if (rid == TPS65218_DCDC_3 && tps->rev == TPS65218_REV_2_1)
+		return 0;
+
 	if (!tps->info[rid]->strobe) {
 		if (rid == TPS65218_DCDC_3)
 			tps->info[rid]->strobe = 3;
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index 85e464e32c43..d1db9527fab5 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -63,6 +63,11 @@
 #define TPS65218_CHIPID_CHIP_MASK	0xF8
 #define TPS65218_CHIPID_REV_MASK	0x07
 
+#define TPS65218_REV_1_0		0x0
+#define TPS65218_REV_1_1		0x1
+#define TPS65218_REV_2_0		0x2
+#define TPS65218_REV_2_1		0x3
+
 #define TPS65218_INT1_VPRG		BIT(5)
 #define TPS65218_INT1_AC		BIT(4)
 #define TPS65218_INT1_PB		BIT(3)
-- 
2.8.1

Re: Applied "regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs" to the regulator tree

[Lee Jones]

On Wed, 10 Aug 2016, Mark Brown wrote:

> The patch
> 
>    regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs

Looks like I also need this patch.

Would you be kind enough to shoot me a pull-request please?

> has been applied to the regulator tree at
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
> From 23a34f9d03a5d40a6234855bc069da370708cc9e Mon Sep 17 00:00:00 2001
> From: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> Date: Wed, 10 Aug 2016 17:53:55 +0530
> Subject: [PATCH] regulator: tps65218: do not disable DCDC3 during poweroff on
>  broken PMICs
> 
> Some versions of tps65218 do not seem to support poweroff modes properly
> if DCDC3 regulator is shut-down. Thus, keep it enabled even during
> poweroff if the version info matches the broken silicon revision.
> 
> Signed-off-by: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>  drivers/regulator/tps65218-regulator.c | 8 ++++++++
>  include/linux/mfd/tps65218.h           | 5 +++++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
> index d1e631d64a20..eb0f5b13841a 100644
> --- a/drivers/regulator/tps65218-regulator.c
> +++ b/drivers/regulator/tps65218-regulator.c
> @@ -180,6 +180,14 @@ static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
>  	if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
>  		return -EINVAL;
>  
> +	/*
> +	 * Certain revisions of TPS65218 will need to have DCDC3 regulator
> +	 * enabled always, otherwise an immediate system reboot will occur
> +	 * during poweroff.
> +	 */
> +	if (rid == TPS65218_DCDC_3 && tps->rev == TPS65218_REV_2_1)
> +		return 0;
> +
>  	if (!tps->info[rid]->strobe) {
>  		if (rid == TPS65218_DCDC_3)
>  			tps->info[rid]->strobe = 3;
> diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
> index 85e464e32c43..d1db9527fab5 100644
> --- a/include/linux/mfd/tps65218.h
> +++ b/include/linux/mfd/tps65218.h
> @@ -63,6 +63,11 @@
>  #define TPS65218_CHIPID_CHIP_MASK	0xF8
>  #define TPS65218_CHIPID_REV_MASK	0x07
>  
> +#define TPS65218_REV_1_0		0x0
> +#define TPS65218_REV_1_1		0x1
> +#define TPS65218_REV_2_0		0x2
> +#define TPS65218_REV_2_1		0x3
> +
>  #define TPS65218_INT1_VPRG		BIT(5)
>  #define TPS65218_INT1_AC		BIT(4)
>  #define TPS65218_INT1_PB		BIT(3)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Applied "regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs" to the regulator tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

On Wed, Aug 31, 2016 at 04:01:15PM +0100, Lee Jones wrote:
> On Wed, 10 Aug 2016, Mark Brown wrote:

> > The patch

> >    regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs

> Looks like I also need this patch.

> Would you be kind enough to shoot me a pull-request please?

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/tps65218-dcdc3-workaround

for you to fetch changes up to 23a34f9d03a5d40a6234855bc069da370708cc9e:

  regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs (2016-08-10 18:21:55 +0100)

----------------------------------------------------------------
regulator: tps65218: Workaround for broken DCDC3 disable on some revisions

----------------------------------------------------------------
Tero Kristo (2):
      mfd: tps65218: add version check to the PMIC probe
      regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs

 drivers/mfd/tps65218.c                 | 9 +++++++++
 drivers/regulator/tps65218-regulator.c | 8 ++++++++
 include/linux/mfd/tps65218.h           | 6 ++++++
 3 files changed, 23 insertions(+)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH 9/9] ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode

[Keerthy]

From: Tero Kristo <t-kristo@ti.com>

Without this, the memory will remain active during poweroff consuming
extra power. Please note revision 2.1 PMIC seems to fail when DCDC3
disable is attempted, so this is not done on that PMIC revision. The
PMIC revision checks in the regulator patches make sure of this.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/boot/dts/am437x-sk-evm.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 03e3d02..1c04e27 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -457,6 +457,9 @@
 			regulator-state-mem {
 				regulator-on-in-suspend;
 			};
+			regulator-state-disk {
+				regulator-off-in-suspend;
+			};
 		};
 
 		dcdc4: regulator-dcdc4 {
-- 
1.9.1