Am Montag, den 16.11.2015, 14:24 +0200 schrieb Grygorii Strashko:
> On 11/16/2015 01:25 PM, Lucas Stach wrote:
> > omap_interconnect_sync() is the only user of the SRAM scratch area
> > allocated in the omap4_sram_init initcall. The interconnect sync is
> > used exclusively in the OMAP4 specific WFI implementation, so there
> > is no point in allocating the SRAM scratch on other SoC types.
> >
> > Bail out of the initcall if the kernel is not running on OMAP4 to
> > avoid a confusing warning about being unable to allocate the SRAM
> > needed for I688 handling.
> >
> > Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
> > Tested-by: Bastian Stender <bst@xxxxxxxxxxxxxx>
> > ---
> > arch/arm/mach-omap2/omap4-common.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
> > index 949696b6f17b..6db393a30a28 100644
> > --- a/arch/arm/mach-omap2/omap4-common.c
> > +++ b/arch/arm/mach-omap2/omap4-common.c
> > @@ -131,6 +131,9 @@ static int __init omap4_sram_init(void)
> > struct device_node *np;
> > struct gen_pool *sram_pool;
> >
> > + if (!cpu_is_omap44xx())
> > + return 0;
>
> This one affects on am43xx also
>
So you are saying this erratum is also present on AM43xx? I wasn't able
to deduce this from the information provided by Richard Woodruff.
>
> > +
> > np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
> > if (!np)
> > pr_warn("%s:Unable to allocate sram needed to handle errata I688\n",
>
> Since all OMAP4+ platforms are now DT based why can't we just return from here silently?
>
If we are unable to allocate the SRAM needed to work around I688 this is
a real error on platforms that expose this erratum, so silently bailing
out at this point may obscure a real issue.
Regards,
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
