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

Aneesh V
2011-01-08T09:13:28Z

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@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