Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4886086pxj; Wed, 12 May 2021 15:41:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUoai0Luyi68LHK5JNc5fhCh6VeJcDS12mrDzBS2FAfUw4eeHkiT5XHUHn7PdkpQUDDvjA X-Received: by 2002:a17:906:63d2:: with SMTP id u18mr40400644ejk.186.1620859319392; Wed, 12 May 2021 15:41:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620859319; cv=none; d=google.com; s=arc-20160816; b=bWZ2pgXQf61qRypxD0YduspIsTBt3YKxXZZZFZV36NqVBtaAUTC1QClhia4gs5Ugib HwL8/cO98zdtpoCBLnovwese0jPF7nmZndq1kGC83yE9MhuLsN32MeukwlNo1XHl5dhR VPM3rY/+VFQRy+mcl8Br2EoxPG09vUHlT+yzh0hjirEEp7FvsH+U1l+a1xW2aHeM8r2n JzSVSylIFytZ57XWT8WxHS00qE5bPotv+AQzfjjHE4ZhSEpXHs4VNYO/uBxxpuAtF91P ldBiIOvZheC8+HzHAa2/CRkxFvEwy4T8lIE5/ctTUbGigHh2w1Anxs9QVrfzbkfGarqe Xwig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=NxhrxEjxVjWENFYvHlizEqBB3HU1enhItQ4kquml6WY=; b=tR1wre7BbC7C2A0LdtUwB15fyANEugyl5bpHVHyBRJKphNLVklCsWyMITC8uyprzwx KH+UTSyNI2IC5AeQwnaOKdi4Defpt9DwfRSGcAu8EgXSwVosxFnV6K3cFWmNysJCOmUp 1KU79U8aCEexd3mcKrFGiMHNucHShL6WMw7BnV6vv86y4ig9GM8QzLvy04DoZxqRHb76 Khkz/NPUMh8ZqEkWK8p9I32VRrG5oSxoPLKXWxI5lvBHwIBQ6y+Rze+bJLlPd56391g7 qQ+uuBil9hOOnsi0mGeNCAxo45ahC18r/vF/hlhOJmdRDX32CxVwX/Fs9dnS2J8/8ZqR hKCA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hs11si1452192ejc.319.2021.05.12.15.41.12; Wed, 12 May 2021 15:41:59 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349506AbhELWiw (ORCPT + 99 others); Wed, 12 May 2021 18:38:52 -0400 Received: from mail.ispras.ru ([83.149.199.84]:37386 "EHLO mail.ispras.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1443603AbhELWff (ORCPT ); Wed, 12 May 2021 18:35:35 -0400 Received: from monopod.intra.ispras.ru (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id CF6394076B2A; Wed, 12 May 2021 22:34:22 +0000 (UTC) Date: Thu, 13 May 2021 01:34:22 +0300 (MSK) From: Alexander Monakov To: Huang Rui cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Alex Deucher , Jason Bagavatsingham , "Pierre-Loup A . Griffais" , Nathan Fontenot , "Rafael J . Wysocki" , Borislav Petkov , x86@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v4] x86, sched: Fix the AMD CPPC maximum perf on some specific generations In-Reply-To: <20210425073451.2557394-1-ray.huang@amd.com> Message-ID: References: <20210425073451.2557394-1-ray.huang@amd.com> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 25 Apr 2021, Huang Rui wrote: > Some AMD Ryzen generations has different calculation method on maximum > perf. 255 is not for all asics, some specific generations should use 166 > as the maximum perf. Otherwise, it will report incorrect frequency value > like below: The commit message says '255', but the code: > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr) > break; > } > } > + > +u32 amd_get_highest_perf(void) > +{ > + struct cpuinfo_x86 *c = &boot_cpu_data; > + > + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) || > + (c->x86_model >= 0x70 && c->x86_model < 0x80))) > + return 166; > + > + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) || > + (c->x86_model >= 0x40 && c->x86_model < 0x70))) > + return 166; > + > + return 225; > +} says 225? This is probably a typo? In any case they are out of sync. Alexander