Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2653998imm; Thu, 11 Oct 2018 13:57:04 -0700 (PDT) X-Google-Smtp-Source: ACcGV61wPPf/CX4zBv+39XFui0g8WT/ry9pwV9GKrbddU1qPcrNC57fPaRLh/YL5UunZyNIs1Ord X-Received: by 2002:a17:902:654e:: with SMTP id d14-v6mr3012760pln.292.1539291424434; Thu, 11 Oct 2018 13:57:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539291424; cv=none; d=google.com; s=arc-20160816; b=VW01i2vk/LovqWjKxQ3XBlmse+zJz+5hR07xGMQiw4d+PxI/vpjqM8Y0/9JO02TcEb DounxdftETGSiMKe/cChj1aQJCBm5qX7mx8fPL5B15f+alQXMoHffBD3xUpOzc+6jwWd POwb6cJGuN1OhtlYyfcJeZnsy4hTzmW9R77gi+H4rpEdGFPOfdsm3RI0/dXQwNQz/Rrs oHB0xIcIYMdf+/2c8Jn8dgGLpBaej1+8BFA63Re2NxCjYxFbHyqtgCxqfQkuQKFQbUTK OqUQa9VEamE4DKg6blWCnRdRimtH7pr8mYpaF7hw5JZHlHupk8hI+8Rr8IJDToDoPHHa i8wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=UV6Rwy7LelIB1BwNyeetsOU2hU20cuOvPTwqTUzO2tM=; b=0Ht0l5kgpIrWL33AzVHQ1I3pjuKhzCFL4oToB4GPrmCOqAvmVToPfOL7qmPOOijdZz KsHZK4ZlJlE9neN3LT6Lvc9gJvc/Sc6PPtpF2bqB/MWsiT0EKHelniNwvlzK4P4BdFKO DeOxU7reQIEi0zspPHQjfJt1wB5Ol8cx4ceW6CkM5pd9HlgXz8FAR/BYF/9T1vXGjHW0 WVp+RjxLJ7Rw2xPSoMGclCQZ+qhuXxxI3m5FVoBfhZyKODFlL69MplgsjtkPqHrJckCw nYYYdOsJothZUmKcQGiteweW4ZI6DgcRsmI2kHaSGEjLZp2EcEJo00KUty2jMNbV9pG3 uEoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p17-v6si24753637pgh.515.2018.10.11.13.56.49; Thu, 11 Oct 2018 13:57:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726944AbeJLEZB (ORCPT + 99 others); Fri, 12 Oct 2018 00:25:01 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:57742 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726074AbeJLEZB (ORCPT ); Fri, 12 Oct 2018 00:25:01 -0400 Received: from 79.184.255.62.ipv4.supernova.orange.pl (79.184.255.62) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.148) id d047225c2c476713; Thu, 11 Oct 2018 22:56:00 +0200 From: "Rafael J. Wysocki" To: "Raju P.L.S.S.S.N" Cc: andy.gross@linaro.org, david.brown@linaro.org, ulf.hansson@linaro.org, khilman@kernel.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, rnayak@codeaurora.org, bjorn.andersson@linaro.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, sboyd@kernel.org, evgreen@chromium.org, dianders@chromium.org, mka@chromium.org, ilina@codeaurora.org Subject: Re: [PATCH RFC v1 2/8] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs Date: Thu, 11 Oct 2018 22:52:51 +0200 Message-ID: <8161939.SRDo8Qx48D@aspire.rjw.lan> In-Reply-To: <1539206455-29342-3-git-send-email-rplsssn@codeaurora.org> References: <1539206455-29342-1-git-send-email-rplsssn@codeaurora.org> <1539206455-29342-3-git-send-email-rplsssn@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, October 10, 2018 11:20:49 PM CEST Raju P.L.S.S.S.N wrote: > From: Ulf Hansson > > To allow CPUs being power managed by PM domains, let's deploy support for > runtime PM for the CPU's corresponding struct device. > > More precisely, at the point when the CPU is about to enter an idle state, > decrease the runtime PM usage count for its corresponding struct device, > via calling pm_runtime_put_sync_suspend(). Then, at the point when the CPU > resumes from idle, let's increase the runtime PM usage count, via calling > pm_runtime_get_sync(). > > Cc: Lina Iyer > Co-developed-by: Lina Iyer > Signed-off-by: Ulf Hansson > Signed-off-by: Raju P.L.S.S.S.N > (am from https://patchwork.kernel.org/patch/10478153/) > --- > kernel/cpu_pm.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c > index 67b02e1..492d4a8 100644 > --- a/kernel/cpu_pm.c > +++ b/kernel/cpu_pm.c > @@ -16,9 +16,11 @@ > */ > > #include > +#include > #include > #include > #include > +#include > #include > #include > > @@ -91,6 +93,7 @@ int cpu_pm_enter(void) > { > int nr_calls; > int ret = 0; > + struct device *dev = get_cpu_device(smp_processor_id()); > > ret = cpu_pm_notify(CPU_PM_ENTER, -1, &nr_calls); > if (ret) > @@ -100,6 +103,9 @@ int cpu_pm_enter(void) > */ > cpu_pm_notify(CPU_PM_ENTER_FAILED, nr_calls - 1, NULL); > > + if (!ret && dev && dev->pm_domain) > + pm_runtime_put_sync_suspend(dev); This may cause a power domain to go off, but if it goes off, then the idle governor has already selected idle states for all of the CPUs in that domain. Is there any way to ensure that turning the domain off (and later on) will no cause the target residency and exit latency expectations for those idle states to be exceeded? > + > return ret; > } > EXPORT_SYMBOL_GPL(cpu_pm_enter); > @@ -118,6 +124,11 @@ int cpu_pm_enter(void) > */ > int cpu_pm_exit(void) > { > + struct device *dev = get_cpu_device(smp_processor_id()); > + > + if (dev && dev->pm_domain) > + pm_runtime_get_sync(dev); > + > return cpu_pm_notify(CPU_PM_EXIT, -1, NULL); > } > EXPORT_SYMBOL_GPL(cpu_pm_exit); >