Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1241838pxv; Fri, 25 Jun 2021 08:27:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycOOZcZgQVmjrrTfdFZuLyTD8JBKb0Uo6dxkE5biaVtwGMhZ/wjnRNOjNEikoayoSRQn7y X-Received: by 2002:a5d:9549:: with SMTP id a9mr8908971ios.152.1624634861742; Fri, 25 Jun 2021 08:27:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624634861; cv=none; d=google.com; s=arc-20160816; b=hfw6xYUc3tOHh66dfJAif1hFlprAPAt+wJ6+ub2T1K+H0Pigvi4FW4LprWENIy53JR 0yX8ulGj5wYzDNF3DC4fomZukB6XZ0y5HOT47VVLql58iB1wYx6+3DMrzYKL7Pv+a+7D kfXrEsRXj+2TNBzv8TI64/hA50I4ePSFPystdb9XtCIbobY4+RFWVQOrStBcaQPVVQpM Y/ZN5jn9se10pFMnKr0LLcTtniV/bfY+kH9hivoPV60ruNo7ezphSZbISab33tJCqQjA g+dn7jPFUOCDl+huwx3QbPEUUt8D6OkkphSbyTkbKNCmv1YqEJxe7Kt8TfCk1iD3gBoa 9egg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=x/mFLuUront170BiPoPTiv6wuvaK5jl7MgAkjaYk67s=; b=vWxayl1O/0tcR4uIdKcQ2gnbrBdDAK3zny2TUUDV2FkDPYiC23xJ31wtonbCmJZAyx 8CEDeBiUzTB2X2QUqboye2V0amuNFlT3TFm0HbHOUcl3VnxS/cILoSK7BonQ0/m6+S9W DlqqmeKbbsp+VFoQdPxLTsKILr2zN51aYbGjwbp+pHvuHQOBBBPJwJQwjxehC1zR70GA vtdOC5HdxO7w4/mlVOtI1qRQLup6JidF+tcKCAGsN5FJKCZG2v9lQ3+cz3s+uECrr6Pa n+hoHjDXnBtMQVWDoSGluLjdUhhDUP+BlMetP9kU1F7FwjqyrFjCnnH7ubMAj9INQOxv yb5g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k7si5952911ilu.130.2021.06.25.08.27.29; Fri, 25 Jun 2021 08:27:41 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229906AbhFYP3H (ORCPT + 99 others); Fri, 25 Jun 2021 11:29:07 -0400 Received: from foss.arm.com ([217.140.110.172]:58660 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbhFYP3H (ORCPT ); Fri, 25 Jun 2021 11:29:07 -0400 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 399591396; Fri, 25 Jun 2021 08:26:46 -0700 (PDT) Received: from e123648.arm.com (unknown [10.57.7.232]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 0C50B3F694; Fri, 25 Jun 2021 08:26:42 -0700 (PDT) From: Lukasz Luba To: linux-kernel@vger.kernel.org Cc: Chris.Redpath@arm.com, lukasz.luba@arm.com, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, qperret@google.com, linux-pm@vger.kernel.org, peterz@infradead.org, rjw@rjwysocki.net, viresh.kumar@linaro.org, vincent.guittot@linaro.org, mingo@redhat.com, juri.lelli@redhat.com, rostedt@goodmis.org, segall@google.com, mgorman@suse.de, bristot@redhat.com, CCj.Yeh@mediatek.com Subject: [PATCH 2/3] PM: EM: Make em_cpu_energy() able to return bigger values Date: Fri, 25 Jun 2021 16:26:02 +0100 Message-Id: <20210625152603.25960-3-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210625152603.25960-1-lukasz.luba@arm.com> References: <20210625152603.25960-1-lukasz.luba@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The Energy Model (EM) em_cpu_energy() is responsible for providing good estimation regarding CPUs energy. It contains proper data structures which are then used during calculation. The values stored in there are in milli-Watts precision (or in abstract scale) smaller that 0xffff, which use sufficient unsigned long even on 32-bit machines. There are scenarios where we would like to provide calculated estimations in a better precision and the values might be 1000 times bigger. This patch makes possible to use quite big values for also 32-bit machines. Signed-off-by: Lukasz Luba --- include/linux/energy_model.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h index 3f221dbf5f95..2016f5a706e0 100644 --- a/include/linux/energy_model.h +++ b/include/linux/energy_model.h @@ -101,7 +101,7 @@ void em_dev_unregister_perf_domain(struct device *dev); * Return: the sum of the energy consumed by the CPUs of the domain assuming * a capacity state satisfying the max utilization of the domain. */ -static inline unsigned long em_cpu_energy(struct em_perf_domain *pd, +static inline u64 em_cpu_energy(struct em_perf_domain *pd, unsigned long max_util, unsigned long sum_util, unsigned long allowed_cpu_cap) { @@ -180,7 +180,7 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd, * pd_nrg = ------------------------ (4) * scale_cpu */ - return ps->cost * sum_util / scale_cpu; + return div_u64((u64)ps->cost * sum_util, scale_cpu); } /** @@ -217,7 +217,7 @@ static inline struct em_perf_domain *em_pd_get(struct device *dev) { return NULL; } -static inline unsigned long em_cpu_energy(struct em_perf_domain *pd, +static inline u64 em_cpu_energy(struct em_perf_domain *pd, unsigned long max_util, unsigned long sum_util, unsigned long allowed_cpu_cap) { -- 2.17.1