Hello,
The purpose of this patch set is to add support for Aurora L2 Cache
Controller used by Armada 370 and Armada XP SoCs. As it was initially
designed by Marvell engineer to be compatible with the ARM L2 Cache
Controller, we chose to reuse the existing code and to just extend it
to support the differences and improvements brought by the Aurora
controller.The diffstat looks like:
Documentation/devicetree/bindings/arm/l2cc.txt | 9 +
arch/arm/boot/dts/armada-370.dtsi | 6 +
arch/arm/boot/dts/armada-xp.dtsi | 7 +
arch/arm/include/asm/hardware/cache-aurora-l2.h | 51 ++++
arch/arm/include/asm/hardware/cache-l2x0.h | 1 +
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/irq-armada-370-xp.c | 4 +
arch/arm/mm/cache-l2x0.c | 297 +++++++++++++++++++++--
8 files changed, 362 insertions(+), 14 deletions(-)
The main differences and improvements are:
- no cache id part number available through hardware (need to get it
by the DT).
- always write through mode available.
- two flavors of the controller 'outer cache' and 'system cache' (the
last one meaning maintenance operations on L1 are broadcasted to the
L2 and L2 performs the same operation).
- in outer cache mode, the cache maintenance operations are improved
and can be done on a range inside a page and are not limited to a
cache line.
- during resume the controller need to restore the ctrl register.
The first patch adds some modifications in the driver
infrastructure. As most of the outer cache functions can use the
Aurora improvements, we had to introduce new functions. So we thought
it was better to use a outer_cache_fns field inside l2x0_of_data and
just memcopy it into outer_cache depending of the type of the l2x0
cache.
If the change we have made in the l2x0 driver are judged too invasive
we are perfectly fine to submit a dedicated driver for the Aurora
Cache Controller.
For interested people you can find the results of the cache benchmarks
which was ran for validate the driver:
htps://github.com/MISL-EBU-System-SW/mainline-public/wiki/Cache-bench-results-for-Aurora-L2-cache-controller-on-Armada-XP-and-Armada-370
All the data related to this benchmark are hosted at:
http://free-electrons.com/%7Egregory/pub/Armada-370-xp/cachebench-results/
The git branch aurora-L2-cache-ctrl is visible at
https://github.com/MISL-EBU-System-SW/mainline-public.git
Regards,
Gregory
Instead of having multiple functions belonging to outer_cache and
filling this structure on the fly, use a outer_cache_fns field inside
l2x0_of_data and just memcopy it into outer_cache depending of the
type of the l2x0 cache. For non DT case, the former code was kept.
Signed-off-by: Gregory CLEMENT <redacted>
Cc: Barry Song <redacted>
Cc: Will Deacon <redacted>
Cc: Santosh Shilimkar <redacted>
Cc: Rob Herring <redacted>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <redacted>
---
arch/arm/mm/cache-l2x0.c | 38 ++++++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 8 deletions(-)
@@ -20,6 +20,12 @@/{model="Marvell Armada 370 family SoC";compatible="marvell,armada370","marvell,armada-370-xp";+L2:l2-cache{+compatible="marvell,aurora-cache-with-outer";+reg=<0xd00080000x1000>;+cache-id-part=<0x100>;+wt-override;+};mpic:interrupt-controlleratd0020000{reg=<0xd0020a000x1d0>,
@@ -22,6 +22,13 @@model="Marvell Armada XP family SoC";compatible="marvell,armadaxp","marvell,armada-370-xp";+L2:l2-cache{+compatible="marvell,aurora-cache-no-outer";+reg=<0xd00080000x1000>;+cache-id-part=<0x100>;+wt-override;+};+mpic:interrupt-controlleratd0020000{reg=<0xd0020a000x1d0>,<0xd00218700x58>;
@@ -6,6 +6,7 @@ config MACH_ARMADA_370_XPbool"Marvell Armada 370 and Aramada XP boards"selectARMADA_370_XP_TIMERselectCPU_V7+selectCACHE_L2X0helpSay'Y'hereifyouwantyourkerneltosupportboardsbasedon
Aurora is a L2 Cache Controller designed to be compatible with the
L2x0 Cache Controller. L2X0 OF bindings are extended to support some
specificity of Aurora (no cache id part number available through
hardware, always write through mode, choice between outer cache and
system cache).
Signed-off-by: Gregory CLEMENT <redacted>
Cc: Grant Likely <redacted>
Cc: Rob Herring <redacted>
Cc: Russell King <redacted>
Cc: Barry Song <redacted>
Cc: Will Deacon <redacted>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <redacted>
---
Documentation/devicetree/bindings/arm/l2cc.txt | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -10,6 +10,12 @@ Required properties: "arm,pl310-cache" "arm,l220-cache" "arm,l210-cache"+ "marvell,aurora-cache-no-outer": Marvell Controller designed to be+ compatible with the ARM one, with system cache mode (meaning+ maintenance operations on L1 are broadcasted to the L2 and L2+ performs the same operation).+ "marvell,aurora-cache-with-outer": Marvell Controller designed to+ be compatible with the ARM one with outer cache mode. - cache-unified : Specifies the cache is a unified cache. - cache-level : Should be set to 2 for a level 2 cache. - reg : Physical base address and size of cache controller's memory mapped
@@ -29,6 +35,9 @@ Optional properties: filter. Addresses in the filter window are directed to the M1 port. Other addresses will go to the M0 port. - interrupts : 1 combined interrupt.+- cache-id-part: cache id part number to be used if it is not present+ on hardware+- wt-override: If present then L2 is forced to Write through mode Example:
Aurora Cache Controller was designed to be compatible with the ARM L2
Cache Controller. It comes with some difference or improvement such
as:
- no cache id part number available through hardware (need to get it
by the DT).
- always write through mode available.
- two flavors of the controller outer cache and system cache (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
- in outer cache mode, the cache maintenance operations are improved and
can be done on a range inside a page and are not limited to a cache
line.
Signed-off-by: Gregory CLEMENT <redacted>
Cc: Barry Song <redacted>
Cc: Will Deacon <redacted>
Cc: Santosh Shilimkar <redacted>
Cc: Rob Herring <redacted>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <redacted>
---
arch/arm/include/asm/hardware/cache-aurora-l2.h | 51 +++++
arch/arm/mm/cache-l2x0.c | 259 ++++++++++++++++++++++-
2 files changed, 304 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -33,6 +34,11 @@ static DEFINE_RAW_SPINLOCK(l2x0_lock);staticu32l2x0_way_mask;/* Bitmask of active ways */staticu32l2x0_size;staticunsignedlongsync_reg_offset=L2X0_CACHE_SYNC;+staticintl2_wt_override;++/* Aurora don't have the cache ID register available, so we have to+*passitthoughthedevicetree*/+staticu32cache_id_part_number_from_dt;structl2x0_regsl2x0_saved_regs;
@@ -275,6 +281,130 @@ static void l2x0_flush_range(unsigned long start, unsigned long end)cache_sync();raw_spin_unlock_irqrestore(&l2x0_lock,flags);}+/*+*NotethattheendaddressespassedtoLinuxprimitivesare+*noninclusive,whilethehardwarecacherangeoperationsuse+*inclusivestartandendaddresses.+*/+staticunsignedlongcalc_range_end(unsignedlongstart,unsignedlongend)+{+unsignedlongrange_end;++BUG_ON(start&(CACHE_LINE_SIZE-1));+BUG_ON(end&(CACHE_LINE_SIZE-1));++/*+*Trytoprocessallcachelinesbetween'start'and'end'.+*/+range_end=end;++/*+*Limitthenumberofcachelinesprocessedatonce,+*sincecacherangeoperationsstalltheCPUpipeline+*untilcompletion.+*/+if(range_end>start+MAX_RANGE_SIZE)+range_end=start+MAX_RANGE_SIZE;++/*+*Cacherangeoperationscan'tstraddleapageboundary.+*/+if(range_end>(start|(PAGE_SIZE-1))+1)+range_end=(start|(PAGE_SIZE-1))+1;++returnrange_end;+}++staticvoidaurora_pa_range(unsignedlongstart,unsignedlongend,+unsignedlongoffset)+{+unsignedlongflags;++/*+*Makesure'start'and'end'referencethesamepage,as+*L2isPIPTandrangeoperationsonlydoaTLBlookupon+*thestartaddress.+*/+BUG_ON((start^end)&~(PAGE_SIZE-1));+raw_spin_lock_irqsave(&l2x0_lock,flags);+writel(start,l2x0_base+AURORA_RANGE_BASE_ADDR_REG);+writel(end,l2x0_base+offset);+raw_spin_unlock_irqrestore(&l2x0_lock,flags);++cache_sync();+}++staticvoidaurora_inv_range(unsignedlongstart,unsignedlongend)+{+/*+*Cleanandinvalidatepartialfirstcacheline.+*/+if(start&(CACHE_LINE_SIZE-1)){+writel((start&~(CACHE_LINE_SIZE-1))&~0x1f,+l2x0_base+AURORA_FLUSH_PHY_ADDR_REG);+cache_sync();+start=(start|(CACHE_LINE_SIZE-1))+1;+}++/*+*Cleanandinvalidatepartiallastcacheline.+*/+if(start<end&&end&(CACHE_LINE_SIZE-1)){+writel((end&~(CACHE_LINE_SIZE-1))&~0x1f,+l2x0_base+AURORA_FLUSH_PHY_ADDR_REG);+cache_sync();+end&=~(CACHE_LINE_SIZE-1);+}++/*+*Invalidateallfullcachelinesbetween'start'and'end'.+*/+while(start<end){+unsignedlongrange_end=calc_range_end(start,end);+aurora_pa_range(start,range_end-CACHE_LINE_SIZE,+AURORA_INVAL_RANGE_REG);+start=range_end;+}++dsb();+}++staticvoidaurora_clean_range(unsignedlongstart,unsignedlongend)+{+/*+*IfL2isforcedtoWT,theL2willalwaysbecleanandwe+*don'tneedtodoanythinghere.+*/+if(!l2_wt_override){+start&=~(CACHE_LINE_SIZE-1);+end=(end+CACHE_LINE_SIZE-1)&~(CACHE_LINE_SIZE-1);+while(start!=end){+unsignedlongrange_end=calc_range_end(start,end);+aurora_pa_range(start,range_end-CACHE_LINE_SIZE,+AURORA_CLEAN_RANGE_REG);+start=range_end;+}+}++dsb();+}++staticvoidaurora_flush_range(unsignedlongstart,unsignedlongend)+{+if(!l2_wt_override){+start&=~(CACHE_LINE_SIZE-1);+end=(end+CACHE_LINE_SIZE-1)&~(CACHE_LINE_SIZE-1);+while(start!=end){+unsignedlongrange_end=calc_range_end(start,end);+aurora_pa_range(start,range_end-CACHE_LINE_SIZE,+AURORA_FLUSH_RANGE_REG);+start=range_end;+}+}+dsb();+}++staticvoidl2x0_disable(void){
@@ -534,6 +706,48 @@ static void pl310_resume(void)l2x0_resume();}+staticvoidaurora_resume(void)+{+u32u;++u=readl(l2x0_base+L2X0_CTRL);+if(!(u&1)){+writel(l2x0_saved_regs.aux_ctrl,l2x0_base+L2X0_AUX_CTRL);+writel(l2x0_saved_regs.ctrl,l2x0_base+L2X0_CTRL);+}+}++staticvoid__initaurora_broadcast_l2_commands()+{+__u32u;+/* Enable Broadcasting of cache commands to L2*/+__asm____volatile__("mrc p15, 1, %0, c15, c2, 0":"=r"(u));+u|=0x100;/* Set the FW bit */+__asm____volatile__("mcr p15, 1, %0, c15, c2, 0\n"::"r"(u));+}++staticvoid__initaurora_of_setup(conststructdevice_node*np,+u32*aux_val,u32*aux_mask)+{+u32val=AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU;+u32mask=AURORA_ACR_REPLACEMENT_MASK;++of_property_read_u32(np,"cache-id-part",+&cache_id_part_number_from_dt);++/* Determine and save the write policy */+l2_wt_override=of_property_read_bool(np,"wt-override");++if(l2_wt_override){+val|=AURORA_ACR_FORCE_WRITE_THRO_POLICY;+mask|=AURORA_ACR_FORCE_WRITE_POLICY_MASK;+}++*aux_val&=~mask;+*aux_val|=val;+*aux_mask&=~mask;+}+staticconststructl2x0_of_datapl310_data={.setup=pl310_of_setup,.save=pl310_save,
@@ -597,6 +838,12 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)if(!(readl_relaxed(l2x0_base+L2X0_CTRL)&1)){if(data->setup)data->setup(np,&aux_val,&aux_mask);+++/* For aurora cache in no outer mode select the+*correctmodeusingthecoprocessor*/+if(data==&aurora_no_outer_data)+aurora_broadcast_l2_commands();}if(data->save)
On 8 August 2012 16:05, Gregory CLEMENT
[off-list ref] wrote:
- two flavors of the controller 'outer cache' and 'system cache' (the
last one meaning maintenance operations on L1 are broadcasted to the
L2 and L2 performs the same operation).
BTW, is the DSB also transparently handled by the L2 in 'system cache' mode?
--
Catalin
From: Will Deacon <hidden> Date: 2012-08-08 15:19:47
On Wed, Aug 08, 2012 at 04:05:03PM +0100, Gregory CLEMENT wrote:
+static void aurora_pa_range(unsigned long start, unsigned long end,
+ unsigned long offset)
+{
This controller is used by Armada XP right? I think that SoC supports LPAE,
so please tell me that the above is a mistake and the controller can support
physical addresses > 32 bits!
If so, you'll need to hack the cache-l2x0 driver to use phys_addr_t types
instead of unsigned longs.
Will
Hello,
The purpose of this patch set is to add support for Aurora L2 Cache
I am surprised because all the patches are awaiting for moderator approval
with the reason "Message has a suspicious header".
As I used the same "git send-email" command as for my previous
submissions I am puzzled.
I hope to receive an explanation soon to be able to fix it.
Now waiting for the arrivals of the patches, the commits are still
available on branch aurora-L2-cache-ctrl located at
https://github.com/MISL-EBU-System-SW/mainline-public.git
regards,
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Wed, Aug 08, 2012 at 04:05:03PM +0100, Gregory CLEMENT wrote:
quoted
+static void aurora_pa_range(unsigned long start, unsigned long end,
+ unsigned long offset)
+{
This controller is used by Armada XP right? I think that SoC supports LPAE,
so please tell me that the above is a mistake and the controller can support
physical addresses > 32 bits!
Yes indeed this SoC support LPAE.
If so, you'll need to hack the cache-l2x0 driver to use phys_addr_t types
instead of unsigned longs.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Wed, Aug 08, 2012 at 04:05:03PM +0100, Gregory CLEMENT wrote:
quoted
+static void aurora_pa_range(unsigned long start, unsigned long end,
+ unsigned long offset)
+{
This controller is used by Armada XP right? I think that SoC supports LPAE,
so please tell me that the above is a mistake and the controller can support
physical addresses > 32 bits!
Yes indeed this SoC support LPAE.
Well Armada XP supports LPAE but don't use any outer cache functions, he works
with the Aurora cache controller on 'system cache'.
Armada 370 uses this outer cache functions but doesn't support LPAE.
But it seem possible to use the Aurora controller as an 'outer cache' on an
Armada XP. In this case we need to handle this case, even if I am not sure when
someone wanted to select this use case.
quoted
If so, you'll need to hack the cache-l2x0 driver to use phys_addr_t types
instead of unsigned longs.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Hi Will,
You will find an updated version of this patch with LPAE support. I've
tested with and without LPAE selected.
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".
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.
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.
Regards,
Gregory
Aurora Cache Controller was designed to be compatible with the ARM L2
Cache Controller. It comes with some difference or improvement such
as:
- no cache id part number available through hardware (need to get it
by the DT).
- always write through mode available.
- two flavors of the controller outer cache and system cache (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
- in outer cache mode, the cache maintenance operations are improved and
can be done on a range inside a page and are not limited to a cache
line.
Signed-off-by: Gregory CLEMENT <redacted>
Cc: Barry Song <redacted>
Cc: Will Deacon <redacted>
Cc: Santosh Shilimkar <redacted>
Cc: Rob Herring <redacted>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <redacted>
---
arch/arm/include/asm/hardware/cache-aurora-l2.h | 51 +++++
arch/arm/mm/cache-l2x0.c | 274 ++++++++++++++++++++++-
2 files changed, 319 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -25,14 +25,33 @@#include<asm/cacheflush.h>#include<asm/hardware/cache-l2x0.h>+#include<asm/hardware/cache-aurora-l2.h>#define CACHE_LINE_SIZE 32+#ifdef CONFIG_ARM_LPAE+/*+*OnAuroraifLPAEisactivatedthenwhenwrittingina32bits+*adressinregsiteractualphysicaladdressis+*{bits[3:0],bits[31:5],00000}.Andifnotbits[4:0]mustbesetto+*0x0.+*/++#define AURORA_LPAE(addr) ((((addr)>>32)&0xf)|((addr)&~0xf))+#else+#define AURORA_LPAE(addr) (addr)+#endif+staticvoid__iomem*l2x0_base;staticDEFINE_RAW_SPINLOCK(l2x0_lock);staticu32l2x0_way_mask;/* Bitmask of active ways */staticu32l2x0_size;staticunsignedlongsync_reg_offset=L2X0_CACHE_SYNC;+staticintl2_wt_override;++/* Aurora don't have the cache ID register available, so we have to+*passitthoughthedevicetree*/+staticu32cache_id_part_number_from_dt;structl2x0_regsl2x0_saved_regs;
@@ -275,6 +294,132 @@ static void l2x0_flush_range(unsigned long start, unsigned long end)cache_sync();raw_spin_unlock_irqrestore(&l2x0_lock,flags);}+/*+*NotethattheendaddressespassedtoLinuxprimitivesare+*noninclusive,whilethehardwarecacherangeoperationsuse+*inclusivestartandendaddresses.+*/+staticphys_addr_tcalc_range_end(phys_addr_tstart,phys_addr_tend)+{+phys_addr_trange_end;++BUG_ON(start&(CACHE_LINE_SIZE-1));+BUG_ON(end&(CACHE_LINE_SIZE-1));++/*+*Trytoprocessallcachelinesbetween'start'and'end'.+*/+range_end=end;++/*+*Limitthenumberofcachelinesprocessedatonce,+*sincecacherangeoperationsstalltheCPUpipeline+*untilcompletion.+*/+if(range_end>start+MAX_RANGE_SIZE)+range_end=start+MAX_RANGE_SIZE;++/*+*Cacherangeoperationscan'tstraddleapageboundary.+*/+if(range_end>(start|(PAGE_SIZE-1))+1)+range_end=(start|(PAGE_SIZE-1))+1;++returnrange_end;+}++staticvoidaurora_pa_range(phys_addr_tstart,phys_addr_tend,+unsignedlongoffset)+{+unsignedlongflags;++/*+*Makesure'start'and'end'referencethesamepage,as+*L2isPIPTandrangeoperationsonlydoaTLBlookupon+*thestartaddress.+*/+BUG_ON((start^end)&~(PAGE_SIZE-1));+raw_spin_lock_irqsave(&l2x0_lock,flags);+++writel_relaxed(AURORA_LPAE(start),l2x0_base+AURORA_RANGE_BASE_ADDR_REG);+writel_relaxed(AURORA_LPAE(end),l2x0_base+offset);+raw_spin_unlock_irqrestore(&l2x0_lock,flags);++cache_sync();+}++staticvoidaurora_inv_range(phys_addr_tstart,phys_addr_tend)+{+/*+*Cleanandinvalidatepartialfirstcacheline.+*/+if(start&(CACHE_LINE_SIZE-1)){+writel_relaxed(AURORA_LPAE((start&~(CACHE_LINE_SIZE-1))&~0x1f),+l2x0_base+AURORA_FLUSH_PHY_ADDR_REG);+cache_sync();+start=(start|(CACHE_LINE_SIZE-1))+1;+}++/*+*Cleanandinvalidatepartiallastcacheline.+*/+if(start<end&&end&(CACHE_LINE_SIZE-1)){+writel_relaxed(AURORA_LPAE((end&~(CACHE_LINE_SIZE-1))&~0x1f),+l2x0_base+AURORA_FLUSH_PHY_ADDR_REG);+cache_sync();+end&=~(CACHE_LINE_SIZE-1);+}++/*+*Invalidateallfullcachelinesbetween'start'and'end'.+*/+while(start<end){+phys_addr_trange_end=calc_range_end(start,end);+aurora_pa_range(start,range_end-CACHE_LINE_SIZE,+AURORA_INVAL_RANGE_REG);+start=range_end;+}++dsb();+}++staticvoidaurora_clean_range(phys_addr_tstart,phys_addr_tend)+{+/*+*IfL2isforcedtoWT,theL2willalwaysbecleanandwe+*don'tneedtodoanythinghere.+*/+if(!l2_wt_override){+start&=~(CACHE_LINE_SIZE-1);+end=(end+CACHE_LINE_SIZE-1)&~(CACHE_LINE_SIZE-1);+while(start!=end){+phys_addr_trange_end=calc_range_end(start,end);+aurora_pa_range(start,range_end-CACHE_LINE_SIZE,+AURORA_CLEAN_RANGE_REG);+start=range_end;+}+}++dsb();+}++staticvoidaurora_flush_range(phys_addr_tstart,phys_addr_tend)+{+if(!l2_wt_override){+start&=~(CACHE_LINE_SIZE-1);+end=(end+CACHE_LINE_SIZE-1)&~(CACHE_LINE_SIZE-1);+while(start!=end){+phys_addr_trange_end=calc_range_end(start,end);+aurora_pa_range(start,range_end-CACHE_LINE_SIZE,+AURORA_FLUSH_RANGE_REG);+start=range_end;+}+}+dsb();+}++staticvoidl2x0_disable(void){
@@ -534,6 +721,48 @@ static void pl310_resume(void)l2x0_resume();}+staticvoidaurora_resume(void)+{+u32u;++u=readl(l2x0_base+L2X0_CTRL);+if(!(u&1)){+writel(l2x0_saved_regs.aux_ctrl,l2x0_base+L2X0_AUX_CTRL);+writel(l2x0_saved_regs.ctrl,l2x0_base+L2X0_CTRL);+}+}++staticvoid__initaurora_broadcast_l2_commands(void)+{+__u32u;+/* Enable Broadcasting of cache commands to L2*/+__asm____volatile__("mrc p15, 1, %0, c15, c2, 0":"=r"(u));+u|=0x100;/* Set the FW bit */+__asm____volatile__("mcr p15, 1, %0, c15, c2, 0\n"::"r"(u));+}++staticvoid__initaurora_of_setup(conststructdevice_node*np,+u32*aux_val,u32*aux_mask)+{+u32val=AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU;+u32mask=AURORA_ACR_REPLACEMENT_MASK;++of_property_read_u32(np,"cache-id-part",+&cache_id_part_number_from_dt);++/* Determine and save the write policy */+l2_wt_override=of_property_read_bool(np,"wt-override");++if(l2_wt_override){+val|=AURORA_ACR_FORCE_WRITE_THRO_POLICY;+mask|=AURORA_ACR_FORCE_WRITE_POLICY_MASK;+}++*aux_val&=~mask;+*aux_val|=val;+*aux_mask&=~mask;+}+staticconststructl2x0_of_datapl310_data={.setup=pl310_of_setup,.save=pl310_save,
@@ -597,6 +853,12 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)if(!(readl_relaxed(l2x0_base+L2X0_CTRL)&1)){if(data->setup)data->setup(np,&aux_val,&aux_mask);+++/* For aurora cache in no outer mode select the+*correctmodeusingthecoprocessor*/+if(data==&aurora_no_outer_data)+aurora_broadcast_l2_commands();}if(data->save)
From: Will Deacon <hidden> Date: 2012-08-10 14:47:30
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
From: Will Deacon <hidden> Date: 2012-08-10 14:49:22
On Wed, Aug 08, 2012 at 05:52:20PM +0100, Gregory CLEMENT wrote:
On 08/08/2012 06:30 PM, Gregory CLEMENT wrote:
quoted
Yes indeed this SoC support LPAE.
Well Armada XP supports LPAE but don't use any outer cache functions, he works
with the Aurora cache controller on 'system cache'.
Armada 370 uses this outer cache functions but doesn't support LPAE.
Can the Armada 370 be configured to use the co-processor interface to the
L2, or does only the Armada XP support that feature? What happens if you
build a single zImage supporting both of the SoCs?
Will
On Thu, Aug 09, 2012 at 05:48:44PM +0100, Gregory CLEMENT wrote:
quoted
Hi Will,
Hi Gregory,
quoted
You will find an updated version of this patch with LPAE support. I've
tested with and without LPAE selected.
Just a rectification, in fact I managed to build in both case, and to run
only without LPAE support. I didn't have the support for LPAE yet. I was
surprised that it worked out of the box, but in fact I tested the wrong
kernel! I realized this this morning.
Thanks for the patches.
quoted
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 :)
quoted
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?
yes it is!
quoted
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Wed, Aug 08, 2012 at 05:52:20PM +0100, Gregory CLEMENT wrote:
quoted
On 08/08/2012 06:30 PM, Gregory CLEMENT wrote:
quoted
Yes indeed this SoC support LPAE.
Well Armada XP supports LPAE but don't use any outer cache functions, he works
with the Aurora cache controller on 'system cache'.
Armada 370 uses this outer cache functions but doesn't support LPAE.
Can the Armada 370 be configured to use the co-processor interface to the
L2, or does only the Armada XP support that feature? What happens if you
build a single zImage supporting both of the SoCs?
About L2 cache we already use the same kernel on Armada 370 and Armada XP
and the differences are in the device tree.
Now if I understood correctly what the LPAE involved, I guess we can't have
a kernel with LAPE running on Armada 370.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
From: Will Deacon <hidden> Date: 2012-08-10 15:20:36
On Fri, Aug 10, 2012 at 04:13:41PM +0100, Gregory CLEMENT wrote:
On 08/10/2012 04:49 PM, Will Deacon wrote:
quoted
Can the Armada 370 be configured to use the co-processor interface to the
L2, or does only the Armada XP support that feature? What happens if you
build a single zImage supporting both of the SoCs?
About L2 cache we already use the same kernel on Armada 370 and Armada XP
and the differences are in the device tree.
Right, but I wonder whether you can end up using both the outer_cache
functions *and* the co-processor interface on the Armada XP by accident.
Ideally, we'd just use the co-processor interface on all platforms and
ignore the memory-mapped one. Is that possible on the 370?
Now if I understood correctly what the LPAE involved, I guess we can't have
a kernel with LAPE running on Armada 370.
Indeed, but you could still run with 2-level page tables on both SoCs (with
less memory on the XP).
Will
On Fri, Aug 10, 2012 at 04:13:41PM +0100, Gregory CLEMENT wrote:
quoted
On 08/10/2012 04:49 PM, Will Deacon wrote:
quoted
Can the Armada 370 be configured to use the co-processor interface to the
L2, or does only the Armada XP support that feature? What happens if you
build a single zImage supporting both of the SoCs?
About L2 cache we already use the same kernel on Armada 370 and Armada XP
and the differences are in the device tree.
Right, but I wonder whether you can end up using both the outer_cache
functions *and* the co-processor interface on the Armada XP by accident.
Well from what I know it should be possible to have both in the same time.
However we implement the support in a way that you won't have both in the
same time: if we use the "system cache" mode then we don't use any outer_cache
functions.
Ideally, we'd just use the co-processor interface on all platforms and
ignore the memory-mapped one. Is that possible on the 370?
The 370 can't use the "system cache" mode (ie the co-processor).
__________________________________________
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
From: Will Deacon <hidden> Date: 2012-08-13 10:44:23
On Fri, Aug 10, 2012 at 04:02:50PM +0100, Gregory CLEMENT wrote:
On 08/10/2012 04:47 PM, Will Deacon wrote:
quoted
On Thu, Aug 09, 2012 at 05:48:44PM +0100, Gregory CLEMENT wrote:
quoted
You will find an updated version of this patch with LPAE support. I've
tested with and without LPAE selected.
Just a rectification, in fact I managed to build in both case, and to run
only without LPAE support. I didn't have the support for LPAE yet. I was
surprised that it worked out of the box, but in fact I tested the wrong
kernel! I realized this this morning.
Ok, please keep me updated with how you get on. I can't shake this nagging
feeling that the memory-mapped interface is restricted to 32-bit addresses,
which is why the XP has the option to treat the L2 as an inner-cache...
</speculation>
Will
On 08/08/2012 05:16 PM, Catalin Marinas wrote:> On 8 August 2012 16:05, Gregory CLEMENT
[off-list ref] wrote:
quoted
- two flavors of the controller 'outer cache' and 'system cache' (the
last one meaning maintenance operations on L1 are broadcasted to the
L2 and L2 performs the same operation).
BTW, is the DSB also transparently handled by the L2 in 'system cache' mode?
The information I have is that from the point view of the software
there is no need to take any extra actions when using this kind of
command, everything is handle by the hardware. So I guess that the
answer to your question should be yes.
---
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com