Kevin Hilman had written, on 10/05/2009 12:04 PM, the following:
y@xxxxxxxxxxxx writes:
From: Shweta Gulati <shweta.gulati@xxxxxx>
Please add descriptive changelog, including Erratta number and
summary of the bug.
Signed-off-by: Shweta Gulati <shweta.gulati@xxxxxx>
---
arch/arm/mach-omap2/pm34xx.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a9eda25..38f4781 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -140,6 +140,12 @@ static void omap3_core_save_context(void)
omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
control_padconf_off |= START_PADCONF_SAVE;
omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
+ /* Due to Silicon Bug on context restore it is found
+ * that the CONTROL_PAD_CONF_ETK14 register is not saved into
+ * scratch pad memory sometimes. To rectify it delay acess by Mpu
+ * for 300us for scm to finish saving task
+ */
+ udelay(300);
Why 300 usecs?
300uSec could be optimized as I understand.
Is ETK14 the only register not saved?
The bug as I understand is that the register is saved, but restore
potentially can corrupt the values.
there is an alternative implementation possible:
a) we save the register in a seperate variable
b) we allow the restore issue to kick us (essentially allow it to be
corrupted)
c) we over write the restored value with the saved value.
This has the risk of a glitch on the line (between the corrupted restore
data to the time we restore with correct data).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
