Will repost the patch with the defconfig option added. So that this can be disabled if not needed. Regards Thara >>-----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
