Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp193095imj; Thu, 14 Feb 2019 18:22:45 -0800 (PST) X-Google-Smtp-Source: AHgI3IZbXNcYUJAvOgJpLjQ3yoLjuSzTRpaSmWZ76V9k4gEc2hMegwkkZ3/L3KIBKb/6VGTzCzbi X-Received: by 2002:a17:902:ab92:: with SMTP id f18mr7367305plr.221.1550197365440; Thu, 14 Feb 2019 18:22:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550197365; cv=none; d=google.com; s=arc-20160816; b=p+HCWrKCHX9wukQiy4h0vhmmB8odcysW+lrTks1ICMExzN7fXKBjxd2Pz7qEdv8aao C56jUQpSnrkRS9rTXVcLYuU+oe5gNHW4upk5PP5zwet+weSsf1lA7u+atBXsNXhoh22T hqiF/0ITdR86Q+WXqnlQuGQg2rWZFU4PcCbPJgZMLDLgt7XqzWTYxHLmW6JzxdVjXTMH A80td6u0i12xen7RyjFSUcqjVtcgNm6uLFZpaM3Ti2tfYpaUtXHZqz+UmUZo2q38U7kz uaeRZhvnNAr1e9eAlAAeOERvdn02/WbeQsr5AGDh9cnPCHPIzneh3pzjpaDyAuRFNLPd 1S1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=q5wqrkC07xGpmzUPhVHpohY8riHbJnmmJQhGxPxjPJ8=; b=u8nsC3g8uP+SqvUB7pHblt9mHT00+5uZSSsrWCa6vnOUxNpCs/sDIL4Ko/lzCLaumc xlSA56C+//cFH8rhc+jLVLygC6iJXo3gcP8W7x0ICtV6hceMBIdVyqvRzZvkWPG6iyiJ LyJnAaJthVn28eMDGu8OqHqlujk7hiWjObrAn9wxP7+SvDen/f3hS9M/P7S+44SetFUA rE/wMlKq9VwgGjJhKAxtH7aPpj2fnNNNPrlQ/KPFk69IOxvfU4ltdqOmcfJNhmqC7Y3e US66f5GJqnZUQrEpJRNQw1y4AyJTDhfrMwQmzRQqpLdXBSzjrEG2erlmneOeiirzwDjz fpaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s5si4001979plp.139.2019.02.14.18.22.29; Thu, 14 Feb 2019 18:22:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387865AbfBNXRP (ORCPT + 99 others); Thu, 14 Feb 2019 18:17:15 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:46753 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728098AbfBNXRP (ORCPT ); Thu, 14 Feb 2019 18:17:15 -0500 Received: from 79.184.254.36.ipv4.supernova.orange.pl (79.184.254.36) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.183) id 9063745e333a071e; Fri, 15 Feb 2019 00:17:13 +0100 From: "Rafael J. Wysocki" To: Xiongfeng Wang Cc: "Rafael J. Wysocki" , Viresh Kumar , gcherianv@gmail.com, Prashanth Prakash , George Cherian , Robert Moore , ACPI Devel Maling List , Linux Kernel Mailing List , Hanjun Guo , John Garry Subject: Re: [PATCH v2 2/2] cpufreq / cppc: Work around for Hisilicon CPPC cpufreq Date: Fri, 15 Feb 2019 00:15:52 +0100 Message-ID: <2813657.1l3PCoQO4Z@aspire.rjw.lan> In-Reply-To: <86a1eddc-01aa-f32a-9bef-c18c7649149b@huawei.com> References: <1550130368-60513-1-git-send-email-wangxiongfeng2@huawei.com> <86a1eddc-01aa-f32a-9bef-c18c7649149b@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, February 14, 2019 2:58:21 PM CET Xiongfeng Wang wrote: > > On 2019/2/14 18:58, Rafael J. Wysocki wrote: > > On Thu, Feb 14, 2019 at 8:46 AM Xiongfeng Wang > > wrote: > >> > >> Hisilicon chips do not support delivered performance counter register > >> and reference performance counter register. But the platform can > >> calculate the real performance using its own method. This patch provide > >> a workaround for this problem, and other platforms can also use this > >> workaround framework. We reuse the desired performance register to > >> store the real performance calculated by the platform. After the > >> platform finished the frequency adjust, it gets the real performance and > >> writes it into desired performance register. OS can use it to calculate > >> the real frequency. > >> > >> Signed-off-by: Xiongfeng Wang > >> --- > >> drivers/cpufreq/cppc_cpufreq.c | 70 ++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 70 insertions(+) > >> > >> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c > >> index fd25c21c..da96fec 100644 > >> --- a/drivers/cpufreq/cppc_cpufreq.c > >> +++ b/drivers/cpufreq/cppc_cpufreq.c > >> @@ -33,6 +33,16 @@ > >> /* Offest in the DMI processor structure for the max frequency */ > >> #define DMI_PROCESSOR_MAX_SPEED 0x14 > >> > >> +struct cppc_workaround_info { > >> + char oem_id[ACPI_OEM_ID_SIZE +1]; > >> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1]; > >> + u32 oem_revision; > >> + unsigned int (*get_rate)(unsigned int cpu); > >> +}; > >> + > >> +/* CPPC workaround for get_rate callback */ > >> +unsigned int (*cppc_wa_get_rate)(unsigned int cpu); > >> + > > > > First off, please don't split the workaround material into two parts. > > IOW, the other new function added below can go here just fine IMO. > > > >> /* > >> * These structs contain information parsed from per CPU > >> * ACPI _CPC structures. > >> @@ -334,6 +344,9 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int cpunum) > >> struct cppc_cpudata *cpu = all_cpu_data[cpunum]; > >> int ret; > >> > >> + if (cppc_wa_get_rate) > >> + return cppc_wa_get_rate(cpunum); > > > > Second, what is the value of using the function pointer above? > > > > All we need for now is a flag to indicate whether or not to call > > hisi_cppc_cpufreq_get_rate() here and return its return value. > > How about adding a pointer of 'struct cppc_workaround_info' to indicate whether we have > found a matches workaround ? > If I use a flag, I will need another variable to indicate which item of the workaround array 'wa_info' > to use. And why do you need to distinguish one of them from the other?