Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp641181pxu; Fri, 23 Oct 2020 09:35:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyigJezwpguW5qyhpClSbHAfOAFx99Gnl9yq7U7kEmLI08h+WSa2R/0fJKcDHX6OOMrvhJN X-Received: by 2002:a17:906:95c5:: with SMTP id n5mr2929758ejy.111.1603470955381; Fri, 23 Oct 2020 09:35:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603470955; cv=none; d=google.com; s=arc-20160816; b=KMSp+3iyxHQxg7rnOdNnSXVJqiftp8uMlUPAWsY42fz0vXM3Msgcn9AJNwkJpNOsW3 P8yn9u5apDpWlDMxWWTFZZIv1X+Tsy4cLVevFGLzm2FUwMrDIQQ+RiXtsHCpHkD7n9+F AYCTHSxw2752pmJEZ2sL2XjxwcXRKs0Yt8mMksA3ruVIIwvUO3lwiD0pS5dBiKpRFWjR tbEOX9r4oDDD9u89H88fg0F4T+gaLShvFK8Tp18HvKZMsjGMrORkVgk47UBuHf/Isyb2 gdDNB1hqzQboqq0L48VK9uiE0SCkQhrdneahPpK8vZqhwwfexrKOcW6Ne4zVq8snPxkD 8k1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=OeW6OcqUy4EA4quDH5kQC8VWz1MzW8X2QVleBmN8UrI=; b=zg7vgaLkJndD3+XRRIEfxCiTNAZpS8mHswRkeCb7xVikXv/SGP8vatNMwCzJSvYFZ8 2dXYVU2r5pp1x1h8tUmHkqi/ZHeQ8HbrhazhKeUxAB5ZXM+HqeI7tuIojLmGdUYDfm3l oF9aqWI5AcrRFom8mWe2hq8DrE1FFCbkqZPvWxoRwWz7pmiOpNojLOpwB795DhE7k3wE ZovjBbkcR6vGoQwIsllFe3AIwgDkZC/Lep8/W1gYDoaE45/5lFg3m24X+UEuDc2sAHKQ P4k5LTfxs/CnBP5fTbAxbIGSem/L4yTjBp+0wSC7AAq91AhoCZ8+jehM3duYCgobfgRl ubBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p89si1044417edd.109.2020.10.23.09.35.32; Fri, 23 Oct 2020 09:35:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750913AbgJWPgu (ORCPT + 99 others); Fri, 23 Oct 2020 11:36:50 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:52656 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750889AbgJWPgt (ORCPT ); Fri, 23 Oct 2020 11:36:49 -0400 Received: from 89-64-88-190.dynamic.chello.pl (89.64.88.190) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.491) id d99488cc2732ed08; Fri, 23 Oct 2020 17:36:47 +0200 From: "Rafael J. Wysocki" To: Linux PM , Viresh Kumar Cc: LKML , Srinivas Pandruvada , Zhang Rui Subject: [PATCH v2 1/4] cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS driver flag Date: Fri, 23 Oct 2020 17:35:19 +0200 Message-ID: <1673796.UrKzctInAk@kreacher> In-Reply-To: <2183878.gTFULuzKx9@kreacher> References: <2183878.gTFULuzKx9@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki Generally, a cpufreq driver may need to update some internal upper and lower frequency boundaries on policy max and min changes, respectively, but currently this does not work if the target frequency does not change along with the policy limit. Namely, if the target frequency does not change along with the policy min or max, the "target_freq == policy->cur" check in __cpufreq_driver_target() prevents driver callbacks from being invoked and they do not even have a chance to update the corresponding internal boundary. This particularly affects the "powersave" and "performance" governors that always set the target frequency to one of the policy limits and it never changes when the other limit is updated. To allow cpufreq the drivers needing to update internal frequency boundaries on policy limits changes to avoid this issue, introduce a new driver flag, CPUFREQ_NEED_UPDATE_LIMITS, that (when set) will neutralize the check mentioned above. Signed-off-by: Rafael J. Wysocki --- New patch in v2. --- drivers/cpufreq/cpufreq.c | 3 ++- include/linux/cpufreq.h | 10 +++++++++- 2 files changed, 11 insertions(+), 2 deletions(-) Index: linux-pm/include/linux/cpufreq.h =================================================================== --- linux-pm.orig/include/linux/cpufreq.h +++ linux-pm/include/linux/cpufreq.h @@ -297,7 +297,7 @@ __ATTR(_name, 0644, show_##_name, store_ struct cpufreq_driver { char name[CPUFREQ_NAME_LEN]; - u8 flags; + u16 flags; void *driver_data; /* needed by all drivers */ @@ -417,6 +417,14 @@ struct cpufreq_driver { */ #define CPUFREQ_IS_COOLING_DEV BIT(7) +/* + * Set by drivers that need to update internale upper and lower boundaries along + * with the target frequency and so the core and governors should also invoke + * the diver if the target frequency does not change, but the policy min or max + * may have changed. + */ +#define CPUFREQ_NEED_UPDATE_LIMITS BIT(8) + int cpufreq_register_driver(struct cpufreq_driver *driver_data); int cpufreq_unregister_driver(struct cpufreq_driver *driver_data); Index: linux-pm/drivers/cpufreq/cpufreq.c =================================================================== --- linux-pm.orig/drivers/cpufreq/cpufreq.c +++ linux-pm/drivers/cpufreq/cpufreq.c @@ -2191,7 +2191,8 @@ int __cpufreq_driver_target(struct cpufr * exactly same freq is called again and so we can save on few function * calls. */ - if (target_freq == policy->cur) + if (target_freq == policy->cur && + !(cpufreq_driver->flags & CPUFREQ_NEED_UPDATE_LIMITS)) return 0; if (cpufreq_driver->target)