Received-SPF: pass (google.com: domain of linux-kernel+bounces-193551-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID:
 <TYCP286MB248669BCAD7A7E54C5071EF9B1F22@TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM>
Date: Wed, 29 May 2024 14:53:41 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set
 target
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: rafael@kernel.org, linux-pm@vger.kernel.org,
 linux-kernel@vger.kernel.org, Riwen Lu <luriwen@kylinos.cn>
References: <TYCP286MB24861BA890594C119892FB3DB1F22@TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM>
 <20240529053652.pzcjoyor7i23qc4i@vireshk-i7>
Content-Language: en-US
From: Riwen Lu <luriwen@hotmail.com>
In-Reply-To: <20240529053652.pzcjoyor7i23qc4i@vireshk-i7>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: TYCP286MB2486:EE_|OS9P286MB4255:EE_
X-MS-Office365-Filtering-Correlation-Id: 9bfb21a3-2621-4411-3238-08dc7fac26b8
X-Microsoft-Antispam: BCL:0;ARA:14566002|461199019|440099019|3412199016;
X-Microsoft-Antispam-Message-Info:
	3eSCsCaDahFxJKYelFD9FK/Btqo9zE0oh4X8mZO8Qw+eQ2JtqaY2IAOCd2rQUr/UYMlmCpwRTxEXhtYUEz1Kuyp2Pe8QYMc0jF7UOrR5SMRmOnlHdHjxYG/S9gW7qfKchQF7HxzcZwGwITWkYhMv7EwJUZU+hAXnLOT6DauNcP9iLbJjRe6t/S5a/TmG9fzNZ6+u4LsJF3aRXiS/gE++5DVJHWezQYgFLxi34qnt7nICOub3VcWKFd7HzgrFnFMN3TvOVOVfXDxdSfQfd13x1jwum+yl/7b7fdI9LQ/769rDb/BdWqXL/f7vmvx552t66pe/x0FmGNVyvbc8P1Cfho2qnIJE8NYerkMmIaco2xOhDyNsIBsFhlXX+s59tSB5Ur9UOLxnPkSKlVv8jYgyrIet4STPWdtHcae3hWKXZMdvPWBdofkahgC99kVvqEKWGTc6INxo4s7eLCmDl9Mh3tv+71S58Wn5psvsK0f16MqV6/s/L/6hLZK1ZdxeGoWB0HnuQ4swxP825O5dJu+69uzfUujdrJ/+kikDU/GKrVlkoDryRjQopBg3Wx+D8Ho1
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?REVlTjhybDM3VCtxcWNMbWp1TUR2eitteWpOWStEQWt2ZkNMMFlrQy9hZWdx?=
 =?utf-8?B?dUJWQXB4ano4eFhTWDFoR1QwaEFNNWVEU0hSR1N6a2gwalVidnlQM0YzSEZW?=
 =?utf-8?B?MEZBSWlzSXowZTgrMlNHd3BSRVBMWm10eElqQW5LWlhydkJtbmRSSm1KQk5n?=
 =?utf-8?B?RmgyTkgzb3d6eXQ3c2xwVjh3NCtzaHU0ZDZyYmJpYlZiMHkwUC9MWDZEM1NB?=
 =?utf-8?B?R1QzYnlBbFZIa0I2L01hd1NhaXRZNXBTNzM0Z040Tzc3cExjSWg1RmxWdjl5?=
 =?utf-8?B?dm1sRnBmWmxKZDZXNWJkb0xoVmh3KzZGK013cVp6OU9hbUdPM214V0tMTDVs?=
 =?utf-8?B?NDk3YWVUWExFYUVnSEVTSlBtUklEZjVBT2VKT1g2WnRiYU1WMGFseGZpM2hi?=
 =?utf-8?B?TkRsSmdFbXc1QW9BOTFRNVpUSE9NdklqUGg3TnI2UGl3eHR4N2Nhb1BnbVhl?=
 =?utf-8?B?eW40em4veUpHS0hPcENiR0ozY0U2UTdHTzAzUmV1NnlsODJCRUhkdWo5a1dK?=
 =?utf-8?B?dmFlR214ejZ0N0h0WU9YWDNIYVdTQnN3VlM2eEhoVmFQcE9vRVJuN3RTTktz?=
 =?utf-8?B?T0xFbHBtSUNvTzZwelNrOFBCUldQblQzenFaKzBwYjdRUWNCY3lRcVFVMG9J?=
 =?utf-8?B?Yk9nRmNWTlM2SGRIY0Y3ZEpJdCtyUGtVRWdmclVlRDV2L3lvdG10SVhmRyt5?=
 =?utf-8?B?M1lIU3JYekNpc3JUNERtcHh1b3dDYk1rRkdPWkxlZUFRZFJJZ2h6RnRNRXFR?=
 =?utf-8?B?aFdPRWgxUW9aL3ZEalFsNHAyT2ZWZzJWWGdneFZINHJ4aHIrWjFFeGxYM3I1?=
 =?utf-8?B?cmVwaFRXWGZ5STB0cVYwcTFSa2lTZm5mZTluUmJtRUZ6RDdCL2RpRFhxV0Vn?=
 =?utf-8?B?ZzI3aFdpdHFvdHJiajRIRnlmZUFSZC84V1hSS0JjdVZuUlJObEFJRnhmQzhz?=
 =?utf-8?B?Q201Y3NJK251RHFzeDVjV1dRcVNwOC95Vy9LUld4UTJZWGF3M1p2QUpWVmps?=
 =?utf-8?B?dGdvZVBRdE1PWmtYZkJsTE9sWDUyVlA5aU5IQnJ1ay9iK2tMcjgrR25zSk1W?=
 =?utf-8?B?T3FvY2Y4SWhSK0ZXOENsWXFIMDFiem9zc1VENlhYNXNValBBbTlKYmlmbzhB?=
 =?utf-8?B?c0JTU09wSHN2V0ZrQWpod0ozaHp1TFg4MDV5TFQ1NXppNG1BTFJWV2lQZ1Fj?=
 =?utf-8?B?Rmw2amt2VU5mckxMazJ0dTV6VzljaVhxR3I0elluV0ZxZXV2QnhYT0EzS0Zl?=
 =?utf-8?B?aHFtRkdwSWFKQ1gyN0JqZGRWZENhblF5YS8zZTB0akdCbFJSREJ6Sk45M2FJ?=
 =?utf-8?B?czdDb3dwMnVRNEJFeDRGWkdPRnprSXFydVVlUnZSRXJxN2JrRGFNUW1vRXdH?=
 =?utf-8?B?STY0RGZiYjJhTGhBcWh4MkhnTktWaExVWFhNOWNTbWtseWFnVVA4MDhRRElz?=
 =?utf-8?B?aW9XL2FUQnllVjh6V2VUR0NpSi9OVHZJZ2R4Y0swOG93VkFoNTdhalJBenQ4?=
 =?utf-8?B?U2lOcmxzcEswZ0lxbzBvL3ZrM2xTNmlNNFpVdm9LSVNwc21CdWJOY2dLRXZC?=
 =?utf-8?B?Y3U4Qno3ZlM1ck1YQmNHclJuNGNSNi80Tm1UczZ1MHhjRjh3VGF5YiszZlJp?=
 =?utf-8?Q?viBj2FkkJbu83Wl3RbNk/IqOAmjv0K8msPqxFkgY3oM0=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-05f45.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bfb21a3-2621-4411-3238-08dc7fac26b8
X-MS-Exchange-CrossTenant-AuthSource: TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2024 06:54:14.2828
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9P286MB4255

在 2024/5/29 13:36, Viresh Kumar 写道:
> On 29-05-24, 11:22, Riwen Lu wrote:
>> From: Riwen Lu <luriwen@kylinos.cn>
>>
>> There is a case that desired_perf is exactly the same with the old perf,
>> but the actual current freq is not. Add a judgment condition to return
>> only when the three values are exactly the same.
>>
>> This happened in S3 while the cpufreq governor is set to powersave.
>> During resume process, the CPU frequency is adjusted to the highest
>> perf. For the booting CPU, there's a warning that "CPU frequency out of
>> sync:", because the policy->cur is the lowest_perf while the actual
>> current frequency is the highest_perf that obtained via
>> cppc_cpufreq_get_rate(), then set policy->cur to highest_perf. The
>> governor->limits() intent to configure the CPU frequency to lowest_perf
>> and the governor->target() returned because the desired_perf is equal to
>> cpu->perf_ctrls.desired_perf leaving the actual current frequency and
>> policy->cur are remain the highest_perf. Add a judgement that if
>> policy->cur is the same with desired_perf to decide whther to return.
>>
>> Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
>>
>> ---
>> v1 -> v2:
>>   - Update commit message and email.
>> ---
>>   drivers/cpufreq/cppc_cpufreq.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>> index 15f1d41920a3..802f7c7c0ad8 100644
>> --- a/drivers/cpufreq/cppc_cpufreq.c
>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> @@ -296,7 +296,8 @@ static int cppc_cpufreq_set_target(struct cpufreq_policy *policy,
>>   
>>   	desired_perf = cppc_khz_to_perf(&cpu_data->perf_caps, target_freq);
>>   	/* Return if it is exactly the same perf */
>> -	if (desired_perf == cpu_data->perf_ctrls.desired_perf)
>> +	if (desired_perf == cpu_data->perf_ctrls.desired_perf &&
>> +	    desired_perf == policy->cur)
> 
>  From my earlier understanding, desired_perf is a derived interpretation of the
> frequency and isn't an actual frequency value which can be compared with
> policy->cur.
> 
> Shouldn't we compare policy->cur with target_freq instead ? If yes, than the
> core must already be doing that somewhere I guess.
> 
Yes, you are right， I didn't think it through. In this circumstance, the 
policy->cur is the highest frequency, desired_perf converted from 
target_freq is the same with cpu_data->perf_ctrls.desired_perf which 
shouldn't.