On Tue, Sep 29, 2015 at 06:06:36PM +0000, Woodruff, Richard wrote: > > From: Robert Schwebel [mailto:r.schwebel@xxxxxxxxxxxxxx] > > Sent: Tuesday, September 29, 2015 12:50 PM > > > -1- > > > Barrier side effects of the patch may be beneficial for other reasons. But > > AM335x should be immune from this particular issue. > > > > Is this a matter of fact, or just an assumption? > > Could you clarify this with the TI hardware folks? > > Which point are you asking for clarification on? > > -0- is factual. The conditions to trigger bridge bugs are specific and tied to cited component issues. These factors can lead to a HW clock gate before completion of bus protocol. The result is a misaligned of HW FIFO pointer inside of the retiming bridge. At hang it is possible to attach through JTAG-DAP and see writes going to the wrong address due to misalignment. The bridge component did fail in simulation and was fixed per hw-bug database as I mention. In my sampling of customers which ramped with aggressive power management ~10/10 I worked with hit this issue on 4430 on robustness tests. We did verify signatures at hang. > > There may be other errata which have a hang condition which users experience but their root cause is not the same as i688. Really any action which results in a bus protocol violation can end up in a hang. For instance a wrong sequencing of DSS pipeline/DMA control can cause the IP to crash. If the IP crashes while in the middle of talking with DDR a hang will result. There is no timeout on the interconnect so a watchdog will be needed to recover from such events. > > -1- is partially an assumption based on previous Linux macros and code structure. Thanks for the explanation! rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- 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
