From patchwork Fri Jul 27 11:50:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Calvin Walton X-Patchwork-Id: 10546945 X-Patchwork-Delegate: lenb@kernel.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 21B1E112B for ; Fri, 27 Jul 2018 11:50:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0E75F2B7ED for ; Fri, 27 Jul 2018 11:50:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 019972B7EF; Fri, 27 Jul 2018 11:50:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8D9E12B7ED for ; Fri, 27 Jul 2018 11:50:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729955AbeG0NMb (ORCPT ); Fri, 27 Jul 2018 09:12:31 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:54201 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729431AbeG0NMb (ORCPT ); Fri, 27 Jul 2018 09:12:31 -0400 Received: by mail-it0-f67.google.com with SMTP id 72-v6so7134194itw.3 for ; Fri, 27 Jul 2018 04:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=ppS0Z+0XQKpXI1g3ftBCHbTOfJriz5sRtIY97NEjC+k=; b=wVuG2DuJ+IjXzKLJKl5u1mVCuTYMhBk6urJMRhbnG3xRm3vNTBE3sp1H53Z8dJKWc2 sGpeDdcfr1ewuejy6uv2vh4R6beSBUETW4by+lzdsamdwDeqCPalEYJT/h03kJGNwcOn JZ++LbctE3bP/BJ69MPW7dF6kpL4Lgf9x1jww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=ppS0Z+0XQKpXI1g3ftBCHbTOfJriz5sRtIY97NEjC+k=; b=i6K1cJrcS/DnRQK42Dm+EiqErQmsu++2qULfqC3gRWNM7UbtvBjT3tDImYqTqgJi0Y 9Cwxlly3YfGNnt+gsOYAnzOHmIiefwigoLnSWo8Q/LVYflfk1IzEdnCNygm+Pbp4wbSD QMvzlG1SYVgsHhaR9UiC6WHM65bCQbLbun8CuHdP97s21SJRn41A6jKuyHy+ndTa5Xp9 mDAVQXbSFnb4w2GAxR2ENU0TkHKMfbzBK1CotYVZn2eiacz+c30Fneh0e/umL33+U7jF 90ql3sONKMU6bIuwPlhuUCCx/Ng3cU7C4BSlJ5FUTsZczav21KYkRS/qa6tKDmOK6VCi +7yg== X-Gm-Message-State: AOUpUlGG9hQ55iGzoaWn5hJWaaUXh3uCkRsfd016kSrTRSDEwrr1Daru yNI8xWZkWZ4Xbj/9MS5FSdlJPw== X-Google-Smtp-Source: AAOMgpfW+O0yXgZNQqdeiu6abzpEF1oQ7FaE5HWkxTk00DjMXe1Nd7sOfh1iZiTMiK+K8L8OQdKing== X-Received: by 2002:a02:b4a4:: with SMTP id k33-v6mr5433245jaj.53.1532692257092; Fri, 27 Jul 2018 04:50:57 -0700 (PDT) Received: from fuko.kepstin.ca ([2001:470:b3f4::561]) by smtp.gmail.com with ESMTPSA id n127-v6sm2333542itn.7.2018.07.27.04.50.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 04:50:56 -0700 (PDT) From: Calvin Walton To: Len Brown , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Calvin Walton Subject: [PATCH v3] turbostat: Read extended processor family from CPUID Date: Fri, 27 Jul 2018 07:50:53 -0400 Message-Id: <20180727115053.8965-1-calvin.walton@kepstin.ca> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180727113809.8427-1-calvin.walton@kepstin.ca> References: <20180727113809.8427-1-calvin.walton@kepstin.ca> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This fixes the reported family on modern AMD processors (e.g. Ryzen, which is family 0x17). Previously these processors all showed up as family 0xf. See the document https://support.amd.com/TechDocs/56255_OSRR.pdf section CPUID_Fn00000001_EAX for how to calculate the family from the BaseFamily and ExtFamily values. This matches the code in arch/x86/lib/cpu.c Signed-off-by: Calvin Walton --- v3: Having just looked at the arch/x86/lib/cpu.c code again, I realized that it *didn't* actually match - the kernel code uses family >= 6 for applying the extended model number, while I was applying it only to family == 6 or family >= 0xf. Change that to match for consistency. v2: I'm still working on updating the RAPL patch on top of the changes for v4.18, but this CPUID fix doesn't have to wait. tools/power/x86/turbostat/turbostat.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index bd9c6b31a504..ed024deed36f 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -4031,7 +4031,9 @@ void process_cpuid() family = (fms >> 8) & 0xf; model = (fms >> 4) & 0xf; stepping = fms & 0xf; - if (family == 6 || family == 0xf) + if (family == 0xf) + family += (fms >> 20) & 0xff; + if (family >= 6) model += ((fms >> 16) & 0xf) << 4; if (!quiet) {