[U-Boot] [PATCH 4/8] arm: minor fixes for cache and mmu handling

[Aneesh V]

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<aneesh at 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