Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp445271imu; Fri, 11 Jan 2019 03:16:30 -0800 (PST) X-Google-Smtp-Source: ALg8bN7ZQsCuuKVOfEcSWvTlnhlYxrkZMwkVKxrMIVjZPXUpqQInpCOv79BeQw8KSrDuCihQD0Uf X-Received: by 2002:a17:902:7e4f:: with SMTP id a15mr9890635pln.149.1547205390638; Fri, 11 Jan 2019 03:16:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547205390; cv=none; d=google.com; s=arc-20160816; b=NbgPuQHIVQe26WPUEgmhDJkXq3S3xugAxIQRpdQUFsGtklUzDz+Pdel6bSHDjrp38W Qs7S2wHK9ascp/9bAyMQdbprIZH72WJrMbGH3gDBMh+X9LLXbiusosdLqimVh3NZXaw3 iTRZhDDk/7BMO6fkb2REB05vgCxifcLVTVsqpWcUEvNH1Z41pqLSq9q18fcXpPlS/sVU qEXWHYfNRdykQvnNSc2etDXFp/R4IevEl05pEARYKX2BcVfBwXEJjb6NqtCU/DwmURc2 nLtK7e4hgHUPUgwJB0Zlcy+C+IzeQOFunSRsWCceCBCphUGPpDVvtfLQKLHBqHhGegvz snqA== 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=5uOVeemcCGeRHPwIayRM3Q9wvWTjuVIJWcqXuZq7RdQ=; b=MZxCRapcFO6isvNz/uGJjR4ok4oh55uNDS14weXSDIaafDmagIF7wx0wvGB1E1NqaV hv+lDoscFzqgUI/sDp7PX7towrV1LBhRdRdSJeodkFbdR5VYEQ//koN8fObEtGJRDTnk rnco8GTK9TgdiPj4F6ME1TW8i2fq4vsLF7RxS59LubS4ixJhsaPJeHjVB0hFr/TY1eQh nz6YbkG6h7uGy6vDw9Izvr+MVtSsneV2JYR6zKuzG3GHA6v8JrKL/lZFpJ+fDvsEshwK 6QEBTMm4UGfB/62SZM6ztwXxgIDOkSHA5eY9490/8gHzN/w7vW6Jbb5WcRfFLqs7LfzR 18bw== 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 z19si36481722pfc.95.2019.01.11.03.16.14; Fri, 11 Jan 2019 03:16:30 -0800 (PST) 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 S1731826AbfAKKzM (ORCPT + 99 others); Fri, 11 Jan 2019 05:55:12 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:57501 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725789AbfAKKzL (ORCPT ); Fri, 11 Jan 2019 05:55:11 -0500 Received: from 79.184.254.168.ipv4.supernova.orange.pl (79.184.254.168) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.183) id ac8736e6ecfb3cd6; Fri, 11 Jan 2019 11:55:08 +0100 From: "Rafael J. Wysocki" To: Ulf Hansson Cc: Daniel Lezcano , Sudeep Holla , Lorenzo Pieralisi , Mark Rutland , Linux PM , "Raju P . L . S . S . S . N" , Stephen Boyd , Tony Lindgren , Kevin Hilman , Lina Iyer , Viresh Kumar , Vincent Guittot , Geert Uytterhoeven , Linux ARM , linux-arm-msm , Linux Kernel Mailing List Subject: Re: [PATCH v10 02/27] PM / Domains: Add support for CPU devices to genpd Date: Fri, 11 Jan 2019 11:54:20 +0100 Message-ID: <1993885.1ZciKZtFgT@aspire.rjw.lan> In-Reply-To: References: <20181129174700.16585-1-ulf.hansson@linaro.org> <45ff9a4b-6130-7800-28cc-a2f5f736f44b@linaro.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, December 19, 2018 11:02:05 AM CET Ulf Hansson wrote: > On Wed, 19 Dec 2018 at 10:53, Daniel Lezcano wrote: > > > > On 29/11/2018 18:46, Ulf Hansson wrote: > > > To enable a device belonging to a CPU to be attached to a PM domain managed > > > by genpd, let's do a few changes to it, as to make it convenient to manage > > > the specifics around CPUs. > > > > > > To be able to quickly find out what CPUs that are attached to a genpd, > > > which typically becomes useful from a genpd governor as following changes > > > is about to show, let's add a cpumask to the struct generic_pm_domain. At > > > the point when a CPU device gets attached to a genpd, let's update its > > > cpumask. Moreover, let's also propagate changes to the cpumask upwards in > > > the topology to the master PM domains. In this way, the cpumask for a genpd > > > hierarchically reflects all CPUs attached to the topology below it. > > > > > > Finally, let's make this an opt-in feature, to avoid having to manage CPUs > > > and the cpumask for a genpd that doesn't need it. For that reason, let's > > > add a new genpd configuration bit, GENPD_FLAG_CPU_DOMAIN. > > > > > > Cc: Lina Iyer > > > Co-developed-by: Lina Iyer > > > Signed-off-by: Ulf Hansson > > > --- > > > > > > Changes in v10: > > > - Don't allocate the cpumask when not used. > > > - Simplify the code that updates the cpumask. > > > - Document the GENPD_FLAG_CPU_DOMAIN. > > > > > > --- > > > drivers/base/power/domain.c | 66 ++++++++++++++++++++++++++++++++++++- > > > include/linux/pm_domain.h | 13 ++++++++ > > > 2 files changed, 78 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > > > index e27b91d36a2a..c3ff8e395308 100644 > > > --- a/drivers/base/power/domain.c > > > +++ b/drivers/base/power/domain.c > > > @@ -20,6 +20,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "power.h" > > > > > > @@ -126,6 +127,7 @@ static const struct genpd_lock_ops genpd_spin_ops = { > > > #define genpd_is_irq_safe(genpd) (genpd->flags & GENPD_FLAG_IRQ_SAFE) > > > #define genpd_is_always_on(genpd) (genpd->flags & GENPD_FLAG_ALWAYS_ON) > > > #define genpd_is_active_wakeup(genpd) (genpd->flags & GENPD_FLAG_ACTIVE_WAKEUP) > > > +#define genpd_is_cpu_domain(genpd) (genpd->flags & GENPD_FLAG_CPU_DOMAIN) > > > > > > static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev, > > > const struct generic_pm_domain *genpd) > > > @@ -1377,6 +1379,56 @@ static void genpd_free_dev_data(struct device *dev, > > > dev_pm_put_subsys_data(dev); > > > } > > > > > > +static void __genpd_update_cpumask(struct generic_pm_domain *genpd, > > > + int cpu, bool set, unsigned int depth) > > > +{ > > > + struct gpd_link *link; > > > + > > > + if (!genpd_is_cpu_domain(genpd)) > > > + return; > > > > With this test, we won't continue updating the cpumask for the other > > masters. Is it done on purpose ? > > Correct, and yes it's on purpose. > > We are not even allocating the cpumask for the genpd in question, > unless it has the GENPD_FLAG_CPU_DOMAIN set. So this patch is generally fine by me. You can add my ACK to it when submitting it again, unless it is changed, so I know I've seen it already.