On 09/25/2015 09:35 AM, Tony Lindgren wrote: > * Bastian Stender <bst@xxxxxxxxxxxxxx> [150925 05:40]: >> Hi, >> >> On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote: >>> On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote: >>>> Signed-off-by: Bastian Stender <bst@xxxxxxxxxxxxxx> >>>> --- >>>> arch/arm/mach-omap2/omap4-common.c | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c >>>> index 949696b..a3a0cd1 100644 >>>> --- a/arch/arm/mach-omap2/omap4-common.c >>>> +++ b/arch/arm/mach-omap2/omap4-common.c >>>> @@ -131,6 +131,12 @@ static int __init omap4_sram_init(void) >>>> struct device_node *np; >>>> struct gen_pool *sram_pool; >>>> >>>> + /* AM335x is OMAP2+, so no erratum I688 handling needed >>>> + * (see CONFIG_OMAP4_ERRATA_I688) needed >>> >>> This makes no sense. OMAP4 is OMAP2+ as well, but it needs the erratum. >>> In fact, all code in mach-omap2 is "OMAP2+". >>> >>> So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled. >> >> So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" node >> + sram property for I688 handling? > > If the errata is interconnect related and applies for omap4+, then > the interconnects are the same also on dm81xx and am335x AFAIK. > > 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? > > Regards, > > Tony > + 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. Regards, Nishanth Menon -- 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
