LPAE for outer caches functiopns (was Re: [RFC 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl)

On Thu, Aug 09, 2012 at 05:48:44PM +0100, Gregory CLEMENT wrote:

Hi Will,

Hi Gregory,

You will find an updated version of this patch with LPAE support. I've
tested with and without LPAE selected.

Thanks for the patches.

Now I get some warning during compilation: "initialization from
incompatible pointer type [enabled by default]"

It is because the outer_cache_fns struct still embed functions with
unsigned long for address instead of phys_addr_t. You are aware of
it, as you started to work on it with your patch "ARM: 6671/1: LPAE:
use phys_addr_t instead of unsigned long in outercache functions".

Correct, I just fixed up the wrapper functions in that patch since no outer
cache implementations required >32 bits of physical address. You're the
lucky guy with the first implementation of such a controller :)

So a first step would be to update the definitions in struct
outer_cache_fns and also in the files using this prototype, I found
only 4 files:

git grep -w  outer_.*_range arch/arm | grep = | cut -f 1| uniq
arch/arm/mm/cache-feroceon-l2.c:
arch/arm/mm/cache-l2x0.c:
arch/arm/mm/cache-tauros2.c:
arch/arm/mm/cache-xsc3l2.c:

But it is not enough we also fixed the call to theses functions:
git grep -w  outer_.*_range arch/arm | grep -v = | cut -f 1 -d: | uniq
arch/arm/include/asm/outercache.h
arch/arm/kernel/smp.c
arch/arm/kernel/suspend.c
arch/arm/mach-exynos/platsmp.c
arch/arm/mach-highbank/highbank.c
arch/arm/mach-msm/platsmp.c
arch/arm/mach-omap2/omap-secure.c
arch/arm/mach-ux500/platsmp.c
arch/arm/mm/dma-mapping.c
arch/arm/mm/fault-armv.c
arch/arm/plat-versatile/platsmp.c

Most of them use __pa or directly __virt_to_phys, so once the patch
"[PATCH 03/22] ARM: LPAE: use phys_addr_t on virt <--> phys
conversion" will be merged the correct type will be used.

Which patch is this? part of the keystone series?

Finally the last file which need some change will be
arch/arm/mm/dma-mapping.c.

Does it sound correct?

If it does, then I can prepare a patch for it.

Yes please, that sounds like the right direction for this. We should use
phys_addr_t wherever we're dealing with physical addresses.

Cheers,

Will