From patchwork Thu Jul 11 09:26: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: 2826236 Return-Path: X-Original-To: patchwork-linux-omap@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 8A7D6C0AB2 for ; Thu, 11 Jul 2013 09:26:59 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8AD9820115 for ; Thu, 11 Jul 2013 09:26:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 803FE2010A for ; Thu, 11 Jul 2013 09:26:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755925Ab3GKJ04 (ORCPT ); Thu, 11 Jul 2013 05:26:56 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:43276 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879Ab3GKJ0z (ORCPT ); Thu, 11 Jul 2013 05:26:55 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id r6B9QTAi008942; Thu, 11 Jul 2013 04:26:29 -0500 Received: from DLEE71.ent.ti.com (dlee71.ent.ti.com [157.170.170.114]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id r6B9QTDe012755; Thu, 11 Jul 2013 04:26:29 -0500 Received: from dlelxv22.itg.ti.com (172.17.1.197) by DLEE71.ent.ti.com (157.170.170.114) with Microsoft SMTP Server id 14.2.342.3; Thu, 11 Jul 2013 04:26:29 -0500 Received: from localhost (h79-1.vpn.ti.com [172.24.79.1]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id r6B9QSVv020477; Thu, 11 Jul 2013 04:26:29 -0500 Date: Thu, 11 Jul 2013 12:26:12 +0300 From: Felipe Balbi To: Rajendra Nayak CC: , Tony Lindgren , Kevin Hilman , "Bedia, Vaibhav" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Mark Jackson , Sourav Poddar , Paul Walmsley Subject: Re: Boot hang regression 3.10.0-rc4 -> 3.10.0 Message-ID: <20130711092612.GG23892@arwen.pp.htv.fi> Reply-To: References: <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com> <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com> <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org> <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi> <51DE780C.2070701@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51DE780C.2070701@ti.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, 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 Thu, Jul 11, 2013 at 02:47:00PM +0530, Rajendra Nayak wrote: > On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote: > > how about something like below ? It makes omap_device/hwmod and > > pm_runtime agree on the initial state of the device and will prevent > > ->runtime_resume() from being called on first pm_runtime_get*() done > > during probe. > > > > This is similar to what PCI bus does (if you look at pci_pm_init()). > > I tried something similar [1] but what I found is that the serial > runtime resume was called despite it being marked as active using > pm_runtime_set_active(). > > That seems to be because of the pm_runtime_set_autosuspend_delay() > because we have the autosuspend_delay = -1 > > ----- > static void update_autosuspend(struct device *dev, int old_delay, int old_use) > { > int delay = dev->power.autosuspend_delay; > > /* Should runtime suspend be prevented now? */ > if (dev->power.use_autosuspend && delay < 0) { > > /* If it used to be allowed then prevent it. */ > if (!old_use || old_delay >= 0) { > atomic_inc(&dev->power.usage_count); > rpm_resume(dev, 0); <------------------------------- calls serial runtime resume. > } > } > ----- > > So we end up with the same issue with serial resume being called before set_termios() yeah, that part I figured out after I started testing today. It seems like my latest version is getting closer but I still see problems, diff below: diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index e6d2307..0cc2da9 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -181,6 +181,26 @@ odbfd_exit: return ret; } +static void omap_device_pm_init(struct platform_device *pdev) +{ + omap_device_enable(pdev); + pm_runtime_forbid(&pdev->dev); + pm_runtime_set_active(&pdev->dev); + device_enable_async_suspend(&pdev->dev); +} + +static void omap_device_pm_allow(struct platform_device *pdev) +{ + pm_runtime_allow(&pdev->dev); +} + +static void omap_device_pm_exit(struct platform_device *pdev) +{ + device_disable_async_suspend(&pdev->dev); + pm_runtime_set_suspended(&pdev->dev); + omap_device_idle(pdev); +} + static int _omap_device_notifier_call(struct notifier_block *nb, unsigned long event, void *dev) { @@ -192,16 +212,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb, if (pdev->archdata.od) omap_device_delete(pdev->archdata.od); break; + case BUS_NOTIFY_BIND_DRIVER: + if (pdev->archdata.od) + omap_device_pm_init(pdev); + break; + case BUS_NOTIFY_BOUND_DRIVER: + if (pdev->archdata.od) + omap_device_pm_allow(pdev); + break; + case BUS_NOTIFY_UNBOUND_DRIVER: + if (pdev->archdata.od) + omap_device_pm_exit(pdev); + break; case BUS_NOTIFY_ADD_DEVICE: if (pdev->dev.of_node) omap_device_build_from_dt(pdev); - /* fall through */ + break; default: - od = to_omap_device(pdev); - if (od) - od->_driver_status = event; + /* nothing */ + break; } + od = to_omap_device(pdev); + if (od) + od->_driver_status = event; + return NOTIFY_DONE; }