On Tue, Aug 26, 2014 at 04:17:59PM +0200, Tomasz Figa wrote: > On Exynos SoCs it is necessary to resume operation of L2C early in > assembly code, because otherwise certain systems will crash. This patch > adds necessary code to non-secure resume handler. > > Signed-off-by: Tomasz Figa <t.figa@xxxxxxxxxxx> > --- > arch/arm/mach-exynos/common.h | 1 + > arch/arm/mach-exynos/firmware.c | 4 +++- > arch/arm/mach-exynos/sleep.S | 41 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 45 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h > index c218200..e88c0f9 100644 > --- a/arch/arm/mach-exynos/common.h > +++ b/arch/arm/mach-exynos/common.h > @@ -113,6 +113,7 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK) > > extern u32 cp15_save_diag; > extern u32 cp15_save_power; > +extern unsigned long l2x0_regs_phys; > > extern void __iomem *sysram_ns_base_addr; > extern void __iomem *sysram_base_addr; > diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c > index 554b350..71bcfbd 100644 > --- a/arch/arm/mach-exynos/firmware.c > +++ b/arch/arm/mach-exynos/firmware.c > @@ -102,7 +102,9 @@ static int exynos_suspend(void) > writel(EXYNOS_SLEEP_MAGIC, sysram_ns_base_addr + EXYNOS_BOOT_FLAG); > writel(virt_to_phys(exynos_cpu_resume_ns), > sysram_ns_base_addr + EXYNOS_BOOT_ADDR); > - > +#ifdef CONFIG_CACHE_L2X0 > + l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs); > +#endif NAK. Please look at how arch/arm/mm/l2c-l2x0-resume.S gets the address of this structure in assembly code. The name of this variable is crap in any case. It's not the registers, it's the saved registers. So even more reason to kill this abomination, which incidentally, I've already killed off once before in the exynos code. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |