> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
