From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22D82C2D0E2 for ; Thu, 24 Sep 2020 09:54:31 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B8EAA2396E for ; Thu, 24 Sep 2020 09:54:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cKFarmvl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8EAA2396E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NV2q2t6krTZeMaKQEojeBVO9fjYhXO/CI3BQ/GwKinI=; b=cKFarmvlrPeh43mZxXrCeURt1 6YmuhTg9v0TARjv4erRM7/fzCF3EdhkbwYs1/p4CbcBw+Qgr1bnjbrmAaIQeR8Y56qmXtNMrGokIL WtIlZ0+PEBL0DyhMxtl4/0+S8WKkiHcXTkOej+gY0UPqTi6mUjuwxWsphcPbBH7m2xHjgzf2nhVz3 3TbbWWTnRN7n4HZQ6xiRKuVf8W2xlgPsiK8FE9aeoNPqFz9J0ZoCcmuSrf6s+n3gjIJWRGdLvTNGV u3uHur3k2oGvFIIhWJqixonRKTIVj3kvt1yYZ0fpxxegEn2V2dKX+LtelHaBijcpyEId2RDwkWLhj vuijVZ1hQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLNw9-0000bp-7f; Thu, 24 Sep 2020 09:53:13 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLNw4-0000aW-VK for linux-arm-kernel@lists.infradead.org; Thu, 24 Sep 2020 09:53:10 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DED27113E; Thu, 24 Sep 2020 02:53:07 -0700 (PDT) Received: from ubuntu.arm.com (unknown [10.57.15.115]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id E876C3F73B; Thu, 24 Sep 2020 02:53:05 -0700 (PDT) From: Nicola Mazzucato To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org, daniel.lezcano@linaro.org Subject: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Date: Thu, 24 Sep 2020 10:53:47 +0100 Message-Id: <20200924095347.32148-3-nicola.mazzucato@arm.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200924095347.32148-1-nicola.mazzucato@arm.com> References: <20200924095347.32148-1-nicola.mazzucato@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200924_055309_150132_72C3363B X-CRM114-Status: GOOD ( 18.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: chris.redpath@arm.com, morten.rasmussen@arm.com, nicola.mazzucato@arm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org I am seeking some feedback/comments on the following approach. Intro: Info of performance depency for cpus will be beneficial for systems where f/w description of the CPU performance control domain is different from the clock domain, e.g. per-CPU control with multiple CPUs sharing clock, and kernel OSPM s/w components need to take CPU performance dependency into account. Essentially these s/w components will have to be provided with this information from dt and this RFC is presenting a possible way to do so. Little details about implementation are given, as this RFC aims to present the overall approach. Proposal: The cpufreq framework currently assumes that a policy covers a group of CPUs that are controlled together. The energy model and thermal frameworks assume that the policy cpumask describes performance dependency relation. This assumption is no longer generally valid, so we need a way to represent both control and performance relation in cpufreq. The proposal is to have one cpufreq_policy instance per control domain, and have a new cpumask 'dependent_cpus' to the policy to represent the CPU performance dependencies. The main reason for a new cpumaks is that although 'related_cpus' could be (or could have been) used for such purpose, its meaning has changed over time. Initially it was designed specifically for this purpose[1], but eventually it has changed to online + offline cpus when sw coordination in use [2,3]. There is also a 'shared_type' field in cpufreq_policy which provides info about coordination type (NONE, SW_ANY, SW_ALL, HW). Currently it's in use only for ACPI but I assume it can be used to indicate the coordination type even out of ACPI itself. Currently there is no use of TYPE_HW. Provided that the cpufreq driver will populate dependent_cpus and set shared_type, the s/w components that rely on such description (we focus on energy-model and cpufreq_cooling for now) will always be provided with the correct information, when picking the new cpumask. Proposed changes (at high level)(4): 1) cpufreq: Add new dependent_cpus cpumaks in cpufreq_policy * New cpumask addition struct cpufreq_policy { cpumask_var_t related_cpus; /* Online + Offline CPUs */ cpumask_var_t real_cpus; /* Related and present */ + /* + * CPUs with hardware clk/perf dependencies + * + * For sw components that rely on h/w info of clk dependencies when hw + * coordinates. This cpumask should always reflect the hw dependencies. + */ + cpumask_var_t dependent_cpus; /* all clk-dependent cpus */ + unsigned int shared_type; /* ACPI: ANY or ALL affected CPUs * Fallback mechanism for dependent_cpus. With this, s/w components can always pick dependent_cpus regardless the coordination type. static int cpufreq_online(unsigned int cpu) /* related_cpus should at least include policy->cpus. */ cpumask_copy(policy->related_cpus, policy->cpus); + + /* dependent_cpus should differ only when hw coordination is in place */ + if (policy->shared_type != CPUFREQ_SHARED_TYPE_HW) + cpumask_copy(policy->dependent_cpus, policy->cpus); } * Add sysfs attribute for dependent_cpus 2) drivers/thermal/cpufreq_cooling: Replace related_cpus with dependent_cpus 3) drivers/firmware/arm_scmi/perf.c: Parse dt for `cpu-performance-dependencies` * Parse dt for `cpu-performance-dependencies` optional node * Store internally performance dependencies * Add api to get depedent_cpus if required 4) drivers/cpufreq/scmi-cpufreq: Register EM device with the proper cpumask * Check for performance dependencies and get dependent_cpus * Set policy->shared_type accordingly * Provide to EM the correct performance dependencies information static int scmi_cpufreq_init(struct cpufreq_policy *policy) policy->fast_switch_possible = handle->perf_ops->fast_switch_possible(handle, cpu_dev); - em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus); + /* + * EM needs accurate information about clk boundaries, thus provide the + * correct cpumask. + */ + if (handle->perf_ops->has_perf_deps(handle)) + em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, + policy->dependent_cpus); + else + em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, + policy->cpus); Any other suggestions are welcome. Thanks Nicola [1] 'commit e8628dd06d66 ("[CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism")' [2] 'commit 951fc5f45836 ("cpufreq: Update Documentation for cpus and related_cpus")' [3] 'commit f4fd3797848a ("acpi-cpufreq: Add new sysfs attribute freqdomain_cpus")' -- 2.27.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel