[PATCH] mfd: arizona: Move chip reset to before register patch

[PATCH] mfd: arizona: Move chip reset to before register patch

[Charles Keepax]

In the absence of a physical reset line the chip is reset by writing the
first register, this was done after the register patch was applied which
negates the settings applied in the register patch.

This patch moves the reset to take place before the register patch is
applied.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
 drivers/mfd/arizona-core.c |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 1b48f20..1d241ea 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -366,6 +366,15 @@ int __devinit arizona_dev_init(struct arizona *arizona)
 
 	regcache_cache_only(arizona->regmap, false);
 
+	/* If we have a /RESET GPIO we'll already be reset */
+	if (!arizona->pdata.reset) {
+		ret = regmap_write(arizona->regmap, ARIZONA_SOFTWARE_RESET, 0);
+		if (ret != 0) {
+			dev_err(dev, "Failed to reset device: %d\n", ret);
+			goto err_reset;
+		}
+	}
+
 	ret = regmap_read(arizona->regmap, ARIZONA_SOFTWARE_RESET, &reg);
 	if (ret != 0) {
 		dev_err(dev, "Failed to read ID register: %d\n", ret);
@@ -413,15 +422,6 @@ int __devinit arizona_dev_init(struct arizona *arizona)
 	if (ret != 0)
 		dev_err(arizona->dev, "Failed to apply patch: %d\n", ret);
 
-	/* If we have a /RESET GPIO we'll already be reset */
-	if (!arizona->pdata.reset) {
-		ret = regmap_write(arizona->regmap, ARIZONA_SOFTWARE_RESET, 0);
-		if (ret != 0) {
-			dev_err(dev, "Failed to reset device: %d\n", ret);
-			goto err_reset;
-		}
-	}
-
 	ret = arizona_wait_for_boot(arizona);
 	if (ret != 0) {
 		dev_err(arizona->dev, "Device failed initial boot: %d\n", ret);
-- 
1.7.2.5

Re: [PATCH] mfd: arizona: Move chip reset to before register patch

[Mark Brown]

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

On Mon, Nov 12, 2012 at 05:56:48PM +0000, Charles Keepax wrote:
> In the absence of a physical reset line the chip is reset by writing the
> first register, this was done after the register patch was applied which
> negates the settings applied in the register patch.
> 
> This patch moves the reset to take place before the register patch is
> applied.

No, we should never write to the chip until we have successfully
identified it.  Do a sync or similar instead (we should be triggering
this very soon afterwards via runtime PM anyway).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] mfd: arizona: Move chip reset to before register patch

[Charles Keepax]

On Tue, Nov 13, 2012 at 02:56:20PM +0900, Mark Brown wrote:
> On Mon, Nov 12, 2012 at 05:56:48PM +0000, Charles Keepax wrote:
> > In the absence of a physical reset line the chip is reset by writing the
> > first register, this was done after the register patch was applied which
> > negates the settings applied in the register patch.
> > 
> > This patch moves the reset to take place before the register patch is
> > applied.
> 
> No, we should never write to the chip until we have successfully
> identified it.  Do a sync or similar instead (we should be triggering
> this very soon afterwards via runtime PM anyway).

In that case I would be inclined to seperate out the chip
identification and the register patch doing the reset in between.
Is this something that would sound reasonable or would you rather
just add a sync after the reset?

Re: [PATCH] mfd: arizona: Move chip reset to before register patch

[Mark Brown]

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

On Tue, Nov 13, 2012 at 01:12:19PM +0000, Charles Keepax wrote:
> On Tue, Nov 13, 2012 at 02:56:20PM +0900, Mark Brown wrote:

> > No, we should never write to the chip until we have successfully
> > identified it.  Do a sync or similar instead (we should be triggering
> > this very soon afterwards via runtime PM anyway).

> In that case I would be inclined to seperate out the chip
> identification and the register patch doing the reset in between.
> Is this something that would sound reasonable or would you rather
> just add a sync after the reset?

Just do a sync, make sure that we mark the map as dirty when we do the
reset via register write and it'll not have any effect anyway.  We
should also check if we've got the LDO and use that for reset too
actually...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] mfd: arizona: Move chip reset to before register patch

[Charles Keepax]

On Wed, Nov 14, 2012 at 10:20:09AM +0900, Mark Brown wrote:
> On Tue, Nov 13, 2012 at 01:12:19PM +0000, Charles Keepax wrote:
> > On Tue, Nov 13, 2012 at 02:56:20PM +0900, Mark Brown wrote:
> 
> > > No, we should never write to the chip until we have successfully
> > > identified it.  Do a sync or similar instead (we should be triggering
> > > this very soon afterwards via runtime PM anyway).
> 
> > In that case I would be inclined to seperate out the chip
> > identification and the register patch doing the reset in between.
> > Is this something that would sound reasonable or would you rather
> > just add a sync after the reset?
> 
> Just do a sync, make sure that we mark the map as dirty when we do the
> reset via register write and it'll not have any effect anyway.  We
> should also check if we've got the LDO and use that for reset too
> actually...

The way the code is layed out at the moment if we don't
successfully get the LDO we won't get as far as the register
write reset. Meaning that if we can do the reset by cycling the
power on the LDO is there any point in having the option to do
the reset via a register write later?

Re: [PATCH] mfd: arizona: Move chip reset to before register patch

[Mark Brown]

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

On Wed, Nov 14, 2012 at 10:48:54AM +0000, Charles Keepax wrote:
> On Wed, Nov 14, 2012 at 10:20:09AM +0900, Mark Brown wrote:

> > Just do a sync, make sure that we mark the map as dirty when we do the
> > reset via register write and it'll not have any effect anyway.  We
> > should also check if we've got the LDO and use that for reset too
> > actually...

> The way the code is layed out at the moment if we don't
> successfully get the LDO we won't get as far as the register
> write reset. Meaning that if we can do the reset by cycling the
> power on the LDO is there any point in having the option to do
> the reset via a register write later?

No, we can't rely on having control over the LDO - it might be always
on.  But we should ideally try to use it as a fallback, using a notifier
to find out if that worked or not.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2] mfd: arizona: Sync regcache after reset

[Charles Keepax]

In the absence of a physical reset line the chip is reset by writing the
first register, which is done after the register patch has been applied.
This patch synchronises the register cache after the reset to preserve
any register changes that had been applied.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---

I will look at the LDO reset and submit it as a seperate patch at
a later date.

 drivers/mfd/arizona-core.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 202bf55..ad1ca49 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -415,11 +415,19 @@ int __devinit arizona_dev_init(struct arizona *arizona)
 
 	/* If we have a /RESET GPIO we'll already be reset */
 	if (!arizona->pdata.reset) {
+		regcache_mark_dirty(arizona->regmap);
+
 		ret = regmap_write(arizona->regmap, ARIZONA_SOFTWARE_RESET, 0);
 		if (ret != 0) {
 			dev_err(dev, "Failed to reset device: %d\n", ret);
 			goto err_reset;
 		}
+
+		ret = regcache_sync(arizona->regmap);
+		if (ret != 0) {
+			dev_err(dev, "Failed to sync device: %d\n", ret);
+			goto err_ldoena;
+		}
 	}
 
 	ret = arizona_wait_for_boot(arizona);
-- 
1.7.2.5

Re: [PATCH v2] mfd: arizona: Sync regcache after reset

[Mark Brown]

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

On Wed, Nov 14, 2012 at 11:31:38AM +0000, Charles Keepax wrote:
> In the absence of a physical reset line the chip is reset by writing the
> first register, which is done after the register patch has been applied.
> This patch synchronises the register cache after the reset to preserve
> any register changes that had been applied.
> 
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>

Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Please submit patches as covered in SubmittingPatches, you've added a
random "Re" to the subject line...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH v2] mfd: arizona: Sync regcache after reset

[Charles Keepax]

In the absence of a physical reset line the chip is reset by writing the
first register, which is done after the register patch has been applied.
This patch synchronises the register cache after the reset to preserve
any register changes that had been applied.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/mfd/arizona-core.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 202bf55..ad1ca49 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -415,11 +415,19 @@ int __devinit arizona_dev_init(struct arizona *arizona)
 
 	/* If we have a /RESET GPIO we'll already be reset */
 	if (!arizona->pdata.reset) {
+		regcache_mark_dirty(arizona->regmap);
+
 		ret = regmap_write(arizona->regmap, ARIZONA_SOFTWARE_RESET, 0);
 		if (ret != 0) {
 			dev_err(dev, "Failed to reset device: %d\n", ret);
 			goto err_reset;
 		}
+
+		ret = regcache_sync(arizona->regmap);
+		if (ret != 0) {
+			dev_err(dev, "Failed to sync device: %d\n", ret);
+			goto err_ldoena;
+		}
 	}
 
 	ret = arizona_wait_for_boot(arizona);
-- 
1.7.2.5

[PATCH v3] mfd: arizona: Sync regcache after reset

[Charles Keepax]

In the absence of a physical reset line the chip is reset by writing the
first register, which is done after the register patch has been applied.
This patch synchronises the register cache after the reset to preserve
any register changes that had been applied.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---

Apologies but it seems I accidentally generated yesterdays patch
against a local development branch rather than the upstream
branch. Sorry for the inconvience here is a fixed version.


 drivers/mfd/arizona-core.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 202bf55..f4f9bf8 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -415,11 +415,19 @@ int __devinit arizona_dev_init(struct arizona *arizona)
 
 	/* If we have a /RESET GPIO we'll already be reset */
 	if (!arizona->pdata.reset) {
+		regcache_mark_dirty(arizona->regmap);
+
 		ret = regmap_write(arizona->regmap, ARIZONA_SOFTWARE_RESET, 0);
 		if (ret != 0) {
 			dev_err(dev, "Failed to reset device: %d\n", ret);
 			goto err_reset;
 		}
+
+		ret = regcache_sync(arizona->regmap);
+		if (ret != 0) {
+			dev_err(dev, "Failed to sync device: %d\n", ret);
+			goto err_reset;
+		}
 	}
 
 	ret = arizona_wait_for_boot(arizona);
-- 
1.7.2.5