Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430

[Kevin Hilman <khilman@deeprootsystems.com>]

"Gopinath, Thara" <thara@ti.com> writes:

>>>-----Original Message-----
>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>Sent: Tuesday, October 06, 2009 6:47 PM
>>>To: Gopinath, Thara
>>>Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta
>>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
>>>
>>>"Gopinath, Thara" <thara@ti.com> 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.
>
> I am not very sure about this as it has the risk of glitch on the
> line. It is probably ok if the ball is not used. But if in use, the
> glitch could create issues.

I don't follow.

IIUC, Nishanth's proposal would be to

In save context:
- manually save ETK_D14 to some static variable (SDRAM)
- initiate the padconf safe 
- poll SAVE_DONE
- here ETK_D14 value saved by HW possibly corrupted, 
  but the copy saved manually should be fine

In restore:
- manually restore ETK_D14 from the static variable

What is wrong with this approach?

Kevin