On Sat, Sep 10, 2011 at 12:04 AM, Kevin Hilman <khilman@xxxxxx> wrote: > Santosh <santosh.shilimkar@xxxxxx> 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<shawn.guo@xxxxxxxxxxxxx> 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. > Will add a comment -- 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
