On Fri, Sep 09, 2011 at 10:29:49PM +0530, Santosh wrote: > On Friday 09 September 2011 08:57 PM, Shawn Guo wrote: > >On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote: > >>On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo<[email protected]> wrote: > >>>On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote: > >>>>On Friday 09 September 2011 01:34 PM, Shawn Guo wrote: > >>>>>Hi Santosh, > > [...] > > >>#ifdef CONFIG_CACHE_L2X0 > >> /* > >> * Clean and invalidate the L2 cache. > >> * Common cache-l2x0.c functions can't be used here since it > >> * uses spinlocks. We are out of coherency here with data cache > >> * disabled. The spinlock implementation uses exclusive load/store > >> * instruction which can fail without data cache being enabled. > >> * OMAP4 hardware doesn't support exclusive monitor which can > >> * overcome exclusive access issue. Because of this, CPU can > >> * lead to deadlock. > >> */ > >>l2x_clean_inv: > >> bl omap4_get_sar_ram_base > >> mov r8, r0 > >> mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR > >> ands r5, r5, #0x0f > >> ldreq r0, [r8, #L2X0_SAVE_OFFSET0] > >> ldrne r0, [r8, #L2X0_SAVE_OFFSET1] > >> cmp r0, #3 > >> bne do_WFI > > > >It looks like you are bypassing L2 clean and invalidate for cases > >"1" and "2" here. But I really do not understand how you get r0 > >back here. > > > The value which is passed in R0 is also stored in scratch patch memory > and retrieved using L2X0_SAVE_OFFSET0. > Simple :) > Aha, no wonder that I read it wrongly. The parameter passing in r0 is here simply for confusing people.
Also, IMO, lable "l2x_clean_inv" should be put after the "bne do_WFI". Otherwise, my original statement (it seems l2x_clean_inv will be called for case "2") stands correct :) -- Regards, Shawn -- 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
