> 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. Regards, Richard W. -- 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
