Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756790Ab3FSNt6 (ORCPT ); Wed, 19 Jun 2013 09:49:58 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:27694 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756639Ab3FSNty (ORCPT ); Wed, 19 Jun 2013 09:49:54 -0400 X-AuditID: cbfec7f5-b7f376d000001ec6-f9-51c1b6ff14db From: Tomasz Figa To: Lorenzo Pieralisi Cc: Chander Kashyap , Kukjin Kim , Tomasz Figa , "linux-samsung-soc@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Russell King - ARM Linux , Jingoo Han , Jonghwan Choi , Abhilash Kesavan , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Kyungmin Park , Arnd Bergmann , Olof Johansson , Nicolas Pitre , Will Deacon , Stephen Boyd Subject: Re: [PATCH] ARM: EXYNOS: Fix incorrect usage of S5P_ARM_CORE1_* registers Date: Wed, 19 Jun 2013 15:49:43 +0200 Message-id: <2791500.rs0iL4EgjJ@amdc1227> Organization: Samsung Poland R&D Center User-Agent: KMail/4.10.3 (Linux/3.8.8-gentoo; KDE/4.10.3; x86_64; ; ) In-reply-to: <20130619132417.GB5276@e102568-lin.cambridge.arm.com> References: <1371569191-2364-1-git-send-email-t.figa@samsung.com> <8974257.1Thh8U4Een@amdc1227> <20130619132417.GB5276@e102568-lin.cambridge.arm.com> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsVy+t/xy7r/tx0MNPj9Tcri8ZrFTBZ/Jx1j t3i4/iaLxeWFl1gtljRzW/QuuMpmcbbpDbvFpsfXWC0u75rDZjHj/D4mi9uXeS3e/H7BbjH9 2F82i1PXP7NZ/DjTzWKxYOMjRotVu/4wWrz8eILFQchjzbw1jB4tzT1sHr9/TWL0uNzXy+Sx c9Zddo871/aweWxeUu9x5UQTq0ffllWMHp83yQVwRXHZpKTmZJalFunbJXBlzD51l61ggXrF /Ik7mRoY38l2MXJySAiYSDy/eoUNwhaTuHBvPZDNxSEksJRRYv/Sc4wQTheTxMlPC8Gq2ATU JD43PAKzRQQMJXpOrWYCsZkFprJJXN0i18XIwSEsECLR0WsOEmYRUJU4crKZBcTmFdCU6Nhx HKyVX0Bd4t22p2CtogKuEu9XHwar4RRwkmjbvpcFYu9MRom1z3eyQjQLSvyYfI8FYpe8xL79 U1khbC2J9TuPM01gFJyFpGwWkrJZSMoWMDKvYhRNLU0uKE5KzzXSK07MLS7NS9dLzs/dxAiJ zK87GJceszrEKMDBqMTDO5PzYKAQa2JZcWXuIUYJDmYlEd6KmUAh3pTEyqrUovz4otKc1OJD jEwcnFINjCsWtbk//T1p6u0pF1XyLfZNqtj9+jzf+yLVwFAHt3sMl4qbbp/5t2Eq0/udHM7u 0l0bnObkboif4yLssG7jNqnweVVaHl/eMlsv4v+yzW/jv91X9NX0X5cc4VGcuCKdNX97Z9fx 74GGWdO0rHdwpzS2zSyyvH7+4Tzp6z2rLrt2rdpmw1vffFyJpTgj0VCLuag4EQB0flm5qgIA AA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5134 Lines: 140 On Wednesday 19 of June 2013 14:24:17 Lorenzo Pieralisi wrote: > On Wed, Jun 19, 2013 at 01:50:57PM +0100, Tomasz Figa wrote: > > On Wednesday 19 of June 2013 17:39:21 Chander Kashyap wrote: > > > On 18 June 2013 23:29, Kukjin Kim wrote: > > > > On 06/19/13 02:45, Tomasz Figa wrote: > > > >> Ccing Arnd and Olof, because I forgot to add them to git > > > >> send-email... > > > >> > > > >> Sorry for the noise. > > > >> > > > >> On Tuesday 18 of June 2013 17:26:31 Tomasz Figa wrote: > > > >>> S5P_ARM_CORE1_* registers affect only core 1. To control further > > > >>> cores > > > >>> properly another registers must be used. > > > >>> > > > >>> This patch replaces S5P_ARM_CORE1_* register definitions with > > > >>> S5P_ARM_CORE_*(x) macro which return addresses of registers for > > > >>> specified core. > > > >>> > > > >>> This fixes CPU hotplug on quad core Exynos SoCs on which > > > >>> currently > > > >>> offlining CPUs 2 or 3 caused CPU 1 to be turned off. > > > >> > > > >> Obviously this doesn't happen currently because of the if (cpu == > > > >> 1), > > > >> but> > > > > > > > > Yes, not happened...and just note exynos5440 doesn't support > > > > hotplug :) > > > > so this is available on exynos4412 and added 5420. > > > > > > > >> if logical cpu1 turned out not to be physical cpu1, then it would > > > >> crash. > > > >> > > > >> Best regards, > > > >> Tomasz > > > >> > > > >>> In addition, > > > >>> bring-up of CPU 2 and 3 is fixed on boards where bootloader > > > >>> powers > > > >>> off > > > >>> secondary cores by default. > > > > > > > > I need to test on board about above... > > > > > > > >>> Cc: stable@vger.kernel.org > > > >>> Signed-off-by: Tomasz Figa > > > >>> Signed-off-by: Kyungmin Park > > > >>> --- > > > >>> > > > >>> arch/arm/mach-exynos/hotplug.c | 9 +++++---- > > > >>> arch/arm/mach-exynos/include/mach/regs-pmu.h | 10 +++++++--- > > > >>> arch/arm/mach-exynos/platsmp.c | 9 +++++---- > > > >>> 3 files changed, 17 insertions(+), 11 deletions(-) > > > >>> > > > >>> diff --git a/arch/arm/mach-exynos/hotplug.c > > > >>> b/arch/arm/mach-exynos/hotplug.c index af90cfa..c089943 100644 > > > >>> --- a/arch/arm/mach-exynos/hotplug.c > > > >>> +++ b/arch/arm/mach-exynos/hotplug.c > > > >>> @@ -93,10 +93,11 @@ static inline void cpu_leave_lowpower(void) > > > >>> > > > >>> static inline void platform_do_lowpower(unsigned int cpu, int > > > >>> > > > >>> *spurious) { > > > >>> > > > >>> for (;;) { > > > >>> > > > >>> + void __iomem *reg_base; > > > >>> + unsigned int phys_cpu = cpu_logical_map(cpu); > > > >>> > > > >>> - /* make cpu1 to be turned off at next WFI command > > > >>> */ > > > >>> - if (cpu == 1) > > > >>> - __raw_writel(0, > > > >>> S5P_ARM_CORE1_CONFIGURATION); > > > >>> + reg_base = S5P_ARM_CORE_CONFIGURATION(phys_cpu); > > > > > > Tomasz, > > > This will break for non-zero, MPIDR value. Say if MPIDR is 1 then > > > for > > > cpu0 phys_cpu value will be 0x100, > > > and address calculation will be (S5P_ARM_CORE0_CONFIGURATION + > > > ((0x101) * 0x80)), which is wrong. > > Honestly, I did not understand the reasoning above, please clarify. > > > Hmm, according to the code initializing __cpu_logical_map[] array this > > is not true. > > > > Here's the code: > > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/a > > rch/arm/kernel/setup.c?id=refs/tags/next-20130619#n468 > > > > and for used macros and bitmasks: > > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/a > > rch/arm/include/asm/cputype.h?id=refs/tags/next-20130619#n45 > > > > Now the structure of the MPIDR register: > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/CI > > HEBGFG.html > > > > As you can see, the value read from the register in > > smp_setup_processor_id() is only the physical CPU ID, so I don't see > > any > > problem here. > > Define "physical CPU ID" :-) > > There is a problem here: the MPIDR is not an index, and the > cpu_logical_map is populated in arm_dt_init_cpu_maps in: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch > /arm/kernel/devtree.c?id=refs/tags/v3.10-rc6 > > with all affinity levels. OK. This is what I was missing. Thanks. > > You need to perform a mapping between logical cpus and registers offset, > you can't use the cpu_logical_map directly for that. Hmm, can't I just extract cluster ID and CPU ID from the MPIDR value and use them appropriately to calculate register offsets? Best regards, Tomasz > Next accident waiting to happen is GIC code (CONFIG_GIC_NON_BANKED), > where cpu_logical_map is used erroneously as an index. > > Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/