On Tue, Sep 29, 2015 at 06:06:36PM +0000, Woodruff, Richard wrote: > > From: Robert Schwebel [mailto:[email protected]] > > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
