Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp355385imm; Fri, 3 Aug 2018 04:44:18 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfIPx44Hh+62ZQeAu+fmmCqq0Np+dMf7YwIfpm9S8Z9ADJChSIoJNJdkuQ3+m/EF12Wq54c X-Received: by 2002:a62:3b03:: with SMTP id i3-v6mr4088193pfa.197.1533296657924; Fri, 03 Aug 2018 04:44:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533296657; cv=none; d=google.com; s=arc-20160816; b=yx1EfUR8tckUL2Zfnrm1NQteZzHNzkqA7B+aI/XG/hbjW8+Ked8MiQm0S4PAttH5um d00BO61VINvbd9iMSth9kWiAyV+AIsm4u9HNsruQNEDLxfD/uxuATI97iNHjCs1hB6oR RfxixKQr/nJu49KHTqNfnNEVGNeONO2TM+HJ1yRcTWd7I7C0w7Mo1PmLhsVTEkBVlh09 ofyFmLjDfe4jwLhvQ/qPuRBiDZHF2pFN16flDZXgrq8ll3yh06AemxqKmUOvI2lzOejZ TMk8nbw64FlhnuxkOztyCuIqty2fB6UiMe3XKW8wln0u262veSPEBsvwoz7OuWA0K5nI /qAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=naIc7+UU99psMTXJQz+RJiQhcwnl+UPm5H2DCEC5u+I=; b=RMLnTwMUQurEelF4N3ceo/zUchGNdLRUs1rG6Jp/Ym9ZJnCyOWfwJ8/f12wmUTyhB8 lFubVNo8oGzI+mLq6RGVRhePwdRm0+Te+9jPIZ8H9YmvkD8YbkDYxfUfpYYDm85dBI5f 8h9NJBgsAiCH6BoRoRvzf7bMcOjHLZjy/e6hSfxn+DTQtMBsm+16LnDdAtpf1PWcaWjg WtIzDGOO5+jVRqr+/3CYI6rUZE28R5NluOZLRUBo3hNUiGyERx5AxnX+UlpNyU/ouCrO afs0L0z4hztSykcqtPtmQmT+fs/uJGq93JN9cjGNU8SHAcIXYECu+J7pqJViCfQ+oNFH ke2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dhksynNB; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p67-v6si4950432pfg.295.2018.08.03.04.44.02; Fri, 03 Aug 2018 04:44:17 -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; dkim=pass header.i=@linaro.org header.s=google header.b=dhksynNB; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728556AbeHCNio (ORCPT + 99 others); Fri, 3 Aug 2018 09:38:44 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:36341 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727473AbeHCNio (ORCPT ); Fri, 3 Aug 2018 09:38:44 -0400 Received: by mail-it0-f68.google.com with SMTP id p81-v6so7964237itp.1 for ; Fri, 03 Aug 2018 04:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=naIc7+UU99psMTXJQz+RJiQhcwnl+UPm5H2DCEC5u+I=; b=dhksynNBdoXB6+JzQqCdW/AxmvFqdIjUmRrdoHaFDA7ModJ6EYJ0qGbwFLmqNKc4/f 2RAGSnqSylayRSJN9W9gWtzJN5ksasLgyWeiGZjwUrFy57XzaqzCe7tRrvrhml8GF6wI Vjimho4R/Qgu+q8Fa/rN9zzAvM/L7NNrzjfQ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=naIc7+UU99psMTXJQz+RJiQhcwnl+UPm5H2DCEC5u+I=; b=g983fbsNj00crJu8xPTEn1H4cwPB6bwKpatpjR6/GPmt/JVgUAeJulOdXT3FHPFRJW KEi8nhNycuVebPl1lerlRK7/XiHaJpO8o4clKZw9u9oopgIobVle1xjejTKOnyCga0PQ w1P78akzaibpY6RknKQCuyiqXOiT7zCix4zgKmehCYLPf9Y3kdIrqYLFImzYX0oo7kIx F4j2g9UcpUKFcciXuHkx+uMeY188xXMU13g3vRQICrjwOLiVICsQEnOfMFWqdrUp2KE6 4+D2ebk3EJflCF58L+1mQJUuiNPg9l5pWXpcL4jPcxebfMiyifH/Lvf8xLwvbztfeGZl GDag== X-Gm-Message-State: AOUpUlECO3FollQe/JDE0ocacxe3aANpbsMoHrNq3ykrtRRYe9OE7uyx cfrVAh1ofDGfg+ZQiHhBfhLbXGwoI7D0GwNdT6QBOQ== X-Received: by 2002:a24:69cb:: with SMTP id e194-v6mr6369978itc.102.1533296567256; Fri, 03 Aug 2018 04:42:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:2b03:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 04:42:46 -0700 (PDT) In-Reply-To: <1683770.JmsJDzJTZp@aspire.rjw.lan> References: <20180620172226.15012-1-ulf.hansson@linaro.org> <20180620172226.15012-9-ulf.hansson@linaro.org> <1683770.JmsJDzJTZp@aspire.rjw.lan> From: Ulf Hansson Date: Fri, 3 Aug 2018 13:42:46 +0200 Message-ID: Subject: Re: [PATCH v8 08/26] PM / Domains: Extend genpd CPU governor to cope with QoS constraints To: "Rafael J. Wysocki" Cc: Sudeep Holla , Lorenzo Pieralisi , Mark Rutland , Linux PM , Kevin Hilman , Lina Iyer , Lina Iyer , Rob Herring , Daniel Lezcano , Thomas Gleixner , Vincent Guittot , Stephen Boyd , Juri Lelli , Geert Uytterhoeven , Linux ARM , linux-arm-msm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19 July 2018 at 12:35, Rafael J. Wysocki wrote: > On Wednesday, June 20, 2018 7:22:08 PM CEST Ulf Hansson wrote: >> CPU devices and other regular devices may share the same PM domain and may >> also be hierarchically related via subdomains. In either case, all devices >> including CPUs, may be attached to a PM domain managed by genpd, that has >> an idle state with an enter/exit latency. >> >> Let's take these latencies into account in the state selection process by >> genpd's governor for CPUs. This means the governor, pm_domain_cpu_gov, >> becomes extended to satisfy both a state's residency and a potential dev PM >> QoS constraint. >> >> Cc: Lina Iyer >> Co-developed-by: Lina Iyer >> Signed-off-by: Ulf Hansson >> --- >> drivers/base/power/domain_governor.c | 15 +++++++++++---- >> include/linux/pm_domain.h | 1 + >> 2 files changed, 12 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/base/power/domain_governor.c b/drivers/base/power/domain_governor.c >> index 1aad55719537..03d4e9454ce9 100644 >> --- a/drivers/base/power/domain_governor.c >> +++ b/drivers/base/power/domain_governor.c >> @@ -214,8 +214,10 @@ static bool default_power_down_ok(struct dev_pm_domain *pd) >> struct generic_pm_domain *genpd = pd_to_genpd(pd); >> struct gpd_link *link; >> >> - if (!genpd->max_off_time_changed) >> + if (!genpd->max_off_time_changed) { >> + genpd->state_idx = genpd->cached_power_down_state_idx; >> return genpd->cached_power_down_ok; >> + } >> >> /* >> * We have to invalidate the cached results for the masters, so >> @@ -240,6 +242,7 @@ static bool default_power_down_ok(struct dev_pm_domain *pd) >> genpd->state_idx--; >> } >> >> + genpd->cached_power_down_state_idx = genpd->state_idx; >> return genpd->cached_power_down_ok; >> } >> >> @@ -255,6 +258,10 @@ static bool cpu_power_down_ok(struct dev_pm_domain *pd) >> s64 idle_duration_ns; >> int cpu, i; >> >> + /* Validate dev PM QoS constraints. */ >> + if (!default_power_down_ok(pd)) >> + return false; >> + >> if (!(genpd->flags & GENPD_FLAG_CPU_DOMAIN)) >> return true; >> >> @@ -276,9 +283,9 @@ static bool cpu_power_down_ok(struct dev_pm_domain *pd) >> /* >> * Find the deepest idle state that has its residency value satisfied >> * and by also taking into account the power off latency for the state. >> - * Start at the deepest supported state. >> + * Start at the state picked by the dev PM QoS constraint validation. >> */ >> - i = genpd->state_count - 1; >> + i = genpd->state_idx; >> do { >> if (!genpd->states[i].residency_ns) >> break; >> @@ -312,6 +319,6 @@ struct dev_power_governor pm_domain_always_on_gov = { >> }; >> >> struct dev_power_governor pm_domain_cpu_gov = { >> - .suspend_ok = NULL, >> + .suspend_ok = default_suspend_ok, >> .power_down_ok = cpu_power_down_ok, >> }; >> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h >> index 97901c833108..dbc69721cad8 100644 >> --- a/include/linux/pm_domain.h >> +++ b/include/linux/pm_domain.h >> @@ -81,6 +81,7 @@ struct generic_pm_domain { >> s64 max_off_time_ns; /* Maximum allowed "suspended" time. */ >> bool max_off_time_changed; >> bool cached_power_down_ok; >> + bool cached_power_down_state_idx; >> int (*attach_dev)(struct generic_pm_domain *domain, >> struct device *dev); >> void (*detach_dev)(struct generic_pm_domain *domain, >> > > I don't see much value in splitting this patch off [07/26] and it actually > confused me, so it may as well confuse someone else. > The idea was to let people, explicitly, comment on the whether dev PM Qos constraints should be considered by the governor. However, I get your point, let's combine them! Kind regards Uffe