From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42E2C3B14DE for ; Mon, 10 Aug 2026 09:54:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786355658; cv=none; b=olRkoRFJAOU0Q5lDfT7fmHXK6LMkwsPFYHzHqjNuXfcqkAccCgwMuicJ4Xc+fZqPgErpDPFgxmXKoVw6ug5XhOueGK5/4Yfl90+bN3Fz8u2rcFgCi1AuXTSKOAnHXU84VhfpPiDRbF+d8x/KRDlQ8OlEMuWSAWfeZUPDTCeCiXQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786355658; c=relaxed/simple; bh=cKOor2fNTKRGf+jPzcfQ4SSvtrlkntAd67pXDZl2Ock=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NwB6oB9uUqgiIuQDaT5pRwZpWpjPlQxHtCO+BqhzUr4MLmEhqHgstG/ZhsnWG44ysCjsSt6I+UM5qjxFi9B2RjlBWcWeVAnUo2CFlIJ2yVvMLtW4nuQP1/ECmlqoMQwPzvf4wxh81ofPn3mTeuvHqOGKYxZyO0PAqEV/r0gBIgY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=N8vMUjRp; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=bo3UHqDE; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="N8vMUjRp"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="bo3UHqDE" Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67A9RuwM1727534 for ; Mon, 10 Aug 2026 09:54:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= E1yaupPD5ZYBbc+QOdbQUWR4btXhlOZTk84i+SjbBKU=; b=N8vMUjRpLTKymt1J MV99G/o+nFcMOhEUVjpTJyJYM2gjruCUIPdmZ6ubfR1pU29GJn78M2NjqHnLQXng luKXhXxWGQcYXkbSeRXnOeQLHGmpux5Bv9+llHS2fdprQ9kdzKfFezeS+UbotdZI zO3Bz+lnHMtkjiFEmt6UGZqXJ2qz4unGTiKWv/8plzV+BOGaruoKErP597SdbKMu wWBXyWhzUgvS5MBAMK+f1LBDSVmUVM/vOtRJ+lfIJhxB0I28TFoSJ4kfgKxdwYZ2 PWjR9sr3x5fr78pKrc7fOEsBHgvtH6b1jgIgeTlfUT66mhpCDis/ybhjuWPWOWVG O191fA== Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fy8v3rvc6-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 10 Aug 2026 09:54:16 +0000 (GMT) Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-caf5fa127d4so3143357a12.0 for ; Mon, 10 Aug 2026 02:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1786355656; x=1786960456; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=E1yaupPD5ZYBbc+QOdbQUWR4btXhlOZTk84i+SjbBKU=; b=bo3UHqDEozuCkfNBzcDoPc8IgeU0RjbSHu3RQzK+kn29vB0gjDRZ8HNTJJ2+k3IVST zy1nEemjmbcZHmY2xS02C/X6j0RlHZFboJMmf66lp3kCcLwZDj/yRdRNTQuE3++wRyzo aQe86mqwQialF7b3iUmygEZ0FUrRNwVLkEsLesShgW/74k/d6fIqskcOWOFzvLRXd3rk dMHjqhzdGQz+yNVmXfsR60XNE1j0Vfo1+SeIjnQy7KAyaC5gt+VBcjDo2SCaywbt/olk oWOh6Cd0/KVVxXXtXybHAke1Ip87Y3cgqdY3zYO0wEd+xdIIjLvkLytHImN7SMUhXSz5 Jctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786355656; x=1786960456; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=E1yaupPD5ZYBbc+QOdbQUWR4btXhlOZTk84i+SjbBKU=; b=QaWZApHJ34uOcb8yA8i94YyrmB1Hvni4CJzPj9Mx9x5lzgF8bhlhjidLF9tc2G2Z49 I0htY3qxx8yEadkZwk2QCuse5tHi2O0xYVewBzlM9lAktUHfhtZyFx+Vtm9e1nkce78y X/zoafW4DGdEykbtnKNvAOC001IBiXiURDRj00aNyLmtBv4G6vNlX7mC6iDQxKZ6mTTA FEJRjFgXPsnF7IjiI7thsCFZljoccS7KlfdNAX7sszFz9+ubXdKWiD6kmID3jwkPI6KK jFwkb33+nWKJaBxpzalsKIvHOSYVHVTJlS6JwEkTBlJt6jK0bwc1D1K0cXNiCfmnTJEs 1nNA== X-Gm-Message-State: AOJu0Ywv/Lviek0+zzsmfbsO9MM00W8XhUCGRa9xRjJOv8ye2oqCKsIf MMCvdwR51SQEv51Rcj4vGS/xxKFiCbpOrIbHjiOpiwabPDVWMdbJdeUH4QSR1OgRBabVAExfPQp T4cHlTsDFHTBfIDH6zurUbszQNeyZWNQI9or0DMpfW82ulIW5qQ+tm8EZqUwTJrtCQbM= X-Gm-Gg: AR+sD107R7oIKG41oBQTMKnuGsnZh+hbSx93VBt5HRVdsNqT4AJ24f/IG+4oSWJw4UU yxlllnoRYkcLNEHuUUb84Prq/xIXJtCjK3/f7+vbvp25d4hg/uuZtVK7/yka1tMZv7kzV04ug8y 2w+0VupCPSQMyowbwgA++Xv5Zj1hn913hFSNoxRbZFCqzL8OWzT2eQ5QiIQL4cv/E7KYJVfHyeZ x5IkZJprJzbZtIOTKfQ8fgEJJKqew4IRz/hYlXyVUjW8oTjYIXBG41CnY/cfyjT0KCh/XhWtLb3 XffgV8AcywOeRsQBEjA/bTgDrwZZXEid15neDHEgdCQpG4yO0ADyk019N6xkRGWIvTxP3W2vg0k xTi7tS2PSaLp1uHwYcUH1tU4sUPFkWWlyyH1rgokLfPmCc5B71qGsiCMnvh//NkxBge73H/s= X-Received: by 2002:a05:6a00:2187:b0:843:49f0:f5a0 with SMTP id d2e1a72fcca58-84f5e0c4b15mr23847262b3a.32.1786355655677; Mon, 10 Aug 2026 02:54:15 -0700 (PDT) X-Received: by 2002:a05:6a00:2187:b0:843:49f0:f5a0 with SMTP id d2e1a72fcca58-84f5e0c4b15mr23847227b3a.32.1786355655243; Mon, 10 Aug 2026 02:54:15 -0700 (PDT) Received: from [10.133.33.19] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84f5a596a10sm3708327b3a.60.2026.08.10.02.54.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2026 02:54:14 -0700 (PDT) Message-ID: <3a20b69e-b072-4723-925f-514d8162e259@oss.qualcomm.com> Date: Mon, 10 Aug 2026 17:54:09 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled To: Sibi Sankar , rafael@kernel.org, viresh.kumar@linaro.org, mingo@redhat.com, peterz@infradead.org, linux-arm-msm@vger.kernel.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com Cc: linux-kernel@vger.kernel.org, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-pm@vger.kernel.org, zhongqiu.han@oss.qualcomm.com References: <20260806044230.909961-1-sibi.sankar@oss.qualcomm.com> <20260806044230.909961-2-sibi.sankar@oss.qualcomm.com> <54e74486-12f2-4b09-916a-1a8806871b6c@oss.qualcomm.com> <18d763f0-d817-45d3-8c79-10639d5a5e47@oss.qualcomm.com> Content-Language: en-US From: Zhongqiu Han In-Reply-To: <18d763f0-d817-45d3-8c79-10639d5a5e47@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: x3RhG9GA0jmJZxghlCgsUvz_NJalHr6D X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEwMDA4NCBTYWx0ZWRfXyA/dM4ZoSoOr hEccV7rxsm7QBEH6brbVg6cJW8QuLye3I43Km7XtiEoztkNQ8IhdCMEzq+rKuX2f2VZZ7Uf5Oyk SvooWkXSCbs2Txh/L1HJweEEaqD6vMxpQvElOeAmN1I3ya6wGMjsL3QeWMx80NeXGTfKpipUhvQ GcGcRe+R3mW8Nzma295seJPv3p0SgGIG/ZE2z9+Yk4liwbZGeBEUP5m6OYMCdid6vJdNv1YnK+J 5FavABrY5gNXJgkFUSlLb4Uy/LZbvN2ak2+Pc/AG0ZvXdrseXbVqLWLeLSfj2JHwsDyNiAD2Oz6 rESmg6UGrIhzHkXQvdZAOKk2g8U8dpOk/vosRksNVatEXre37jgrz5RHDOSziXaYlM8p5qtxCie w0+FMl6oSDF+rwyg6t79HsyFizbe458JF1fCTKWYrJTjAa6YPYmDqwf/yI7TJtiHFU+sW+yMOO6 g/BqtsShtCeIchbSj7w== X-Proofpoint-Spam-Info: AW1haW4tMjYwODEwMDA4NCBTYWx0ZWRfX0fJr7iD2O6y6 OtrtM8zQ9t97HfJITgD9XO/7SGnYUOLdmGazzvxTpuYBHlDIjDNCcrVIo2L80vjLDoaOzsuQrp7 kLXAMc1thrbO52qeJCNXMcK9wJo0E4c= X-Proofpoint-GUID: x3RhG9GA0jmJZxghlCgsUvz_NJalHr6D X-Authority-Analysis: v=2.4 cv=c+mbhx9l c=1 sm=1 tr=0 ts=6a799fc8 cx=c_pps a=oF/VQ+ItUULfLr/lQ2/icg==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=EUspDBNiAAAA:8 a=oDw6gA2hALo5y0joJwwA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=3WC7DwWrALyhR5TkjVHa:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-10_02,2026-08-07_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 clxscore=1015 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608100084 On 8/7/2026 10:23 PM, Sibi Sankar wrote: > > On 8/6/2026 4:52 PM, Zhongqiu Han wrote: >> Hi Sibi and Ananthu, >> >> On 8/6/2026 12:42 PM, Sibi Sankar wrote: >>> From: Ananthu C V >>> >>> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly >>> if max boost is known") guarded cpuinfo max updates to only allow >>> increases, preserving values set directly by drivers above the freq >>> table maximum. This prevents cpuinfo max from decreasing on boost >>> disable, leaving policy max pinned at the boost ceiling. >>> >>> Remove the guard so cpuinfo max is always derived from the frequency >>> table scan. Drivers that correctly flag boost entries are unaffected >>> since the scan already excludes them when boost is off. >>> >>> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if >>> max boost is known") >>> Signed-off-by: Ananthu C V >>> Signed-off-by: Sibi Sankar >>> --- >>>   drivers/cpufreq/freq_table.c | 7 +------ >>>   1 file changed, 1 insertion(+), 6 deletions(-) >>> >>> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c >>> index ea994647abc8..791118466ca4 100644 >>> --- a/drivers/cpufreq/freq_table.c >>> +++ b/drivers/cpufreq/freq_table.c >>> @@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct >>> cpufreq_policy *policy) >>>       } >>>         policy->cpuinfo.min_freq = min_freq; >>> -    /* >>> -     * If the driver has set its own cpuinfo.max_freq above >>> max_freq, leave >>> -     * it as is. >>> -     */ >>> -    if (policy->cpuinfo.max_freq < max_freq) >>> -        policy->cpuinfo.max_freq = max_freq; >> >> As I understand it, the guard added by commit 538b0188da46 is >> intended for drivers (e.g. acpi-cpufreq and AMD) that may set >> cpuinfo.max_freq above the maximum frequency in the frequency table. >> Removing it may cause those drivers to lose their boost maximum >> frequency. > > Yup, we did mention the same in the cover letter. > >> >> The regression should instead be related to commit db80ad776cd2 >> ("cpufreq: Remove driver default policy->min/max init"), which removed >> the "policy->max = max_freq" initialization that previously allowed >> policy->max to track the result of the boost-aware frequency scan. >> >> Please feel free to let me know what you think. Thanks >> > > The commit db80ad776cd2 is unrelated. The problem comes from the > fact that policy_set_boost uses policy->cpuinfo.max_freq in it's > freq_qos_update_request. If we modify it to use a frequency that > adheres to the boost and per-policy boost flag instead might be > the right thing to do here. > Hi Sibi, Please let me know if you see any issues with the analysis below: [Background] Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known") made `cpuinfo.max_freq` hold the CPU's real physical maximum independently of the frequency table — for drivers whose max boost frequency is not in the table and added the if (cpuinfo.max_freq < max_freq) guard so it can only be raised, never lowered. [Root cause] Commit 6e39ba4e5a82 ("cpufreq: Add boost_freq_req QoS request") changed the value fed to the boost QoS request from the boost-aware policy->max computed by each driver's .set_boost() to cpuinfo.max_freq, overloading one field with two conflicting roles: a boost ceiling that must track boost state in both directions, and a constant physical maximum. Only cppc_cpufreq_set_boost() and amd_pstate_cpu_boost_update() were taught to update it in both directions; cpufreq_boost_set_sw() was missed — it can only do so indirectly via cpufreq_frequency_table_cpuinfo(), where the 538b0188da46 guard forbids a decrease. So on boost-disable boost_freq_req can't be lowered and policy->max stays pinned at the boost frequency. [Trigger] Before Commit db80ad776cd2 ("cpufreq: Remove driver default policy->min max init") removed policy->max = max_freq, that write still pushed policy->max down and masked the issue. Removing that write just made it reproducible. [Conclusion] Removing the Commit 538b0188da46 guard maybe therefore not the right fix, the drivers that rely on it would lose their real boost maximum at init. The fix should belong in policy_set_boost() / cpufreq_boost_set_sw(): source boost_freq_req from the boost-aware table maximum instead of the sticky cpuinfo.max_freq. `Fixes:` should point at 6e39ba4e5a82. >> >>> +    policy->cpuinfo.max_freq = max_freq; >>>         if (min_freq == ~0) >>>           return -EINVAL; >> >> -- Thx and BRs, Zhongqiu Han