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. 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:paul@xxxxxxxxx] 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
