mach-ux500: unlock I&D l2x0 caches before init
Subsystems (3)
PATCH 1/1 mach-ux500: unlock I&D l2x0 caches before init
From: Linus Walleij <[email protected]>
Apparently U8500 U-Boot versions may leave the l2x0 locked down before executing the kernel. Make sure we unlock it before we initialize the l2x0. This fixes a performance problem reported by Jan Rinze.
--- arch/arm/mach-ux500/cache-l2x0.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
arch/arm/mach-ux500/cache-l2x0.c +15 -0
@@ -70,3 +70,18 @@ static int ux500_l2x0_init(void) }early_initcall (ux500_l2x0_init); + +static int ux500_l2x0_unlock (void ) +{ +/* +* Unlock Data and Instruction Lock if locked. Ux500 U-Boot versions +* apparently locks both caches before jumping to the kernel. +*/ +if (readl_relaxed (l2x0_base +L2X0_LOCKDOWN_WAY_D ) &0xFF ) +writel_relaxed (0x0 , l2x0_base +L2X0_LOCKDOWN_WAY_D ); + +if (readl_relaxed (l2x0_base +L2X0_LOCKDOWN_WAY_I ) &0xFF ) +writel_relaxed (0x0 , l2x0_base +L2X0_LOCKDOWN_WAY_I ); +} + +arch_initcall (ux500_l2x0_unlock);
Signature · 1 line
1.7.3.2
PATCH 1/1 mach-ux500: unlock I&D l2x0 caches before init
Linus,
Quoted 7 lines · Linus Walleij
From: Linus Walleij <[email protected]>
Apparently U8500 U-Boot versions may leave the l2x0 locked down before executing the kernel. Make sure we unlock it before we initialize the l2x0. This fixes a performance problem reported by Jan Rinze.
Just when you think a bootloader wouldn't muck with something like this...
I'll ask the obvious question: As this is u-boot, can't this be fixed in u-boot?
Quoted 20 lines
Cc Srinidhi Kasagar <[email protected]>Cc Rabin Vincent <[email protected]>Cc Adrian Bunk <[email protected]>Reported-by Jan Rinze <[email protected]>Tested-by Robert Marklund <[email protected]>Signed-off-by Linus Walleij <[email protected]>--- arch/arm/mach-ux500/cache-l2x0.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)arch/arm/mach-ux500/cache-l2x0.c +2
-0@@ -70,3 +70,18 @@ static int ux500_l2x0_init(void) }early_initcall (ux500_l2x0_init); + +static int ux500_l2x0_unlock (void )
arch/arm/mach-ux500/cache-l2x0.c static int ux500_l2x0_init(void) · line 84
Quoted 10 lines
arch/arm/mach-ux500/cache-l2x0.c +10
-0+{ +/* +* Unlock Data and Instruction Lock if locked. Ux500 U-Boot versions +* apparently locks both caches before jumping to the kernel. +*/ +if (readl_relaxed (l2x0_base +L2X0_LOCKDOWN_WAY_D ) &0xFF ) +writel_relaxed (0x0 , l2x0_base +L2X0_LOCKDOWN_WAY_D ); + +if (readl_relaxed (l2x0_base +L2X0_LOCKDOWN_WAY_I ) &0xFF ) +writel_relaxed (0x0 , l2x0_base +L2X0_LOCKDOWN_WAY_I );
Do you really need to read the register first?
Can't this just be done unconditionally in l2x0_init for everyone. I doubt anyone wants to lock down ways. You would need to adjust for 16-way support.
Rob
PATCH 1/1 mach-ux500: unlock I&D l2x0 caches before init
2011/9/1 Rob Herring <[email protected]>:
Quoted 10 lines
[Me]
Quoted 4 lines
Apparently U8500 U-Boot versions may leave the l2x0 locked down before executing the kernel. Make sure we unlock it before we initialize the l2x0. This fixes a performance problem reported by Jan Rinze.
Just when you think a bootloader wouldn't muck with something like this...
I'll ask the obvious question: As this is u-boot, can't this be fixed in u-boot?
As in so many other countless examples found on the ARM mailing list, this is sadly yet another case where there are deployed U-boot images all over the planet doing this, and people don't like to change them.
Quoted 10 lines
Quoted 9 lines
+ ? ? /*
+ ? ? ?* Unlock Data and Instruction Lock if locked. Ux500 U-Boot versions
+ ? ? ?* apparently locks both caches before jumping to the kernel.
+ ? ? ?*/
+ ? ? if (readl_relaxed(l2x0_base + L2X0_LOCKDOWN_WAY_D)&0xFF)
+ ? ? ? ? ? ?writel_relaxed(0x0, l2x0_base + L2X0_LOCKDOWN_WAY_D); +
+ ? ? if (readl_relaxed(l2x0_base + L2X0_LOCKDOWN_WAY_I)&0xFF)
+ ? ? ? ? ? ?writel_relaxed(0x0, l2x0_base + L2X0_LOCKDOWN_WAY_I);
Quoted 5 lines
Do you really need to read the register first?
Can't this just be done unconditionally in
l2x0_initfor everyone. I doubt anyone wants to lock down ways. You would need to adjust for 16-way support.
Good question.
Catalin, how do you feel about disabling D&I locks in l2x0_init()?
Yours,
Linus Walleij