Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp541991ybh; Wed, 18 Mar 2020 04:47:22 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt9zFOt8NJWCNpApXbHk+7n1JvuejA+BKvxneW+ANWtORIfTosBsRGqvjjQn3lPwdWA2FA0 X-Received: by 2002:aca:4286:: with SMTP id p128mr2720371oia.29.1584532042735; Wed, 18 Mar 2020 04:47:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584532042; cv=none; d=google.com; s=arc-20160816; b=bLazQTxlKd/PnGQRqjVKpQx7XycXdc5nrQPV5QirvRXCAlkkeXiaKcvr4py3RD6onF UF+60F1TVHd8F2YMOUEdlhS53sMjt6P/6YNXmYPDfzvHUGp5qDJI4TVYUimKtW0chg6A 5qC2LdSZvVJYo5lgkuFhz85QymfQ6Mun8570pBSIZ5IByn0qvZ5ngEtySZpLjw4hWQhK Qo2OSDPQCYq4Mfc4R1IpOiSXN1qO0R0xyz4W828Ls7RpM1dJ8DiKhjavj4ULQP2mscpe 7+mS3S8GvWvKAJPzBM8p7jXkL7NupvEDV7dfffuwtJWe3WMKpYze63cTiE55YZF6hhPX Y0mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=fQGcMnvYeslJL+0GnXrd8xuuGyqlH+6XR7xHfhy5N2k=; b=AlXZMdcK0Ge/nhpYtAC0sAfGq6THb+WL7nQ5LTzmIihZbyfKRaMIaQuE3vyij6Qjqh pc9HYailmEXDcwrdQ/wlT5GCKIE5fGIsLUHkRDl1/FEbfdgrU7AR/CpSm0CrexarQPWv k1wcy7AKYWpGzVcVVxcgrlxIW0Rp8qU5yRJabzBQhCyfelJzQQRiZjYI8CaXzwbuzUR0 tgfrar7GVVt9XfeEMChl5Br6ibOw8vU+owbF3WQ9x/i+ldAkgX+HrbC8rnxYWE9q9uFb c84AyWfo4IgSrKtDEzALvxMzT963nFULKAxNAAN1EcNgkxB1vvHdEHGnX3FsYHxZXSTR RsFQ== 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 b11si3129705oii.11.2020.03.18.04.47.11; Wed, 18 Mar 2020 04:47:22 -0700 (PDT) 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 S1727230AbgCRLqX (ORCPT + 99 others); Wed, 18 Mar 2020 07:46:23 -0400 Received: from foss.arm.com ([217.140.110.172]:48860 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726586AbgCRLqW (ORCPT ); Wed, 18 Mar 2020 07:46:22 -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 ABDB81FB; Wed, 18 Mar 2020 04:46:21 -0700 (PDT) Received: from e123648.arm.com (unknown [10.37.12.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 04D633F534; Wed, 18 Mar 2020 04:46:09 -0700 (PDT) From: Lukasz Luba To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-imx@nxp.com Cc: Morten.Rasmussen@arm.com, Dietmar.Eggemann@arm.com, javi.merino@arm.com, cw00.choi@samsung.com, b.zolnierkie@samsung.com, rjw@rjwysocki.net, sudeep.holla@arm.com, viresh.kumar@linaro.org, nm@ti.com, sboyd@kernel.org, rui.zhang@intel.com, amit.kucheria@verdurent.com, daniel.lezcano@linaro.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, rostedt@goodmis.org, qperret@google.com, bsegall@google.com, mgorman@suse.de, shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com, kernel@pengutronix.de, khilman@kernel.org, agross@kernel.org, bjorn.andersson@linaro.org, robh@kernel.org, matthias.bgg@gmail.com, steven.price@arm.com, tomeu.vizoso@collabora.com, alyssa.rosenzweig@collabora.com, airlied@linux.ie, daniel@ffwll.ch, liviu.dudau@arm.com, lorenzo.pieralisi@arm.com, lukasz.luba@arm.com, patrick.bellasi@matbug.net, orjan.eide@arm.com, rdunlap@infradead.org, mka@chromium.org Subject: [PATCH v5 0/5] Add support for devices in the Energy Model Date: Wed, 18 Mar 2020 11:45:43 +0000 Message-Id: <20200318114548.19916-1-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, This patch set introduces support for devices in the Energy Model (EM) framework. It will unify the power model for thermal subsystem and make it simpler. The 1st patch refactors EM framework and adds support for devices. The 2nd patch changes dev_pm_opp_of_register_em() in OPP/OF which now should take as an argument struct device pointer. It touches a few trees (OMAP, NXP, Mediatek) updating their CPUfreq drivers to the new interface. Patch 4/5 changes thermal devfreq cooling removing old code for calculating local power table. It simplifies the code and uses EM for requested power calculation. Last patch 5/5 adds EM to Panfrost driver. The patch set is based on linux-next tag next-20200317. I have decided to add a pending patch developed by Matthias [5]. It introduces PM QoS limits in devfreq cooling, to not break the build test. When it lands into thermal/linux-next and then in linux-next, I'll drop it from this series. Changes: v5: - devfreq cooling: rebased on top of pending patch introducing PM QoS limits - devfreq cooling: added Matthias's patch to make this series build check pass - devfreq cooling: removed OPP disable code and switched to PM QoS - devfreq cooling: since thermal code always used a pointer to devfreq_dev_status, switched to work on a local copy and avoid potential race when either busy_time or total_time could change in the background - devfreq cooling: added _normalize_load() and handle all scenarios when busy_time and total_time could have odd values (even raw counters) - Energy Model patch 2/4: removed prints from cpufreq drivers and added print inside dev_pm_opp_of_register_em() - update patch 2/4 description to better reflect upcoming changes - collected ACK from Quentin for patch 1/4 and Reviewed-by from Steven for 4/4 v4 [4]: - devfreq cooling: added two new registration functions, which will take care of registering EM for the device and simplify drivers code (suggested by Robin and Rob) - Energy Model: changed unregistering code, added kref to track usage, added code freeing tables, added helper function - added return value to function dev_pm_opp_of_register_em() and updated CPUFreq drivers code, added debug prints in case of failure - updated comments in devfreq cooling removing statement that only simple_ondemand devfreq governor is supported to work with power extentions - fixed spelling in the documentation (reported by Randy) v3 [3]: - added back the cpumask 'cpus' in the em_perf_domain due potential cache misses - removed _is_cpu_em() since there is no need for it - changed function name from em_pd_energy() to em_cpu_energy(), which is optimized for usage from the scheduler making some assumptions and not validating arguments to speed-up, there is a comment stressing that it should be used only for CPUs em_perf_domain - changed em_get_pd() to em_pd_get() which is now aligned with em_cpu_get() naming - Energy Model: add code which checks if the EM is already registered for the devfreq device - extended comment in em_cpu_get() describing the need for this function - fixed build warning reported on x86 by kbuild test robot in devfreq_cooling.c - updated documentation in the energy-model.rst - changed print messages from 'energy_model' to 'EM' - changed dev_warn to dev_dbg, should calm down test scripts in case the platform has OPPs less efficient in the OPP table (some of them are there for cooling reasons, we shouldn't warn in this case, debug info is enough) v2 [2]: - changed EM API em_register_perf_domain() adding cpumask_t pointer as last argument (which was discussed with Dietmar and Quentin) - removed dependency on PM_OPP, thanks to the cpumask_t argument - removed enum em_type and em->type dependent code - em_get_pd() can handle CPU device as well as devfreq device - updated EM documentation - in devfreq cooling added code which prevents from race condition with devfreq governors which are trying to use OPPs while thermal is in the middle of disabling them. - in devfreq cooling added code which updates state of the devfreq device to avoid working on stale data when governor has not updated it for a long time - in devfreq cooling added backward compatibility frequency table for drivers which did not provide EM - added Steven's Reviewed-by to trace code in thermal - added another CPUFreq driver which needs to be updated to the new API The v1 can be found here [1]. Regards, Lukasz Luba [1] https://lkml.org/lkml/2020/1/16/619 [2] https://lkml.org/lkml/2020/2/6/377 [3] https://lkml.org/lkml/2020/2/21/1910 [4] https://lkml.org/lkml/2020/3/9/471 [5] https://patchwork.kernel.org/patch/11435217/ Lukasz Luba (4): PM / EM: add devices to Energy Model OPP: refactor dev_pm_opp_of_register_em() and update related drivers thermal: devfreq_cooling: Refactor code and switch to use Energy Model drm/panfrost: Register devfreq cooling and attempt to add Energy Model Matthias Kaehlcke (1): thermal: devfreq_cooling: Use PM QoS to set frequency limits Documentation/power/energy-model.rst | 133 ++--- Documentation/scheduler/sched-energy.rst | 2 +- drivers/cpufreq/cpufreq-dt.c | 2 +- drivers/cpufreq/imx6q-cpufreq.c | 2 +- drivers/cpufreq/mediatek-cpufreq.c | 2 +- drivers/cpufreq/omap-cpufreq.c | 2 +- drivers/cpufreq/qcom-cpufreq-hw.c | 2 +- drivers/cpufreq/scmi-cpufreq.c | 13 +- drivers/cpufreq/scpi-cpufreq.c | 2 +- drivers/cpufreq/vexpress-spc-cpufreq.c | 2 +- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +- drivers/opp/of.c | 76 +-- drivers/thermal/cpufreq_cooling.c | 12 +- drivers/thermal/devfreq_cooling.c | 536 ++++++++++---------- include/linux/devfreq_cooling.h | 39 +- include/linux/energy_model.h | 111 ++-- include/linux/pm_opp.h | 15 +- include/trace/events/thermal.h | 19 +- kernel/power/energy_model.c | 465 +++++++++++++---- kernel/sched/fair.c | 2 +- kernel/sched/topology.c | 4 +- 21 files changed, 901 insertions(+), 542 deletions(-) -- 2.17.1