"Gopinath, Thara" <thara@xxxxxx> writes: >>>-----Original Message----- >>>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>>Sent: Tuesday, October 06, 2009 6:47 PM >>>To: Gopinath, Thara >>>Cc: Menon, Nishanth; linux-omap@xxxxxxxxxxxxxxx; Gulati, Shweta >>>Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 >>> >>>"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. > > 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 -- 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
