Hello Vishwa, Thanks for the info. a few quick questions: On Thu, 16 Sep 2010, Sripathy, Vishwanath wrote: > > -----Original Message----- > > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > > Sent: Thursday, September 16, 2010 3:05 AM > > > > On Tue, 25 May 2010, Reddy, Teerth wrote: > > > > > > -----Original Message----- > > > > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > > > > Sent: Wednesday, May 19, 2010 6:03 AM > > > > To: Reddy, Teerth > > > > > > > > On Fri, 23 Apr 2010, Reddy, Teerth wrote: > > > > > > > > > From: Teerth Reddy <teerth@xxxxxx> > > > > > > > > > > This patch has the workaround for errata 1.176. > > > > What's the current status of this patch? Still waiting for an updated > > version. > > We have realized that this errata is not applicable if reset is > triggered via dpll3 reset. The rootcasuse of the issues was that incase > of warm reset, SDRC is not sensitive to the warm reset, but the > interconect is reset on the fly, thus causing a misalignment between > SDRC logic, interconect logic and DDR memory state. Hence the workaround > was proposed. However, incase of dpll3 reset, sdrc also gets reset. In > omap_prcm_arch_reset, system reset is triggered via dpll3 reset, so this > WA is not applicable. 1. So by "warm reset," are you referring to the software warm reset triggered by GLOBAL_SW_RST, or by another mechanism? 2. If GLOBAL_SW_RST, what do you think about adding a brief comment in the code warning people not to use GLOBAL_SW_RST unless they implement the Errata 1.176 sequence? - Paul -- 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
