From patchwork Tue Feb 2 10:42:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 61004 Delivered-To: patch@linaro.org Received: by 10.112.130.2 with SMTP id oa2csp644740lbb; Tue, 2 Feb 2016 02:42:54 -0800 (PST) X-Received: by 10.66.144.5 with SMTP id si5mr45784789pab.51.1454409774633; Tue, 02 Feb 2016 02:42:54 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ks7si1140714pab.129.2016.02.02.02.42.54; Tue, 02 Feb 2016 02:42:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dkim=neutral (body hash did not verify) header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754537AbcBBKmx (ORCPT + 11 others); Tue, 2 Feb 2016 05:42:53 -0500 Received: from mail-yk0-f176.google.com ([209.85.160.176]:34562 "EHLO mail-yk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754382AbcBBKmw (ORCPT ); Tue, 2 Feb 2016 05:42:52 -0500 Received: by mail-yk0-f176.google.com with SMTP id u9so48211982ykd.1 for ; Tue, 02 Feb 2016 02:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QMEFEx3iGw7Yx1iavMWH/Uc74Xpu/PWZ5Qejw28jCTE=; b=AkGuoeCpbIyHv6CyPGlBJqVfWj5bym1iQx72xb5RX8ywQFQEPfwl93B4YPVsNG08KI PSbNdELqMrfOkMaFyzuqM+EfNH7FJ6e2DRONPAAxQnRJUfI1kYT4k9BZfLrOx/qW22TM GEGIB26PU/VBIwYYS8fz2M0ndgnFVFZbPRDrA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QMEFEx3iGw7Yx1iavMWH/Uc74Xpu/PWZ5Qejw28jCTE=; b=X74KecozoY8E0Ozt9LN0NG4BvhgaJgm0nebbj0rNvpZCKWeYBKFXzCXlMNlKqO0phN Cry7W3lqqzLDPdCzqMxZA3EGGD8SNWWeulKKvnh46idBt4PcoMBWbcTBge8ghJ78uTKa aKzYh2eX17/RppCuMi1Dn8HwMPof2us23rMLh6OQNGXm7xEAGARr9g4MjxixvmfH44ON e3Ifqb0CdHrQyuei5AepufZeUFzGbQqUqyrVMiTFD/R753D8mo7ngXLWUnUk4b3CHey2 CZyoRcCHMSYp9uziGYoWeB4ydb4Jl5plcfcQoJk9PI4baaws9KuQEamzJb4hkLRJcwWT ChoA== X-Gm-Message-State: AG10YOQ86JSSDdS3WzRiMkVlEjWtvfXbovrPeqAkqw2ePsdhez0CAcJhYZCQLPWxtJ5HGBrUkv1mItlsnmp5cBDh MIME-Version: 1.0 X-Received: by 10.37.16.197 with SMTP id 188mr18025490ybq.114.1454409771530; Tue, 02 Feb 2016 02:42:51 -0800 (PST) Received: by 10.129.114.84 with HTTP; Tue, 2 Feb 2016 02:42:51 -0800 (PST) In-Reply-To: References: <20160201232833.GR19432@atomide.com> <20160202030533.GT19432@atomide.com> Date: Tue, 2 Feb 2016 11:42:51 +0100 Message-ID: Subject: Re: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 From: Ulf Hansson To: Tony Lindgren , Alan Stern , "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , Linux OMAP Mailing List , "linux-arm-kernel@lists.infradead.org" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org > > Instead of the suggested approaches, I think the regression should be > fixed at the PM domain level (omap hwmod). I have attached a patch > below, please give it try as it's untested. Realized that version 1 would actually *only* make the PM domain code to deal with pre-enabled devices. It would still invoke the driver's ->runtime_resume() callbacks (via pm_generic_runtime_resume()) for these scenarios. That's not what we want. So I moved the checks to the actual ->runtime_resume() callback in the PM domain, instead of in the omap_device_enable() function. A version 2 is attached. Please give it at try. [...] From: Ulf Hansson Date: Tue, 2 Feb 2016 10:05:39 +0100 Subject: [PATCH V2] ARM: OMAP2+: omap-device: Allow devices to be pre-enabled Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error and driver unbind") may re-initialize the runtime PM status of the device to RPM_SUSPENDED at driver probe failures. For the omap_hsmmc and likely also other omap drivers, which needs more than one attempt to ->probe() (returning -EPROBE_DEFER), this commit causes a regression at the PM domain level (omap hwmod). The reason is that the drivers don't put back the device into low power state while bailing out in ->probe to return -EPROBE_DEFER. This leads to that pm_runtime_reinit() in driver core, is re-initializing the runtime PM status from RPM_ACTIVE to RPM_SUSPENDED. The next ->probe() attempt then triggers the ->runtime_resume() callback to be invoked, which means this happens two times in a row. At the PM domain level (omap hwmod) this is being treated as an error and thus the runtime PM status of the device isn't correctly synchronized with the runtime PM core. In the end, ->probe() anyway succeeds (as the driver don't checks the error code from the runtime PM APIs), but results in that the PM domain always stays powered on. This because of the runtime PM core believes the device is RPM_SUSPENDED. Fix this regression by allowing devices to be pre-enabled when the PM domain's (omap hwmod) ->runtime_resume() callback is requested to enable the device. In such cases, return zero to synchronize the runtime PM status with the runtime PM core. Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error and driver unbind") Signed-off-by: Ulf Hansson --- Changes in v2: -Prevent a driver's ->runtime_resume() callbacks from being invoked for a pre-enabled device. --- arch/arm/mach-omap2/omap_device.c | 9 +++++++++ 1 file changed, 9 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index 0437537..1ad390b 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -599,8 +599,17 @@ static int _od_runtime_suspend(struct device *dev) static int _od_runtime_resume(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); + struct omap_device *od = to_omap_device(pdev); int ret; + /* + * From the PM domain perspective the device may already be enabled. + * In such case, let's return zero to synchronize the state with the + * runtime PM core. + */ + if (od->_state == OMAP_DEVICE_STATE_ENABLED) + return 0; + ret = omap_device_enable(pdev); if (ret) return ret;