* Adam Ford <aford173@xxxxxxxxx> [161025 05:52]: > The omap2plus_defconfig enables OMAP2, 3, 4 and 5 features, but when > booting an OMAP3 board, I am surprised to see an OMAP4 error. > > [ 0.690704] omap4_sram_init:Unable to allocate sram needed to > handle errata I688 > [ 0.690734] omap4_sram_init:Unable to get sram pool needed to > handle errata I688 > > > It doesn't make sense to me that we do checking in a bunch of places > to see what kind of soc we're running before we do something, but not > when we're trying to run omap4_sram_init. > > While the code inside omap4_sram_init() checks for the presence of > "ti,omap4-mpu" in the device tree, it simply presents the > warning/error message if it's absent, but it continues on. > > Since the sram_pool = of_gen_pool_get(np, "sram", 0) call fails we > present yet another warning/error message. While it doesn't seem to > be hurting anything, it seems like we should check to see if we're > even on the right architecture first. Why not do a check for > "ti,omap4" and if not present, then exit without warning. (or > something similar) Probably best would be to ignore the warning for omap2 and omap3. The others are derived from omap4 for the interconnects and should be at least checked for I688 before we do anything. Regards, Tony -- 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
