Hi Richard, On Fri, Sep 25, 2015 at 08:44:29PM +0000, Woodruff, Richard wrote: > > From: Menon, Nishanth > > Sent: Friday, September 25, 2015 9:44 AM > > > > If I688 is not needed on am335x, then it seems there are still some > > > mysteries remaining with this erratum to unravel. Something like > > > difference in the L3 implementation. Maybe somebody from TI can > > > investigate which SoCs this is really needed on? > > > + Richard who probably has the oldest history on the topic. > > > > I suspect strongly that the erratum was discovered during A9 OMAP4 days, > > but never percolated to older SoC erratum documentation. The need of > > barrier logic was clarified with SoC folks to confirm the behavior though. > > -0- > After looking up i688 in data base and reviewing AM335x SOC I do NOT think i688 will exhibit for AM335x. > - it appears not to be using pieces which have issues on path. > > I688 could impact SOCs which use a DMM and the interconnect infrastructure which supports it. > > I believe hang issues on path could be mapped to 3 sources: > - asyncbrige used from MPUSS to Arteris NOC to DMM > - Dual EMIF idle (ocp-connect/disconnect) policy on path > - PL310 idle signal usage on path > > SOCs using similar chassis components of OMAP4430 time are impacted. Errata aspect in generic bridge map to Aegis, J5E, ... > > The hangs are brought out by enabling power management features which causes micro-idles on path which can trigger a lock up. > > Later SOCs pulled in fixes in one or all areas. Some SOCs are not using components. > > -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? 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
