Am Freitag, den 25.09.2015, 20:44 +0000 schrieb Woodruff, Richard: > > 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. So please help me to get this straight: Errata I688 only affects OMAP4 which is consequently the only user of omap_interconnect_sync() in it's WFI enter sequence, which in turn is the only user of the SRAM scratch area to work around the erratum. The OMAP specific barrier implementation which should be used also on other SoCs does not need any SRAM scratch, but uses a part of DRAM to do the strongly ordered access. So it is safe to say that we only ever need to run the initcall allocating the SRAM scratch area on OMAP4. Is this conclusion correct? Thanks, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
