From patchwork Thu Jun 30 22:40:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Hilman X-Patchwork-Id: 9209033 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 309806089D for ; Thu, 30 Jun 2016 22:40:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1DE2A2845D for ; Thu, 30 Jun 2016 22:40:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 124AF28691; Thu, 30 Jun 2016 22:40:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2C5922868A for ; Thu, 30 Jun 2016 22:40:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752547AbcF3WkZ (ORCPT ); Thu, 30 Jun 2016 18:40:25 -0400 Received: from mail-pf0-f170.google.com ([209.85.192.170]:35031 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbcF3WkU (ORCPT ); Thu, 30 Jun 2016 18:40:20 -0400 Received: by mail-pf0-f170.google.com with SMTP id c2so33646885pfa.2 for ; Thu, 30 Jun 2016 15:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version; bh=ux5alZOinT7hCwlI2l2D0s8Dri2la0Yg+xWXR9hHSmU=; b=vnozlrDyTqQT0Uo5hzkcOfud8ObjnkOMGnmCW8ezc0vX3kI4iUxWqOKToGlNdaG5W6 eEgR7961aPa5kparwOMn47DQm7kQ1k0+ZdFKvVypAqrIYqu6+4gUPy9Z76PM+wntghz7 Ownq5Ob56Xo+jl6lne4KEkhznDMQdnAUOUmoHUfd5SevNpEGY3dbUA0wn2DUz8gu3hc8 OFFF+kfwif4IlVCiINITGicqilc8ISH+yhj8L8n1uUt7z8fqZV+HQ2W/4o+4vmja+QFl YHygD1qVs/JgnR1VBEyGNXu8NaUyTTQC9ZL4x2iYZp72bVVIG1hsiLo5pZPBVxYgFmV7 aBfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references:date :in-reply-to:message-id:user-agent:mime-version; bh=ux5alZOinT7hCwlI2l2D0s8Dri2la0Yg+xWXR9hHSmU=; b=PkN6/R9Ob+o8mqSptbyY65ZCja3jiq9h7V4jDymFnDe3PbCs/VrYjxhyRLAvClmA7r wRNMNDTfefN2ALZ+UiWwESoavdNQrV+ZrICUgbleVChfyBRFgc2I189KycSDh6jebiYz bnbiA2KwMt2HU+C1uHHWs8o4tJv5Fj2si9QwI4ZhXvtC2AS3LhgdPSVB4+B7hRk3bf8M eMP148DDGSUIsBIVK/IPVabtdJw8fi4azFBPwVjh1SisAPyo5GJkymzLaAxBbW93Wl7p n1oNKrERdX9kFCWouZnsuk6WnKoz/jNsmBk7jZ6VnQyoOTDMJ2g4TABjt/ApiLZh3SR4 5IXA== X-Gm-Message-State: ALyK8tKgLsuaLhjJNpGFHFGYpz5eAFsSj6EyisSVqLSU4RBq9srTHNW6qnvTejhkQtdc5UsR X-Received: by 10.98.96.67 with SMTP id u64mr25827401pfb.70.1467326418964; Thu, 30 Jun 2016 15:40:18 -0700 (PDT) Received: from localhost (c-98-203-232-209.hsd1.wa.comcast.net. [98.203.232.209]) by smtp.gmail.com with ESMTPSA id zv2sm349680pac.43.2016.06.30.15.40.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2016 15:40:18 -0700 (PDT) From: Kevin Hilman To: Geert Uytterhoeven Cc: Ulf Hansson , "Rafael J. Wysocki" , Linux PM list , Len Brown , Pavel Machek , Geert Uytterhoeven , Lina Iyer , Axel Haslam , Marek Szyprowski , Jon Hunter , Andy Gross , Laurent Pinchart , Linux-Renesas Subject: Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Organization: BayLibre References: <1463485296-22742-1-git-send-email-ulf.hansson@linaro.org> <1463485296-22742-5-git-send-email-ulf.hansson@linaro.org> Date: Thu, 30 Jun 2016 15:40:15 -0700 In-Reply-To: (Geert Uytterhoeven's message of "Tue, 28 Jun 2016 18:26:36 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) MIME-Version: 1.0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Geert, Geert Uytterhoeven writes: > Hi Ulf, Rafael, > > On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson wrote: >> When the pm_runtime_force_suspend|resume() helpers were invented, we still >> had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options. >> >> To make sure these helpers worked for all combinations and without >> introducing too much of complexity, the device was always resumed in >> pm_runtime_force_resume(). >> >> More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was >> unset, we needed to resume the device as the subsystem/driver couldn't >> rely on using runtime PM to do it. >> >> As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it >> removed this combination, of using CONFIG_PM_SLEEP without the earlier >> CONFIG_PM_RUNTIME. >> >> For this reason we can now rely on the subsystem/driver to use runtime PM >> to resume the device, instead of forcing that to be done in all cases. In >> other words, let's defer this to a later point when it's actually needed. >> >> Signed-off-by: Ulf Hansson >> --- >> drivers/base/power/runtime.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c >> index 09e4eb1..1db7b46 100644 >> --- a/drivers/base/power/runtime.c >> +++ b/drivers/base/power/runtime.c >> @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev) >> if (!pm_runtime_status_suspended(dev)) >> goto out; >> >> + /* >> + * The PM core increases the runtime PM usage count in the system PM >> + * prepare phase. If the count is greather than 1 at this point, someone >> + * else has also increased it. In that case, invoke the runtime resume >> + * callback for the device as that is likely what is expected. In other >> + * case we trust the subsystem/driver to runtime resume the device when >> + * it's actually needed. >> + */ >> + if (atomic_read(&dev->power.usage_count) < 2) >> + goto out; >> + >> ret = pm_runtime_set_active(dev); >> if (ret) >> goto out; > > This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on > sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller is a > child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and > simple-pm-bus, cfr. > > arch/arm/boot/dts/r8a73a4-ape6evm.dts > arch/arm/boot/dts/r8a73a4.dtsi > arch/arm/boot/dts/sh73a0-kzm9g.dts > arch/arm/boot/dts/sh73a0.dtsi > > During resume, the bus clock is not enabled, causing an imprecise abort > when accessing the Ethernet controller's registers. I have a hunch (without too much digging) that this may be an odd interaction with the direct_complete stuff since the simple-pm-bus has no callbacks. For kicks, could you add something like the hack below (untested) which will avoid the direct_complete path, and at least help indicate if that path is worth investigating further. Thanks, Kevin --- 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/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c index c5eb46cbf388..63b95fb21510 100644 --- a/drivers/bus/simple-pm-bus.c +++ b/drivers/bus/simple-pm-bus.c @@ -36,6 +36,15 @@ static int simple_pm_bus_remove(struct platform_device *pdev) return 0; } +static int simple_pm_bus_prepare(struct device *dev) +{ + return pm_generic_prepare(dev); +} + +static const struct dev_pm_ops simple_pm_bus_ops = { + .prepare = simple_pm_bus_prepare, +}; + static const struct of_device_id simple_pm_bus_of_match[] = { { .compatible = "simple-pm-bus", }, { /* sentinel */ } @@ -48,6 +57,7 @@ static struct platform_driver simple_pm_bus_driver = { .driver = { .name = "simple-pm-bus", .of_match_table = simple_pm_bus_of_match, + .pm = &simple_pm_bus_ops, }, };