From patchwork Tue Nov 25 06:01:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Abhilash Kesavan X-Patchwork-Id: 5372511 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 75DFA9F2F5 for ; Tue, 25 Nov 2014 06:04:00 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 570E020179 for ; Tue, 25 Nov 2014 06:03:59 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3CAB42015D for ; Tue, 25 Nov 2014 06:03:58 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Xt9C3-0005pS-C9; Tue, 25 Nov 2014 06:01:43 +0000 Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Xt9Bz-0005Xe-To for linux-arm-kernel@lists.infradead.org; Tue, 25 Nov 2014 06:01:41 +0000 Received: by mail-qc0-f178.google.com with SMTP id b13so8838775qcw.37 for ; Mon, 24 Nov 2014 22:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pPFlK1JKRwikF/FTh5HvQhayLjCCRvvKs+ik9Uh5QcE=; b=IKnsZBjeZcMKObrj1d7bsx49T9kxfjHxKnSrK1nLVSPSLFQkEeKTy0N/dv+PtmPB78 K/p2uMH4Bsr0yfZv9U8TxnQ6jRFPLVmr4PCN4DMkq0Po4/YhoXcNSf+lnexD4PAl7GYH jxCPPIW+QPCvnjAnuDDEbKDro+dNyh1HobDnrNCYzzu7nGRI2Q5vKqs9QGRooMZi5H4n UMPoGcy3zb8WfOqYeA91p7AUdGFmkguo8ZaxKGCtmAVrGM9qEtJj6zcAbfigHxkkIbtd 5RHNKQr4HUfwyxKz/o4mr92xY9F4od+lFwG30CXge55p/5sWdIzfBAwV9nA1rvQqUXjV gv9g== MIME-Version: 1.0 X-Received: by 10.140.23.35 with SMTP id 32mr9536257qgo.73.1416895278279; Mon, 24 Nov 2014 22:01:18 -0800 (PST) Received: by 10.229.214.67 with HTTP; Mon, 24 Nov 2014 22:01:18 -0800 (PST) In-Reply-To: References: <1414796382-5447-1-git-send-email-khilman@kernel.org> <000e01cffb39$5ef0a2d0$1cd1e870$@kernel.org> <7hegtaq26c.fsf@deeprootsystems.com> <044101d00852$3f421420$bdc63c60$@kernel.org> Date: Tue, 25 Nov 2014 11:31:18 +0530 Message-ID: Subject: Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable From: Abhilash Kesavan To: Kevin Hilman X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141124_220140_119831_6E1ADBF3 X-CRM114-Status: GOOD ( 33.33 ) X-Spam-Score: -0.8 (/) Cc: Krzysztof Kozlowski , "linux-samsung-soc@vger.kernel.org" , Bartlomiej Zolnierkiewicz , Doug Anderson , Sachin Kamat , Kukjin Kim , "linux-arm-kernel@lists.infradead.org" , Olof Johansson , Kukjin Kim , Javier Martinez Canillas , "linaro-kernel@lists.linaro.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello Kevin, On Tue, Nov 25, 2014 at 8:50 AM, Kevin Hilman wrote: > On Mon, Nov 24, 2014 at 5:50 PM, Kukjin Kim wrote: >> Olof Johansson wrote: >>> >>> On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson wrote: >>> > On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman wrote: >>> >> On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson wrote: >>> >>> On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman wrote: >>> >>>> Kukjin, >>> >>>> >>> >>>> On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman wrote: >>> >>>>> Kukjin Kim writes: >>> >>>>> >>> >>>>>> Kevin Hilman wrote: >>> >>>>>>> >>> >>>>>>> From: Kevin Hilman >>> >>>>>>> >>> >>>>>>> The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts >>> >>>>>>> during boot testing, causing various userspace startup failures. >>> >>>>>>> >>> >>>>>>> Disable until it has gotten more testing. >>> >>>>>>> >>> >>>>>>> Cc: Kukjin Kim , >>> >>>>>>> Cc: Javier Martinez Canillas , >>> >>>>>>> Cc: Sachin Kamat , >>> >>>>>>> Cc: Doug Anderson , >>> >>>>>>> Cc: Bartlomiej Zolnierkiewicz , >>> >>>>>>> Cc: Krzysztof Kozlowski , >>> >>>>>>> Cc: Tushar Behera , >>> >>>>>>> Cc: stable@vger.kernel.org # v3.17+ >>> >>>>>>> Signed-off-by: Kevin Hilman >>> >>>>>>> --- >>> >>>>>>> This has been reported by a few people[1], but not investigated or fixed, so it's >>> >>>>>>> time to disable this feature until it can be fixed. >>> >>>>>>> >>> >>>>>> Hi Kevin, >>> >>>>>> >>> >>>>>> Yeah I agree with your opinion. >>> >>>>>> >>> >>>>>> But as you can see my tree, I've queued regarding mcpm patches for 3.19 will >>> >>>>>> be shown in -next in this weekend. >>> >>>>> >>> >>>>> Which of the recently queued patches are expected to address the >>> >>>>> imprecise abort issue? I'd be happy to test them out. >>> >>>> >>> >>>> Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. >>> >>>> >>> >>>> What is the status of $SUBJECT patch? >>> >>>> >>> >>>>>> Anyway let me apply this into -fixes and >>> >>>>>> then let's enable after test its functionality in -next in a couple of days. >>> >>>>> >>> >>>>> Yes, I think this needs to be applied until these aborts are understood >>> >>>>> and fixed. >>> >>>> >>> >>>> Is anyone at Samsung actually looking into these MCPM issues? >>> >>> >>> >>> Hi Kevin, >>> >>> >>> >>> What hardware are you having problems with? 5420 or 5422/5800? >>> >> >>> >> Yes. :) >>> >> >>> >> exynos5420-arndale-octa: >>> >> http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420- >>> arndale-octa.html >>> >> exynos5422-odroid-xu3: >>> >> http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422- >>> odroid-xu3.html >>> >> >>> >> My boot tests seem to pass fine because I have such a minimal >>> >> userspace, but Tyler Baker reported that with a "real" userspace, he >>> >> can't boot to a shell: >>> >> >>> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html >>> > >> Hmm...his report was in Sep...I think it should be fine with current -next? > > No, it is still broken in linux-next (as I stated above.) > > Moreover, earlier in this thread you mentioned you were merging some > MCPM patches that should address this, but did not respond when I > asked which patches you thing should address this issue > >> To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk >> which has different bootloader, I couldn't test it...I'll try to make a test >> farm like you guys... > > Do you have some colleagues with any other 542x hardware? I had > assumed that linux-next was being better tested on the publicaly > available, and widely available boards like odroid-xu3 and > Chromebook2, but I've come to realize the hard way that that is not Are you seeing this on Chromebook2 (Peach-Pi 5800) too ? > the case. You mention your board has a different bootloader. Do you > suspect there's a bootloader issue on these other platforms? If so, > could you elaborate on possible fixes? I'm more than willing to test > any proposed fixes, but I'm not familiar enough yet with these SoCs to > figure out the underlying issues alone. > > Until you have a working board farm, you could start having a closer > look at the boot logs we're already producing. Admittedly linux-next > broken in many ways besides this one for exynos currently, but it has > been having these imprecise aborts well before the other recent > issues. > > Also, It's very possible that this issue is not even MCPM related at > all, and MCPM is just uncovering a previously hidden bug. It would be > very helpful if people more familiar with this hardware and SoC would > investigate bug reports like these. The 3 boards I have access to (SMDK5420, Chromebook Peach-Pi and Chromebook Peach-Pit) work fine with MCPM enabled. I am not sure why it is failing only on the above mentioned boards as there is nothing specific to them in the MCPM back-end. I assume that when you default to platsmp (on disabling MCPM), the non-working boards boot all cores upto userspace without any issues ? Based on the timeline (problems started about 2.5 months back), there have only been a couple of changes in the 5420 MCPM back-end. Could you revert the following commits and check if things improve. 20fe6f9 ARM: EXYNOS: Support cluster power off on exynos5420/5800 fbb0499 ARM: 8083/1: exynos: activate the CCI on boot CPU/cluster using the MCPM loopback These might not revert cleanly, so instead of the above you could also comment the following 2 lines: If you still get aborts then I suspect that the problem is with the bootloader configuration but am not sure. I am OK with disabling 5420_MCPM in the default configuration in such a case. This would however mean that S2R also stops working by default on 5420. Regards, Abhilash > > Kevin > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c index dc9a764..9a07188 100644 --- a/arch/arm/mach-exynos/mcpm-exynos.c +++ b/arch/arm/mach-exynos/mcpm-exynos.c @@ -152,7 +152,7 @@ static void exynos_power_down(void) exynos_cpu_power_down(cpunr); if (exynos_cluster_unused(cluster)) { - exynos_cluster_power_down(cluster); + //exynos_cluster_power_down(cluster); last_man = true; } } else if (cpu_use_count[cpu][cluster] == 1) { @@ -356,8 +356,8 @@ static int __init exynos_mcpm_init(void) ret = mcpm_platform_register(&exynos_power_ops); if (!ret) ret = mcpm_sync_init(exynos_pm_power_up_setup); - if (!ret) - ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */ + //if (!ret) + //ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */ if (ret) { iounmap(ns_sram_base_addr); return ret;