"Woodruff, Richard" <r-woodru...@ti.com> writes: > Hi Paul, > > Hm, seems my mailing is out to lunch today... I'll be worse than normal in > protocol and top post. > > I've seen this issue on a couple custom boards. In these instances > I've not had access to boot loaders. I would expect this issue > would show up in the wild in some devices. It might be ok to move > to at least init. Having it at deadlock spot is a bit more > conservative.
Richard, since Paul and I cannot reproduce this currently, would you be able to test if a fix at init fixes the problems that you've seen? Kevin > I've only seen the condition along side of very aggressive SDRC_POWER > settings. Its my guess beagle doesn't enable all those features yet. Unless > you have a bunch of beagle accessories attached, I'm not sure how good a > reference beagle is for system DVFS validation. > > I've not taken stat's to see how much it happens. The alternate to the > latency spike is a dead lock which is clealry not wanted. Net-Net I see this > as more a plus than a minus in current form. > > If you have some time you might expirment with beagle and see if you can > trigger the condition. > > Regards, > Richard W. > > -----Original Message----- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, June 17, 2009 3:04 AM > > So, what is different about your setup? The usual suite of questions: > > - What chip revisions/boards does this affect? > > - Is this specific to certain bootloaders? > > - Has anyone else out there seen this problem? > > Rather than working around an occasional DLL failure to lock, is it possible > to reset the DLL earlier in the boot process, as Richard's commit message > suggests? That would be preferable to this approach. A back-of-the-envelope > assessment suggests that this patch could cause unpredictable, additional 1.5 > millisecond latency spikes whenever the workaround triggers (since OCM RAM is > marked uncacheable). -- 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
