Hi Santosh,

just posted a series whose aim is the same, please have a look and
let's try to merge the two approaches.

On Thu, Apr 12, 2012 at 12:29:47PM +0100, Santosh Shilimkar wrote:
> The ARMv7 processor setup functions clean and invalidates the
> cpu cache before enabling MMU. The intention here is to start
> with clean CPU local cache.
> 
> But on architectures like Cortex-[A15/A8], this code will end
> up flushing the L2 cache as well which undesirable and incorrect.

Undesirable agreed, can you define incorrect please ?

> The setup functions are used in CPU hotplug scenario's too and
> hence flushing all cache levels should be avoided.
> 

Agreed, but this is also true for __cpu_disable() if we consider hotplug into
the picture. The difference is that __cpu_disable is not v7 specific
that's what I tried to address with my series, a more generic (and of course
arguable) approach.

> Fix this code by restricting the cache flush to local cpu
> cache or L1.
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilim...@ti.com>
> Cc: Catalin Marinas <catalin.mari...@arm.com>
> Cc: Russell King <rmk+ker...@arm.linux.org.uk>
> ---
>  arch/arm/mm/proc-v7.S |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index f1c8486..96cfc31 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -172,7 +172,8 @@ __v7_ca15mp_setup:
>  __v7_setup:
>       adr     r12, __v7_setup_stack           @ the local stack
>       stmia   r12, {r0-r5, r7, r9, r11, lr}
> -     bl      v7_flush_dcache_all
> +     mov     r0, #0x1
> +     bl      v7_flush_dcache_by_level

I did not post my patch here that is similar but basically the idea here is
to clean/invalidate up to Level of Unification Inner Shareable.

That hardcoded 0x1 must be explained, it might work for most of the v7 systems
but I think it should be generalized.

Thanks,
Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to