On Friday 30 August 2013 10:39 AM, Kevin Hilman wrote: > Rajendra Nayak <[email protected]> writes: > >> On Thursday 29 August 2013 10:50 PM, Kevin Hilman wrote: >>> Rajendra Nayak <[email protected]> writes: >>> >>>> In order to handle errata I688, a page of sram was reserved by doing a >>>> static iotable map. Now that we use gen_pool to manage sram, we can >>>> completely remove all of these static mappings and use gen_pool_alloc() >>>> to get the one page of sram space needed to implement errata I688. >>>> >>>> Suggested-by: Sekhar Nori <[email protected]> >>>> Signed-off-by: Rajendra Nayak <[email protected]> >>> >>> [...] >>> >>>> @@ -71,6 +72,21 @@ void omap_bus_sync(void) >>>> } >>>> EXPORT_SYMBOL(omap_bus_sync); >>>> >>>> +static int __init omap4_sram_init(void) >>>> +{ >>>> + struct device_node *np; >>>> + struct gen_pool *sram_pool; >>>> + >>>> + 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", >>>> + __func__); >>>> + sram_pool = of_get_named_gen_pool(np, "sram", 0); >>> >>> I haven't actually tested this, but if there is no 'sram' property >>> defined... >>> >>>> + sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE); >>> >>> ... does this still behave properly? >> >> I guess not :( >> of_get_named_gen_pool() ends up returning NULL, but passing NULL to >> gen_pool_alloc() >> crashes. Will fix with the additional check for non-NULL sram_pool, thanks. > > OK, that's what I suspected. Thanks for checking/testing. > I miss-understood your comment initially. Now re-reading it, its clear now.
Regards, Santosh -- 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
