Santosh <[email protected]> writes: > 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 :)
Sounds like some in-code documentation needs to be added to make this a bit more understandable. Thanks, Kevin -- 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
