Hi, On Tue, 23 Jun 2009, Woodruff, Richard wrote:
> > From: Paul Walmsley [mailto:p...@pwsan.com] > > Sent: Tuesday, June 23, 2009 3:05 PM > > > Looks like the significant difference is the use of CLKCTRL = 0x2 (+ > > AUTOCOUNT). Maybe there is some SDRC bug related to CLKCTRL = 0x2 that > > causes this problem? Perhaps the problem is partially related to PWDENA = > > 1 and erratum 1.150? Anyway, will do a test run here with this SDRC_POWER > > register value and see if the problem reproduces. > > It is my guess not for PWDENA as it was reported on a system with that > not set. Yes that should not enabled per errata. Anyway it only does > something in OFF type scenarios where you don't use self-refresh. > "Typical" use cases don't seem to be using this. > > There are a few unlock events which are best for any focused test. Most > are supposed to auto-relock but ... I've heard of some validation tests > in a few areas maybe they will yield something. A quick note: in stress testing here, was able to confirm that SDRC_POWER = 0x000200AD causes problems under memory load and intensive CORE DVFS. SDRC_POWER = 0x0002009D seems to work fine. The difference is CLKCTRL = 1 (works) vs. CLKCTRL = 2 (fails). According to the TRM, CLKCTRL = 2 enables self-refresh when AUTOCOUNT reaches 0. There is probably some race between AUTOCOUNT and the CORE DVFS SRAM code, or it is tickling some SDRC bug. Will look into this further later. By the way, there appears to be a TRM bug in the "Dynamic Power Saving Configurations" table in the SDRC chapter. The "External SDRC CLK" column should have "after AUTOCOUNT expiration" for CLKCTRL = 1 rows. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
