"Gopinath, Thara" <thara@xxxxxx> writes: > The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close > to the end of context save sequence for the pad conf registers, the last context is not > saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the > MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current > safe delay proposed by TI. I believe investigations are going on to whether this delay can be > optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. > We could add a defconfig option for this workaround and enable it on need basis till TI > comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. Kevin > >>>-----Original Message----- >>>From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Menon, >>>Nishanth >>>Sent: Monday, October 05, 2009 10:58 PM >>>To: Kevin Hilman >>>Cc: linux-omap@xxxxxxxxxxxxxxx; Gulati, Shweta >>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 >>> >>>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 -- 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
