IOn Sat, Sep 10, 2011 at 5:04 AM, Shawn Guo <shawn.guo@xxxxxxxxxxxxx> wrote: > 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<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 :) >> > Aha, no wonder that I read it wrongly. The parameter passing in r0 > is here simply for confusing people. > No It's not. Same cod is used for CPUIDLE and we do have different C-states than just OSWR. ON and INACTIVE makes use of it. > 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 :) > It's just a label. All L2 related code and checks for the valid state is kept under that by purpose. Regards Santosh -- 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
