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.st...@pengutronix.de>
> Tested-by: Bastian Stender <b...@pengutronix.de>
> ---
> 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
> +
> 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?
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
