Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5733984pxu; Thu, 22 Oct 2020 09:41:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyhUu2qX9UGnrTJjQWOfBh3CKbOYjZmSPsvjV9B/y57BaLnBAskNetrJKgOopTK6l2xxYA X-Received: by 2002:a05:6402:2292:: with SMTP id cw18mr3180079edb.112.1603384902890; Thu, 22 Oct 2020 09:41:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603384902; cv=none; d=google.com; s=arc-20160816; b=O41MVNPFD9MZ6Xmt96VnlDAP85ZCqHAXGdqb9sBbCJzGQ4T9422G9OqsQJV3sN/zec 4LJnoErSrkXipznxYnbmu0SmQ/KNkkSuPHtfb69qxbKSoohXexccYcPw6JiqddSuNo5E gmssU7okbkek0io5y+oFqQFh6fMYbw5/+/Wk+RKMo9zMh1NDLBuhdh7018jhHtV8klct nE1+Cut8ef0shQg9T/Kq7qMCQi0KxCHcMlJ+MAZU/VXSB5tEtqT1NcG7DuryKlH1XGlc 9ktFE+bU2XGph4fcq+hqX7NUz+WdSqPyI5rFkVnOoWKkSIVd1TYTHFngVLc545pqbhU3 DrTw== 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 :message-id:date:subject:cc:to:from; bh=fLhdzjgqqfl02jWHe8W3jS4G1iSLP7png4wKptE3CJ8=; b=rK8dEwuwG+fm/ictkEJtF6+QPhJ3VnjCmXrj0h9O5gZdg8AUN+//13c07piN9xzehK H4WFbJb2EKdih84MO2d99H3YsXAcq7rapaSO2mB1Npj/f1ExAw8JMBwKiQwilcw9zNZl +HgYoS/SaK+EgbidOUfGwpCIOn7Xvte+ubL3lERVQlrmfNMC+OBGibwDoEkOe6Hv2gJ+ 8QH8HqIkffYgALJ71eMvp9X1FXSZx6TMALipKjsMsw3un0dKM47nW/BP9d2r9UHWL93P D0ktXqeZw4NuRPnrJXt1mjDMNQa0Oi5qS1Ih0lW3pVlKs5279uJ9aTO39/AMil0AsRZP F9Rw== 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 g1si1640905edn.177.2020.10.22.09.41.20; Thu, 22 Oct 2020 09:41:42 -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 S2897724AbgJVL57 (ORCPT + 99 others); Thu, 22 Oct 2020 07:57:59 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:49644 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2897699AbgJVL56 (ORCPT ); Thu, 22 Oct 2020 07:57:58 -0400 Received: from 89-64-87-167.dynamic.chello.pl (89.64.87.167) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.491) id c2ae5f4a621278e0; Thu, 22 Oct 2020 13:57:55 +0200 From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Viresh Kumar , Srinivas Pandruvada , Zhang Rui Subject: [PATCH 0/2] cpufreq: intel_pstate: Avoid missing HWP max limit updates with powersave governor Date: Thu, 22 Oct 2020 13:55:13 +0200 Message-ID: <1666263.spd1I39WAV@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 Hi All, There is a problem in intel_pstate that if it works in the passive mode with HWP enabled and the "powersave" governor is used on top of it, then changing the policy max frequency doesn't cause the HWP max limit to be updated which is quite confusing. That happens because of two checks, one in the cpufreq core and one in the driver itself, that are there to avoid unnecessary HW/FW updates when the current frequency doesn't change. Of course, that is the case when the policy max limit changes under the "powersave" governor (which sets the current frequency to the policy min limit), but in that particular case, the checks turn out to be harmful. This is dealt with by the first patch. The second one is an optimization that can be done right away on top of the first one. Thanks!