From patchwork Mon Jul 8 13:35:12 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 2824891 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1CB1FC0AB2 for ; Mon, 8 Jul 2013 13:47:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BBA8B201D5 for ; Mon, 8 Jul 2013 13:47:12 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5697B201D4 for ; Mon, 8 Jul 2013 13:47:11 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UwBe6-0007ys-QH; Mon, 08 Jul 2013 13:38:37 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UwBba-0000cr-CC; Mon, 08 Jul 2013 13:35:50 +0000 Received: from comal.ext.ti.com ([198.47.26.152]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UwBbX-0000cG-4c for linux-arm-kernel@lists.infradead.org; Mon, 08 Jul 2013 13:35:48 +0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id r68DZPqU020735; Mon, 8 Jul 2013 08:35:25 -0500 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id r68DZPO7029896; Mon, 8 Jul 2013 08:35:25 -0500 Received: from dlelxv22.itg.ti.com (172.17.1.197) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.2.342.3; Mon, 8 Jul 2013 08:35:24 -0500 Received: from localhost (h78-11.vpn.ti.com [172.24.78.11]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id r68DZObY003207; Mon, 8 Jul 2013 08:35:24 -0500 Date: Mon, 8 Jul 2013 16:35:12 +0300 From: Felipe Balbi To: Rajendra Nayak Subject: Re: Boot hang regression 3.10.0-rc4 -> 3.10.0 Message-ID: <20130708133512.GD31221@arwen.pp.htv.fi> References: <51D59146.3070002@newflow.co.uk> <51D59C0E.8080003@newflow.co.uk> <20130705115959.GQ5523@atomide.com> <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com> <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com> MIME-Version: 1.0 In-Reply-To: <51DABC81.3080409@ti.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130708_093547_320544_6E65ACA9 X-CRM114-Status: GOOD ( 35.22 ) X-Spam-Score: -7.2 (-------) Cc: Paul Walmsley , Mark Jackson , Tony Lindgren , "Bedia, Vaibhav" , Sourav Poddar , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: balbi@ti.com 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=-4.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, 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 Hi, On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote: > >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead > >>>>>> of -1 for the serial driver? > >>>>>> > >>>>> > >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i > >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1. > >>> > >>> OK > >> > >> Issue 2: Causing boot to stop when serial driver is initialized. > >> (After Issue 1 is fixed) > >> > >> I could narrow this down to the change done to return -EINVAL > >> instead of 0 in serial_omap_get_context_loss_count() as part of > >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: > >> Fix device tree based PM runtime" > >> > >> What this change in turn seems to do is cause a > >> serial_omap_restore_context() to get called as part of > >> serial_omap_runtime_resume() which was not the case when > >> serial_omap_get_context_loss_count() returned 0 > >> > >> from serial_omap_runtime_resume(): > >> ----- > >> int loss_cnt = serial_omap_get_context_loss_count(up); > >> > >> if (loss_cnt < 0) { > >> dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n", > >> loss_cnt); > >> serial_omap_restore_context(up); > >> } else if (up->context_loss_cnt != loss_cnt) { > >> serial_omap_restore_context(up); > >> } > >> ----- > >> > >> I am still working on why a serial_omap_restore_context() could > >> have caused console to die. I will work with Sourav on this and > >> post the fixes for both issue 1 and issue2 once its clear on whats > >> really causing issue 2. > > > > That's because we don't have the omap specific pdata callbacks for > > context loss any longer. We may be able to detect when the context > > was really lost in the serial driver, and only then call the > > serial_omap_restore_context(). > > Right, but calling serial_omap_restore_context() even when the context > is not lost, should not ideally cause an issue. it does in one condition. If context hasn't been saved before. And that can happen in the case of wrong pm runtime status for that device. Imagine the device is marked as suspended even though it's fully enabled (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case your context structure is all zeroes (context has never been saved before) then when you call pm_runtime_get_sync() on probe() your ->runtime_resume() will get called, which will restore context, essentially undoing anything which was configured by u-boot. Am I missing something ? > >> Let me know if the fix I listed for Issue 1: makes sense. > > > > Yes makes sense as a fix, but IMHO we should not need any workarounds > > like that. Is the hwmod code idling the the uarts early? If so, then > > it should only do that in a late_initcall if no drivers are registered. > > hwmod as part of its setup (early) enables/resets and idles all modules. > These flags are used to tell hwmod to avoid a reset and idle and leave the > module enabled (in this case console uart) then it needs to call pm_runtime_set_active() for those devices which have that flag set, right ? (completely untested, didn't even try to compile, just to illustrate) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 7341eff..d8dca68 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh) (postsetup_state == _HWMOD_STATE_IDLE)) { oh->_int_flags |= _HWMOD_SKIP_ENABLE; postsetup_state = _HWMOD_STATE_ENABLED; + + /* tell pm_runtime this device is already active */ + pm_runtime_set_active(&oh->od->pdev->dev); + } else { + /* tell pm_runtime this device is trully suspended */ + pm_runtime_set_suspended(&oh->od->pdev->dev); } if (postsetup_state == _HWMOD_STATE_IDLE)