Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp716371ybj; Thu, 7 May 2020 06:07:24 -0700 (PDT) X-Google-Smtp-Source: APiQypLzTekfnvNlVgm7ZcQV/dPH+6CHOCAoLQ8Xf8mOmaLV1jDaQmIl7iYVfrC9LIvjVIB79Iqk X-Received: by 2002:a17:906:cf8a:: with SMTP id um10mr11652814ejb.60.1588856844117; Thu, 07 May 2020 06:07:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588856844; cv=none; d=google.com; s=arc-20160816; b=aaK4XN4p0A8UbqX2UXzXBGzYUjyDW0KYOOB7cqXgPXYuC73TfBgb1WF+oJjaQJPjWc Jip+Tyqm7ZINLmc7IXdXM2+fkrodL/9CXA6ig7M8p56Tp7G+0ou93FPtQ01ho0wxbtco cjF9okx6y4WbZKDir4anfHe5On+yuAnwQXJbaDwZxCfmf1u/5uvYgyRujuxre3EwYTL7 6mTlPB8PEYp7kJLA4UFxWPim+cZP7zT0ILY8MIf4blsadOESQeS9Uiz5ZqlU2+vr7kl/ hTOE6J83oq2uJTT+Gp4AAO+Jd08WNnQQjuko4BYDZAIYb2YabPltJIqnAzfcRae4fKs3 wvOA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=aY+EWraH9F4563Elq81fK7T3th2rmhYydyknzdH9gOk=; b=a19vVnAiMulD+MUylAeUR6g37Chyapn5WFkL4xXcznld9GScPve9+SxhTX8hQx39Pw aBiCcLsti1vkQYsZCAoHaGKpMr1BCQ09NaZdMimk/7fcLC22O963U6u5ziaWRUmndcI3 duXxM0euXFUqUC5KUwVa6WUOKC8IqddpB2EAmuLOzTsVbX17CrsZZcVepmcd6q6N4/Wu vKRL+kU4vYjDxsm9sXN8orA12xk/WjCo7VihkefK4si7Aqp0WTVPaLvtg3QMprtU+iTa NCljM+7Ew9s8NUEylSDbw3ph7hzHQtr8vmOuhYrSqfcxbfl/F2C4cBCeNCIQFoTzmBEU ap0Q== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w26si3088771ejs.63.2020.05.07.06.06.56; Thu, 07 May 2020 06:07:24 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726683AbgEGNE6 (ORCPT + 99 others); Thu, 7 May 2020 09:04:58 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:3844 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725914AbgEGNE5 (ORCPT ); Thu, 7 May 2020 09:04:57 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 59812306F6222C6274D5; Thu, 7 May 2020 21:04:52 +0800 (CST) Received: from [127.0.0.1] (10.166.213.93) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.487.0; Thu, 7 May 2020 21:04:44 +0800 Subject: Re: [RFC PATCH] cpufreq: add support for HiSilicon SoC HIP09 To: Souvik Chakravarty , Thanu Rangarajan , Sudeep Holla CC: Xiongfeng Wang , "rjw@rjwysocki.net" , "viresh.kumar@linaro.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "john.garry@huawei.com" , Jonathan Cameron References: <1588227599-46438-1-git-send-email-wangxiongfeng2@huawei.com> <20200430095559.GB28579@bogus> <3ba950dd-4065-e4a5-d406-dc5c6c1781a7@huawei.com> <20200506124932.GA20426@bogus> <028166CD-55C8-4FC6-AEBB-C190D20290D5@arm.com> From: Hanjun Guo Message-ID: Date: Thu, 7 May 2020 21:04:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [10.166.213.93] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thanu, Souvik, Sudeep, Thanks a lot for the prompt reply, and it clarify a lot for us, comment inline below. On 2020/5/6 22:57, Souvik Chakravarty wrote: > Hi, > >> From: Thanu Rangarajan >> Sent: Wednesday, May 6, 2020 1:58 PM >> >> Hi, >> ACPI CPPC already supports the notion of boost. Not sure we need any >> enhancements there. >> >> Regards, >> Thanu >> >> On 06/05/2020, 18:19, "Sudeep Holla" wrote: >> >> + Thanu, Souvik who work with ASWG >> >> On Wed, May 06, 2020 at 05:36:51PM +0800, Hanjun Guo wrote: >> > Hi Sudeep, >> > >> > On 2020/4/30 17:55, Sudeep Holla wrote: >> > > On Thu, Apr 30, 2020 at 02:19:59PM +0800, Xiongfeng Wang wrote: >> > > > HiSilicon SoC has a separate System Control Processor(SCP) >> dedicated for >> > > > clock frequency adjustment and has been using the cpufreq driver >> > > > 'cppc-cpufreq'. New HiSilicon SoC HIP09 add support for CPU Boost, >> but >> > > > ACPI CPPC doesn't support this. In HiSilicon SoC HIP09, each core has >> > > > its own clock domain. It is better for the core itself to adjust its >> > > > frequency when we require fast response. In this patch, we add a >> > > > separate cpufreq driver for HiSilicon SoC HIP09. >> > > > >> > > >> > > I disagree with this approach unless you have tried to extend the CPPC >> > > in ACPI to accommodate this boost feature you need. Until you show >> those >> > > efforts and disagreement to do that from ASWG, I am NACKing this >> approach. >> > >> > Unfortunately we are not in ASWG at now, could you please give some >> > help about extending CPPC in ACPI to support boost feature? >> > >> >> You may have to provide more details than the commit log for sure as I >> haven't understood the boost feature and what is missing in ACPI CPPC. > > I would agree with Thanu here regarding the ACPI spec part - everything is already there. I take another detail read of the spec and as you said, everything is already there,thanks!. I was misleading by the CPPC code which it's using the 'Highest Performance' as the max performance not the 'Nominal Performance', so seems that 'Highest Performance' is the normal max performance but not the boost performance. > > It seems to me that the .set_boost is today not handled in cppc_cpufreq.c. In fact if a platform provides a value for Highest Performance which is different than Nominal Performance, then the entire range of performance is always requested, which works well for platforms which do boost enable/disable selection at hardware/firmware level. Yes, so for now, the CPPC code will enable the boost feature in default if the firmware provides a value for Highest Performance which is different than Nominal Performance. > > .boost hook could potentially be useful in cppc_cpufreq.c for platforms which would manage the boost selection in software. But it would be good to keep a common implementation which can choose between "software-triggered or auto-boost" selection for different platforms. Thanks for the clarify, it helps a lot, Xiongfeng prepared some patches to enable .boost hook, but needs to set the 'Nominal Performance' as the max performance, and 'Highest Performance' is the max boost performance, will send out for comments. Best Regards, Hanjun