2018-10-02 10:42:14

by Richard Fitzgerald

[permalink] [raw]
Subject: [PATCH v2 1/2] mfd: madera: Increase wait time for silicon reset

Based on latest silicon validation, we should allow at least
2 milliseconds after DCVDD enable or hard reset before trying
to communicate with the silicon.

Previously the delay was done as a side-effect of
madera_disable_hard_reset(). As we also need this delay when
enabling DCVDD (with or without hard reset) it is better for it
to be obvious where it happens in every power-up sequence rather
than hidden within another call in some cases. So it has been
moved out into a separate function call.

Signed-off-by: Richard Fitzgerald <[email protected]>
---
drivers/mfd/madera-core.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
index 440030cecbbd..1dedfe68a3dc 100644
--- a/drivers/mfd/madera-core.c
+++ b/drivers/mfd/madera-core.c
@@ -135,6 +135,15 @@ EXPORT_SYMBOL_GPL(madera_name_from_type);
#define MADERA_BOOT_POLL_INTERVAL_USEC 5000
#define MADERA_BOOT_POLL_TIMEOUT_USEC 25000

+static void madera_por_delay(void)
+{
+ /*
+ * Delay after DCVDD enable or hard reset to allow for silicon POR
+ * (power-on reset).
+ */
+ usleep_range(2000, 3000);
+}
+
static int madera_wait_for_boot(struct madera *madera)
{
ktime_t timeout;
@@ -209,7 +218,6 @@ static void madera_disable_hard_reset(struct madera *madera)
return;

gpiod_set_raw_value_cansleep(madera->pdata.reset, 1);
- usleep_range(1000, 2000);
}

static int __maybe_unused madera_runtime_resume(struct device *dev)
@@ -225,6 +233,8 @@ static int __maybe_unused madera_runtime_resume(struct device *dev)
return ret;
}

+ madera_por_delay();
+
regcache_cache_only(madera->regmap, false);
regcache_cache_only(madera->regmap_32bit, false);

@@ -440,6 +450,7 @@ int madera_dev_init(struct madera *madera)
}

madera_disable_hard_reset(madera);
+ madera_por_delay();

regcache_cache_only(madera->regmap, false);
regcache_cache_only(madera->regmap_32bit, false);
--
2.11.0



2018-10-02 10:42:00

by Richard Fitzgerald

[permalink] [raw]
Subject: [PATCH v2 2/2] mfd: madera: Wait for BOOT_DONE before reading device ID

It isn't safe to read the device ID in the SOFTWARE_RESET
register until the silicon boot sequence has completed. This
patch rearranges the code to wait until BOOT_DONE is set.

If we don't have a hard reset line we want to defer writing a
soft reset command until we have identified the silicon as
something we recognize. As the BOOT_DONE bit is sticky it is
safe to wait for it without issuing a soft reset first, because
the most recent power-up will have caused a boot sequence and
set the bit. Note that the boot sequence is not the same as a
reset so we still have to soft reset to get the codec into a
known state.

Signed-off-by: Stuart Henderson <[email protected]>
Signed-off-by: Richard Fitzgerald <[email protected]>
---
drivers/mfd/madera-core.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
index 1dedfe68a3dc..e114ca5e6c3f 100644
--- a/drivers/mfd/madera-core.c
+++ b/drivers/mfd/madera-core.c
@@ -455,10 +455,13 @@ int madera_dev_init(struct madera *madera)
regcache_cache_only(madera->regmap, false);
regcache_cache_only(madera->regmap_32bit, false);

- /*
- * Now we can power up and verify that this is a chip we know about
- * before we start doing any writes to its registers.
- */
+ /* BOOT_DONE must be set before we can read the device ID */
+ ret = madera_wait_for_boot(madera);
+ if (ret) {
+ dev_err(madera->dev, "Device failed initial boot: %d\n", ret);
+ goto err_reset;
+ }
+
ret = regmap_read(madera->regmap, MADERA_SOFTWARE_RESET, &hwid);
if (ret) {
dev_err(dev, "Failed to read ID register: %d\n", ret);
@@ -528,12 +531,13 @@ int madera_dev_init(struct madera *madera)
ret = madera_soft_reset(madera);
if (ret)
goto err_reset;
- }

- ret = madera_wait_for_boot(madera);
- if (ret) {
- dev_err(madera->dev, "Device failed initial boot: %d\n", ret);
- goto err_reset;
+ ret = madera_wait_for_boot(madera);
+ if (ret) {
+ dev_err(madera->dev, "Device failed initial soft reboot: %d\n",
+ ret);
+ goto err_reset;
+ }
}

ret = regmap_read(madera->regmap, MADERA_HARDWARE_REVISION,
--
2.11.0


2018-10-02 10:56:35

by Charles Keepax

[permalink] [raw]
Subject: Re: [PATCH v2 1/2] mfd: madera: Increase wait time for silicon reset

On Tue, Oct 02, 2018 at 11:41:33AM +0100, Richard Fitzgerald wrote:
> Based on latest silicon validation, we should allow at least
> 2 milliseconds after DCVDD enable or hard reset before trying
> to communicate with the silicon.
>
> Previously the delay was done as a side-effect of
> madera_disable_hard_reset(). As we also need this delay when
> enabling DCVDD (with or without hard reset) it is better for it
> to be obvious where it happens in every power-up sequence rather
> than hidden within another call in some cases. So it has been
> moved out into a separate function call.
>
> Signed-off-by: Richard Fitzgerald <[email protected]>
> ---

Reviewed-by: Charles Keepax <[email protected]>

Thanks,
Charles

2018-10-02 10:57:49

by Charles Keepax

[permalink] [raw]
Subject: Re: [PATCH v2 2/2] mfd: madera: Wait for BOOT_DONE before reading device ID

On Tue, Oct 02, 2018 at 11:41:34AM +0100, Richard Fitzgerald wrote:
> It isn't safe to read the device ID in the SOFTWARE_RESET
> register until the silicon boot sequence has completed. This
> patch rearranges the code to wait until BOOT_DONE is set.
>
> If we don't have a hard reset line we want to defer writing a
> soft reset command until we have identified the silicon as
> something we recognize. As the BOOT_DONE bit is sticky it is
> safe to wait for it without issuing a soft reset first, because
> the most recent power-up will have caused a boot sequence and
> set the bit. Note that the boot sequence is not the same as a
> reset so we still have to soft reset to get the codec into a
> known state.
>
> Signed-off-by: Stuart Henderson <[email protected]>
> Signed-off-by: Richard Fitzgerald <[email protected]>
> ---

Reviewed-by: Charles Keepax <[email protected]>

Thanks,
Charles