From patchwork Tue Oct 13 14:10:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 7385901 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 98270BEEA4 for ; Tue, 13 Oct 2015 14:10:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C9784205B6 for ; Tue, 13 Oct 2015 14:10:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D2648205BC for ; Tue, 13 Oct 2015 14:10:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752768AbbJMOKr (ORCPT ); Tue, 13 Oct 2015 10:10:47 -0400 Received: from mail-lb0-f173.google.com ([209.85.217.173]:33550 "EHLO mail-lb0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751904AbbJMOKq (ORCPT ); Tue, 13 Oct 2015 10:10:46 -0400 Received: by lbbk10 with SMTP id k10so21797048lbb.0 for ; Tue, 13 Oct 2015 07:10:44 -0700 (PDT) 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:date:message-id; bh=VxZeYVBKQPxZ6PXDN9yybkira8AVIKwoY5nKTJOm5J8=; b=QP39BmMxmQPl/gMsc4+8FHIUlF/dHQopEt25ZhH0+rSHnTO2jKgtS/baVCawEtz6C8 ph16ig4/m3olPg7qfODg2p1spRb3EinvbImAdX3jiy1WpwqU8cS6jIH3Je/oXoXMTrvj zbmHkJTjMEFhwVkdbcRO8OOIEHRpWkfZLaJ9DZAUuuSvD26bbHXzQGwot92tdiLjKN8t j0ksuyHDwAuCGFzLPPenvuSJbtX9dXX0BeMtDAqWhgGICnYtQpGitp7HD2F2cbZtGJAG 3/bf6dETqrkLfwj90jTPzftPVRjACRi3MRDhUMUN5TxauCFq0ZzkMaVG5xJ+xfPdtbdt /mNA== X-Gm-Message-State: ALoCoQlBKJ/MarnMlzF0L19nsRv5llVaRPAs00wneudwF6bjbcgjX6n3R2FIErZVDb3AqyRvLazY X-Received: by 10.112.147.39 with SMTP id th7mr15111076lbb.82.1444745443776; Tue, 13 Oct 2015 07:10:43 -0700 (PDT) Received: from uffe-Latitude-E6430s.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id m133sm551703lfg.47.2015.10.13.07.10.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Oct 2015 07:10:43 -0700 (PDT) From: Ulf Hansson To: "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , linux-pm@vger.kernel.org Cc: Len Brown , Pavel Machek , Geert Uytterhoeven , Lina Iyer , Krzysztof Kozlowski Subject: [PATCH] PM / Domains: Fix validation of latency constraints in genpd governor Date: Tue, 13 Oct 2015 16:10:28 +0200 Message-Id: <1444745428-4396-1-git-send-email-ulf.hansson@linaro.org> X-Mailer: git-send-email 1.9.1 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_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 Commit ba2bbfbf6307 ("PM / Domains: Remove intermediate states from the power off sequence") changed the power off sequence in genpd. That also required some updates regarding the validation of latency constraints in the genpd governor. Unfortunate that wasn't covered, so let's fix this. From a runtime PM and latency point of view, we need to consider the worst case scenario while validating latency constraints. That's typically when a call to pm_runtime_get_sync() needs to wait for a ongoing runtime suspend operation to be carried out, as it then also needs to wait for the device to be runtime resumed again. The above mentioned commit made the genpd governor's ->stop_ok() callback responsible of validating genpd's device's runtime suspend/resume latency. In other words, the constraint needs to be validated towards the relevant latencies present in genpd's ->runtime_suspend|resume() callbacks. Earlier, that included latencies from the ->stop|start() callbacks, but as ->save|restore_state() are now also being invoked from genpd's ->runtime_suspend|resume() and to comply with the worst case scenario, let's take also those latencies into account. Fixes: ba2bbfbf6307 ("PM / Domains: Remove intermediate states from the power off sequence") Signed-off-by: Ulf Hansson --- drivers/base/power/domain_governor.c | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/drivers/base/power/domain_governor.c b/drivers/base/power/domain_governor.c index 2a4154a..85e17ba 100644 --- a/drivers/base/power/domain_governor.c +++ b/drivers/base/power/domain_governor.c @@ -77,13 +77,16 @@ static bool default_stop_ok(struct device *dev) dev_update_qos_constraint); if (constraint_ns > 0) { - constraint_ns -= td->start_latency_ns; + constraint_ns -= td->save_state_latency_ns + + td->stop_latency_ns + + td->start_latency_ns + + td->restore_state_latency_ns; if (constraint_ns == 0) return false; } td->effective_constraint_ns = constraint_ns; - td->cached_stop_ok = constraint_ns > td->stop_latency_ns || - constraint_ns == 0; + td->cached_stop_ok = constraint_ns >= 0; + /* * The children have been suspended already, so we don't need to take * their stop latencies into account here. @@ -126,18 +129,6 @@ static bool default_power_down_ok(struct dev_pm_domain *pd) off_on_time_ns = genpd->power_off_latency_ns + genpd->power_on_latency_ns; - /* - * It doesn't make sense to remove power from the domain if saving - * the state of all devices in it and the power off/power on operations - * take too much time. - * - * All devices in this domain have been stopped already at this point. - */ - list_for_each_entry(pdd, &genpd->dev_list, list_node) { - if (pdd->dev->driver) - off_on_time_ns += - to_gpd_data(pdd)->td.save_state_latency_ns; - } min_off_time_ns = -1; /* @@ -193,7 +184,6 @@ static bool default_power_down_ok(struct dev_pm_domain *pd) * constraint_ns cannot be negative here, because the device has * been suspended. */ - constraint_ns -= td->restore_state_latency_ns; if (constraint_ns <= off_on_time_ns) return false;