From patchwork Tue Apr 24 23:12:39 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Prakash, Prashanth" X-Patchwork-Id: 10361199 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 78E7B6038F for ; Tue, 24 Apr 2018 23:13:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6862928E8F for ; Tue, 24 Apr 2018 23:13:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5C46F28E92; Tue, 24 Apr 2018 23:13:17 +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=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID 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 994D528E8F for ; Tue, 24 Apr 2018 23:13:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751061AbeDXXNQ (ORCPT ); Tue, 24 Apr 2018 19:13:16 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:46434 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751027AbeDXXNP (ORCPT ); Tue, 24 Apr 2018 19:13:15 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 02A6960881; Tue, 24 Apr 2018 23:13:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524611595; bh=0BeVXF7Zg5FVqLfgSzuEbLhDpGtxltKaNfNoC+UJy8o=; h=From:To:Cc:Subject:Date:From; b=PH3z7qxv1pyS6n7308jxRJlfRGbRjA0S1/bZb9M8uqFhkXne17WSWgb0krAiLulBq DFqYbYKH2nLWW8/Ajc9EdtNghn2x83t6BPxi+l7aycRxxsbLdGqKaTjvBxcAL7vF/B 8PEKXoRwX1JkD4jltAKWYyFvxMOZbm95PlBr1awc= Received: from pprakash-lnx.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pprakash@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id BBF1B6071A; Tue, 24 Apr 2018 23:13:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524611594; bh=0BeVXF7Zg5FVqLfgSzuEbLhDpGtxltKaNfNoC+UJy8o=; h=From:To:Cc:Subject:Date:From; b=I27A+HSMiF0t9A2TN16LI3O8MkTfZe1GCiiMcwqDFqlBovFQGqRjZPqmmm02OeOvv 0YvCks47boVT+x9T36sL17pOcACcdRZ/tRIET/Ih2mwCCWN3w+2EpKjsIn4eGemy4A kF3NysFtfznTXyZO0ZPcAXEEkvDVGRrMQBeWqzw8= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org BBF1B6071A Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=pprakash@codeaurora.org From: Prashanth Prakash To: linux-pm@vger.kernel.org Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org, Prashanth Prakash Subject: [PATCH] cpufreq / CPPC: Set platform specific transition_delay_us Date: Tue, 24 Apr 2018 17:12:39 -0600 Message-Id: <1524611559-20138-1-git-send-email-pprakash@codeaurora.org> X-Mailer: git-send-email 1.9.1 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 Add support to specify platform specific transition_delay_us instead of using the transition delay derived from PCC. With commit "45f39cb5071c: cpufreq: CPPC: Use transition_delay_us depending transition_latency" we are setting transition_delay_us directly and not applying the LATENCY_MULTIPLIER. With this on Qualcomm Centriq we can end up with a very high rate of frequency change requests when using schedutil governor (default rate_limit_us=10 compared to an earlier value of 10000). The PCC subspace describes the rate at which the platform can accept commands on the CPPC's PCC channel. This includes read and write command on the PCC channel that can be used for reasons other than frequency transitions. Moreover the same PCC subspace can be used by multiple freq domains and deriving transition_delay_us from it as we do now can be sub-optimal. Moreover if a platform does not use PCC for desired_perf register then there is no way to compute the transition latency or the delay_us. CPPC does not have a standard defined mechanism to get the transition rate or the latency at the moment. Given the above limitations, it is simpler to have a platform specific transition_delay_us and rely only on PCC derived value only if a platform specific value is not available. Signed-off-by: Prashanth Prakash Cc: Viresh Kumar Cc: Rafael J. Wysocki Fixes: 45f39cb5071c ("cpufreq: CPPC: Use transition_delay_us depending transition_latency) --- drivers/cpufreq/cppc_cpufreq.c | 43 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index bc5fc16..e935e43 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -126,6 +126,43 @@ static void cppc_cpufreq_stop_cpu(struct cpufreq_policy *policy) cpu->perf_caps.lowest_perf, cpu_num, ret); } +/* + * The PCC subspace describes the rate at which platform can accept commands + * on the shared PCC channel (including READs which do not count towards freq + * trasition requests), so ideally we need to use the PCC values as a fallback + * if we don't have a platform specific transition_delay_us + */ +#if defined(CONFIG_ARM64) +#include + +static unsigned int cppc_cpufreq_get_transition_delay_us(void) +{ + unsigned long implementor = read_cpuid_implementor(); + unsigned long part_num = read_cpuid_part_number(); + unsigned int delay_us = 0; + + switch (implementor) { + case ARM_CPU_IMP_QCOM: + switch (part_num) { + case QCOM_CPU_PART_FALKOR_V1: + case QCOM_CPU_PART_FALKOR: + delay_us = 10000; + break; + } + break; + } + + return delay_us; +} + +#else + +static unsigned int cppc_cpufreq_get_transition_delay_us(void) +{ + return 0; +} +#endif + static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy) { struct cppc_cpudata *cpu; @@ -162,8 +199,10 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy) cpu->perf_caps.highest_perf; policy->cpuinfo.max_freq = cppc_dmi_max_khz; - policy->transition_delay_us = cppc_get_transition_latency(cpu_num) / - NSEC_PER_USEC; + policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(); + if (!policy->transition_delay_us) + policy->transition_delay_us = cppc_get_transition_latency(cpu_num) / + NSEC_PER_USEC; policy->shared_type = cpu->shared_type; if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {