From patchwork Wed Oct 21 10:16:19 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martinez Canillas X-Patchwork-Id: 7455951 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id C0A229F30B for ; Wed, 21 Oct 2015 10:16:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D74EC207B9 for ; Wed, 21 Oct 2015 10:16:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CCE6A208A4 for ; Wed, 21 Oct 2015 10:16:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932434AbbJUKQ3 (ORCPT ); Wed, 21 Oct 2015 06:16:29 -0400 Received: from lists.s-osg.org ([54.187.51.154]:42069 "EHLO lists.s-osg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932192AbbJUKQ0 (ORCPT ); Wed, 21 Oct 2015 06:16:26 -0400 Received: from [192.168.1.139] (211.178.21.95.dynamic.jazztel.es [95.21.178.211]) by lists.s-osg.org (Postfix) with ESMTPSA id A877A46270; Wed, 21 Oct 2015 03:16:22 -0700 (PDT) Subject: Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers To: Alim Akhtar , m.reichl@fivetechno.de, Alim Akhtar References: <1445333085-22837-1-git-send-email-alim.akhtar@samsung.com> <1606098.olLAyTIhB3@dell2.five-lan.de> <56272C1C.8040007@samsung.com> From: Javier Martinez Canillas X-Enigmail-Draft-Status: N1110 Cc: "linux-samsung-soc@vger.kernel.org" , kgene , =?UTF-8?Q?Krzysztof_Koz=c5=82owski?= , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Tobias Jakobi Message-ID: <562765F3.9010306@osg.samsung.com> Date: Wed, 21 Oct 2015 12:16:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56272C1C.8040007@samsung.com> Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, 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 Alim, On 10/21/2015 08:09 AM, Alim Akhtar wrote: [snip] >>>>> >>>>> Hi Alim, >>>>> >>>>> I have installed your patch set above with git am on top of >>>>> 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today >>>>> with make exynos_defconfig on Odroid U3. >>>>> >>>> which exynos soc Odroid U3 uses? >>>> >>> OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does >>> include exynos4.dtsi, >>> so these should have worked. >>> >>>>> "halt -p" worked (power 0.0W). >>>>> "reboot" got stuck at 0.5W. >>>>> >>>> reboot stuck mean system does not reboot any more? >> >> It freezes when going for reboot. >> Have to power off/on to boot again. >> >> Btw I use an mmc, not an sd-card. >> No other HW connected, just LAN-cable. >> Bootloader is u-boot v2015.10. >> o > Have checked on 4.3.0-rc6-00006-gd03c139e7e77, still works on peach boards. > Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help here to check whats wrong. To me its looks more of a board specific issue for now. > Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). Having said that I think I know what is the issue here. Markus said that he is using an eMMC instead of an uSD (which is what I used and my guess is that Krzysztof did too). Now, there is a subtle difference between the old PMU restart handler and the syscon-reboot one, and that is the restart handler priorities: notifier priority ------------------------------------ pmu_restart_notify 128 mmc_pwrseq_emmc_reset_nb 129 syscon_restart_handle 192 So, without Alim's patches, first the eMMC reset handler will be called and then the PMU restart handler but after his series, the syscon reset handler has a higher priority so the eMMC reset will never be called. But the problem is that the eMMC card has to be properly reset on system restart to allow the SoC iROM to be able to read the bootloader from the eMMC since the iROM doesn't have restart logic and the card shouldn't be left in an unknown state. So the problem here is not that the system is not being reset (that I think that works) but that on reboot, the system is not able to boot again since the ROM is not able to read the second stage bootloader. Markus, Can you please test following patch [0] on top of Alim's series? If that works then it should either be part of Alim's series or the patches will have to wait until that patch lands into mainline. I don't have an eMMC to test it in XU4 but I'm pretty confident that it will solve the issue. Best regards, Tested-by: Markus Reichl Tested-by: Anand Moon Reviewed-by: Alim Akhtar diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c index 137c97fb7aa8..ad4f94ec7e8d 100644 --- a/drivers/mmc/core/pwrseq_emmc.c +++ b/drivers/mmc/core/pwrseq_emmc.c @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host, /* * register reset handler to ensure emmc reset also from - * emergency_reboot(), priority 129 schedules it just before - * system reboot + * emergency_reboot(), priority 255 is the highest priority + * so it will be executed before any system reboot handler. */ pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; - pwrseq->reset_nb.priority = 129; + pwrseq->reset_nb.priority = 255; register_restart_handler(&pwrseq->reset_nb); pwrseq->pwrseq.ops = &mmc_pwrseq_emmc_ops;