"Gopinath, Thara" <thara@xxxxxx> writes: > Will repost the patch with the defconfig option added. So that this can be disabled if not needed. ok, please update the changelog as well as describe the 300usec value in terms of cycles. IOW, is 300usecs going to work at lower OPPs also? Kevin >>>-----Original Message----- >>>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>>Sent: Tuesday, October 06, 2009 8:19 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: >>> >>>>>>-----Original Message----- >>>>>>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>>>>>Sent: Tuesday, October 06, 2009 7:50 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: >>>>>> >>>>>>>>>-----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? >>>> In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14. >>>> Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not >>>happen >>>> 1. Before going to Off - the pin is pulled high >>>> 2. Off >>>> 3. h/w restore - Has done bad save. So bad value restored. Say pull low. >>>> 4. Manual restore - the pin is again pulled high. >>>> >>>> Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with >>>this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1 >>>this glitch might be unacceptable. >>> >>>I see now. Thanks for explanation. >>> >>>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
