Hi Albert, On Saturday 08 January 2011 12:34 PM, Albert ARIBAUD wrote: > Hi Aneesh, > > Le 22/12/2010 12:54, Aneesh V a écrit : >> 1. make sure that page table setup is not done multiple times >> 2. flush_dcache_all() is more appropriate while disabling cache >> than a range flush on the entire memory(flush_cache()) >> >> Provide a default implementation for flush_dcache_all() >> for backward compatibility and to avoid build issues. >> >> Signed-off-by: Aneesh V<ane...@ti.com> >> --- >> arch/arm/lib/cache-cp15.c | 9 +++++++-- >> arch/arm/lib/cache.c | 13 ++++++++++++- >> 2 files changed, 19 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c >> index ca526fb..20aa993 100644 >> --- a/arch/arm/lib/cache-cp15.c >> +++ b/arch/arm/lib/cache-cp15.c >> @@ -94,13 +94,18 @@ static inline void mmu_setup(void) >> set_cr(reg | CR_M); >> } >> >> +static int mmu_enabled(void) >> +{ >> + return get_cr()& CR_M; >> +} >> + >> /* cache_bit must be either CR_I or CR_C */ >> static void cache_enable(uint32_t cache_bit) >> { >> uint32_t reg; >> >> /* The data cache is not active unless the mmu is enabled too */ >> - if (cache_bit == CR_C) >> + if ((cache_bit == CR_C)&& !mmu_enabled()) >> mmu_setup(); >> reg = get_cr(); /* get control reg. */ >> cp_delay(); > > Do you know why double MMU setups happen? Can we not fix the execution > path and remove the second MMU setup call there, rather that catching t > on the fly to ignore it?
Please note that mmu_setup() was getting called unconditionally from dcache_enable(). I see that some drivers are calling dcache_enable() and there are u-boot commands for enabling disabling cache. Consequently mmu_setup() may get called multiple times. Do we want to prevent dcache_enable() from being called multiple times? Best regards, Aneesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot