On 1/13/21 3:35 PM, Steven Price wrote:
On 05/01/2021 16:41, Lukasz Luba wrote:
Devfreq framework supports 2 modes for monitoring devices.
Use delayed timer as default instead of deferrable timer
in order to monitor the GPU status regardless of CPU idle.
Signed-off-by: Lukasz Luba
Looks
data with thresholds values gathered experimentally in different
workloads.
Signed-off-by: Lukasz Luba
---
Hi all,
This patch aims to improve the panfrost performance in various workloads,
(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the
On 1/22/21 8:21 AM, Steven Price wrote:
On 21/01/2021 17:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to
On 1/21/21 5:15 PM, Daniel Lezcano wrote:
On 21/01/2021 18:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to
On 1/22/21 10:24 AM, Steven Price wrote:
On 22/01/2021 10:00, Lukasz Luba wrote:
On 1/22/21 8:21 AM, Steven Price wrote:
On 21/01/2021 17:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide
about
the frequency change: upthreshold, downdifferential
On 1/27/21 10:24 AM, Lukasz Luba wrote:
Hi Christian,
On 1/25/21 8:18 AM, Christian Hewitt wrote:
This patch adapts the panfrost pre-defined thresholds change [0] to the
lima driver to improve real-world performance. The upthreshold value has
been set to ramp GPU frequency to max freq
Hi Christian,
On 1/25/21 8:18 AM, Christian Hewitt wrote:
This patch adapts the panfrost pre-defined thresholds change [0] to the
lima driver to improve real-world performance. The upthreshold value has
been set to ramp GPU frequency to max freq faster (compared to panfrost)
to compensate for th
Devfreq framework supports 2 modes for monitoring devices.
Use delayed timer as default instead of deferrable timer
in order to monitor the GPU status regardless of CPU idle.
Signed-off-by: Lukasz Luba
---
Hi all,
I've missed the Lima driver while working on Panfrost patch for fixing
the
On 1/27/21 7:35 PM, Christian Hewitt wrote:
On 27 Jan 2021, at 3:11 pm, Lukasz Luba wrote:
On 1/27/21 10:24 AM, Lukasz Luba wrote:
Hi Christian,
On 1/25/21 8:18 AM, Christian Hewitt wrote:
This patch adapts the panfrost pre-defined thresholds change [0] to the
lima driver to improve real
uct devfreq_simple_ondemand_data gov_data;
ktime_t busy_time;
ktime_t idle_time;
It looks good.
Reviewed-by: Lukasz Luba
Regards,
Lukasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Qiang,
On 1/30/21 1:51 PM, Qiang Yu wrote:
Thanks for the patch. But I can't observe any difference on glmark2
with or without this patch.
Maybe you can provide other test which can benefit from it.
This is a design problem and has impact on the whole system.
There is a few issues. When the
On 1/30/21 1:57 PM, Qiang Yu wrote:
This patch gets minor improvement on glmark2 (160->162).
It has bigger impact when the load is changing and the frequency
is stuck to min w/o this patch.
Seems there's no way for user to change this value, do we?
Or there's work pending to expose it to
27;t be woken up, it will stay in suspend.
Regards,
Lukasz
Regards,
Qiang
On Mon, Feb 1, 2021 at 5:53 PM Lukasz Luba wrote:
Hi Qiang,
On 1/30/21 1:51 PM, Qiang Yu wrote:
Thanks for the patch. But I can't observe any difference on glmark2
with or without this patch.
Maybe you can pro
On 2/4/21 1:39 PM, Robin Murphy wrote:
On 2021-02-03 02:01, Qiang Yu wrote:
On Tue, Feb 2, 2021 at 10:02 PM Lukasz Luba wrote:
On 2/2/21 1:01 AM, Qiang Yu wrote:
Hi Lukasz,
Thanks for the explanation. So the deferred timer option makes a
mistake that
when GPU goes from idle to busy
Hi Daniel,
On 3/4/21 12:50 PM, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.
There are no so many and actually it makes more sense to register the
devfreq device when adding it.
Consequently, e
On 3/4/21 4:53 PM, Daniel Lezcano wrote:
Hi Lukasz,
thanks for commenting this patch,
On 04/03/2021 14:47, Lukasz Luba wrote:
Hi Daniel,
On 3/4/21 12:50 PM, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq
On 12/1/20 2:05 PM, Ionela Voinescu wrote:
Hi,
On Thursday 22 Oct 2020 at 12:17:31 (+0100), Lukasz Luba wrote:
[..]
+/**
+ * devfreq_cooling_em_register_power() - Register devfreq cooling device with
+ * power information and attempt to register Energy Model (EM)
It took me a
On 12/1/20 10:36 AM, Ionela Voinescu wrote:
Hi,
Sorry for the delay and for the noise on this older version. I first
want to understand the code better.
On Thursday 22 Oct 2020 at 11:55:28 (+0100), Lukasz Luba wrote:
[..]
+{
+ /* Make some space if needed */
+ if (status
On 12/2/20 11:49 AM, Ionela Voinescu wrote:
On Wednesday 02 Dec 2020 at 11:14:02 (+), Lukasz Luba wrote:
Hi Ionela,
On 12/2/20 10:24 AM, Ionela Voinescu wrote:
Hi Lukasz,
On Wednesday 18 Nov 2020 at 12:03:56 (+), Lukasz Luba wrote:
[snip]
+ struct device_node *np = NULL
Hi Ionela,
On 12/2/20 10:24 AM, Ionela Voinescu wrote:
Hi Lukasz,
On Wednesday 18 Nov 2020 at 12:03:56 (+), Lukasz Luba wrote:
[snip]
+ struct device_node *np = NULL;
[snip]
+
+ if (dev->of_node)
+ np = of_node_get(dev->of_node);
+
Should np be c
On 12/3/20 1:09 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which might be a stale data
and get more up-to-date values of the load.
Devfreq framework
On 12/3/20 3:40 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
The Energy Model (EM) framework supports devices such as Devfreq. Create
new registration functions which automatically register EM for the thermal
devfreq_cooling devices. This patch prepares the code for
On 12/3/20 4:09 PM, Daniel Lezcano wrote:
On 03/12/2020 16:38, Lukasz Luba wrote:
On 12/3/20 1:09 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which
Hi Daniel,
On 12/7/20 12:41 PM, Lukasz Luba wrote:
On 12/3/20 4:09 PM, Daniel Lezcano wrote:
On 03/12/2020 16:38, Lukasz Luba wrote:
On 12/3/20 1:09 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
Devfreq cooling needs to now the correct status of the device in order
Prepare for deleting the static and dynamic power calculation and clean
the trace function. These two fields are going to be removed in the next
changes.
Reviewed-by: Ionela Voinescu
Reviewed-by: Steven Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal
: Ionela Voinescu
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 83 ++-
include/linux/devfreq_cooling.h | 23 +
2 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal
needed structures.
Reviewed-by: Ionela Voinescu
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 307 ++
include/linux/devfreq_cooling.h | 17 --
2 files changed, 97 insertions(+), 227 deletions(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b
, which also makes sure
that whatever data comes from the device, the load will be in range from 1
to 1024.
Reviewed-by: Ionela Voinescu
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 47 ---
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git
Add a property dynamic-power-coefficient which allows to register Energy
Model for the Mali Midgard devices.
Signed-off-by: Lukasz Luba
---
.../bindings/gpu/arm,mali-midgard.yaml | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings
created based on DT 'dynamic-power-coefficient', voltage and frequency.
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Add a property dynamic-power-coefficient which allows to register Energy
Model for the Mali Bifrost devices.
Signed-off-by: Lukasz Luba
---
.../bindings/gpu/arm,mali-bifrost.yaml | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings
Hi all,
The patch set aims to add a new property dynamic-power-coefficient to Mali GPU
DT bindings. This property is known from CPUs and they are both aligned. It
is used for Energy Model registration.
Regards,
Lukasz Luba
Lukasz Luba (2):
dt-bindings: mali-midgard: Add dynamic-power
t(), since the code can handle it
- removed dfc_em_get_requested_power() (as missed to do it in v2)
- collected all Reviewed-by tags
v2 [3]:
- renamed freq_get_state() and related to perf_idx pattern as
suggested by Ionela
v1 [2]
Regards,
Lukasz Luba
[1] https://lkml.org/lkml/2020/5/11/326
[2] https://lore
Hi Daniel,
On 12/9/20 10:30 AM, Lukasz Luba wrote:
Hi all,
This patch set is a continuation of my previous work, which aimed
to add Energy Model to all devices [1]. This series is a follow up
for the patches which got merged to v5.9-rc1. It aims to change
the thermal devfreq cooling and use
, which also makes sure
that whatever data comes from the device, the load will be in range from 1
to 1024.
Reviewed-by: Ionela Voinescu
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 47 ---
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git
: Ionela Voinescu
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 54 ++-
include/linux/devfreq_cooling.h | 10 ++
2 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal/devfreq_cooling.c
'dynamic-power-coefficient'.
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drive
needed structures.
Reviewed-by: Ionela Voinescu
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 307 ++
include/linux/devfreq_cooling.h | 17 --
2 files changed, 97 insertions(+), 227 deletions(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b
Prepare for deleting the static and dynamic power calculation and clean
the trace function. These two fields are going to be removed in the next
changes.
Reviewed-by: Ionela Voinescu
Reviewed-by: Steven Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal
dle it
- removed dfc_em_get_requested_power() (as missed to do it in v2)
- collected all Reviewed-by tags
v2 [3]:
- renamed freq_get_state() and related to perf_idx pattern as
suggested by Ionela
v1 [2]
Regards,
Lukasz Luba
Lukasz Luba (5):
thermal: devfreq_cooling: change tracing function and
: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 99 ++-
include/linux/devfreq_cooling.h | 22 +++
2 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal/devfreq_cooling.c
index 925523694462
the status structure and use it
for internal calculations.
In addition this patch adds normalization function, which also makes sure
that whatever data comes from the device, it is in a sane range.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 52
Prepare for deleting the static and dynamic power calculation and clean
the trace function. These two fields are going to be removed in the next
changes.
Reviewed-by: Steven Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 3 +--
include
created based on DT 'dynamic-power-coefficient', voltage and frequency.
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
needed structures.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 302 ++
include/linux/devfreq_cooling.h | 17 --
2 files changed, 96 insertions(+), 223 deletions(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal
gh thermal tree,
but it's here for consistency.
The patch set is based on current next-20201118, which has new EM API
in the pm/linux-next tree.
changes:
v2:
- renamed freq_get_state() and related to perf_idx pattern as
suggested by Ionela
v1 [2]
Regards,
Lukasz Luba
[1] https://lkml.org
Hi Daniel,
Do you think it has chance to go to as material for v5.11?
Regards,
Lukasz
On 12/10/20 2:30 PM, Lukasz Luba wrote:
Hi all,
This patch set is a continuation of my previous work, which aimed
to add Energy Model to all devices [1]. This series is a follow up
for the patches which
On 12/11/20 3:15 PM, Daniel Lezcano wrote:
On 11/12/2020 16:11, Lukasz Luba wrote:
Hi Daniel,
Do you think it has chance to go to as material for v5.11?
Yes, it is in the thermal/linux-next material ATM.
Thank you!
Regards,
Lukasz
___
dri
Devfreq framework supports 2 modes for monitoring devices.
Use delayed timer as default instead of deferrable timer
in order to monitor the GPU status regardless of CPU idle.
Signed-off-by: Lukasz Luba
---
Hi all,
This is just a simple change but has impact on reliable polling mode
with
From: Lukasz Luba
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
From: Lukasz Luba
Drop the CPU specific interface with cpumask and switch to struct device.
The Energy Model framework supports both: CPUs and devfreq devices. The new
interface provides easy way to create a Energy Model (EM), which then might
be used in i.e. thermal subsystem.
Signed-off-by
From: Lukasz Luba
Add device to the Energy Model framework. It will create a dedicated
and unified data structures used i.e. in the thermal framework.
The power model used in dev_pm_opp subsystem is simplified and created
based on DT 'dynamic-power-coefficient', volatage and freque
From: Lukasz Luba
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 129 +
drivers/cpufreq/scmi-cpufreq.c
From: Lukasz Luba
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain calculation for it locally
Hi Quentin,
Thank you for the review, please find my comments below.
On 2/7/20 12:04 PM, Quentin Perret wrote:
On Thursday 06 Feb 2020 at 13:46:37 (+), lukasz.l...@arm.com wrote:
2. Core APIs
@@ -70,14 +72,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework.
Drivers are
On 2/13/20 10:59 AM, Dietmar Eggemann wrote:
On 06/02/2020 14:46, lukasz.l...@arm.com wrote:
From: Lukasz Luba
[..]
@@ -26,7 +28,7 @@ framework, and interested clients reading the data from it::
s/::/: ?
| Thermal (IPA) | | Scheduler (EAS) | | Other
Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 425 ++
include/linux/devfreq_cooling.h | 17 --
include/trace/events/thermal.h| 19 +-
3 files changed, 201 insertions(+), 260 deletions(-)
diff --git a/drivers
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
Drop the CPU specific interface with cpumask and switch to struct device.
The Energy Model framework supports both: CPUs and devfreq devices. The new
interface provides easy way to create a Energy Model (EM), which then might
be used in i.e. thermal subsystem.
Signed-off-by: Lukasz Luba
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 133
Documentation/scheduler/sched-energy.rst | 2
to the CPU model used in Energy Aware Scheduler.
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbf..d527a5113
Hi Randy,
Thank you for taking the time to look into this patch.
On 2/22/20 12:42 AM, Randy Dunlap wrote:
Hi,
One minor nit. Please see inline:
On 2/21/20 11:47 AM, Lukasz Luba wrote:
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be
On 2/26/20 1:55 PM, Robin Murphy wrote:
On 26/02/2020 10:06 am, Lukasz Luba wrote:
[...]
@@ -118,6 +120,7 @@ void panfrost_devfreq_fini(struct
panfrost_device *pfdev)
{
if (pfdev->devfreq.cooling)
devfreq_cooling_unregister(pfdev->devfreq.c
Hi Rob,
On 2/25/20 8:57 PM, Rob Herring wrote:
On Fri, Feb 21, 2020 at 1:48 PM Lukasz Luba wrote:
Add device to the Energy Model framework. It will create a dedicated
and unified data structures used i.e. in the thermal framework.
The power model used in dev_pm_opp subsystem is simplified
robe_device+0x78/0x1c4
[<7481a0cf>] device_driver_attach+0x58/0x60
[<0ff8f5c1>] __driver_attach+0xb8/0x158
[<86006144>] bus_for_each_dev+0x74/0xb4
[<10159dca>] bus_add_driver+0x1c0/0x200
[<8a265265>] driver_register+0x74/0x108
[] exynos_drm_init+0
Hi Marek,
On 3/5/20 7:07 AM, Marek Szyprowski wrote:
Hi Lukasz,
On 04.03.2020 23:00, Lukasz Luba wrote:
There is a memory leak which left some objects not freed. The reference
counter of mapping: 'mapping->kref' was 2 when calling
arm_iommu_detach_device(), so the release_
() callback of master's compound DRM driver.
Signed-off-by: Marek Szyprowski
Attaching back the old mapping looks good. The problem with leakage
is also no longer reported (you can add it to the commit message).
Reviewed-by: Lukasz Luba
Regards,
Lukasz
---
drivers/gpu/drm/e
created based on DT 'dynamic-power-coefficient', voltage and frequency.
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/dr
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 133 ---
Documentation/scheduler/sched-energy.rst | 2
Hi Inki,
On 3/9/20 12:45 AM, Inki Dae wrote:
Hi Lukasz,
20. 3. 5. 오전 7:00에 Lukasz Luba 이(가) 쓴 글:
There is a memory leak which left some objects not freed. The reference
counter of mapping: 'mapping->kref' was 2 when calling
arm_iommu_detach_device(), so the release_iommu_mappi
Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 506 --
include/linux/devfreq_cooling.h | 39 ++-
include/trace/events/thermal.h| 19 +-
3 files changed, 304 insertions(+), 260 deletions(-)
diff --git a
Drop the CPU specific interface with cpumask and switch to struct device.
The Energy Model framework supports both: CPUs and devfreq devices. The new
interface provides easy way to create a Energy Model (EM), which then might
be used in i.e. thermal subsystem.
Signed-off-by: Lukasz Luba
ide 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
Hi Quentin,
On 3/13/20 10:04 AM, Quentin Perret wrote:
Hi Lukasz,
On Monday 09 Mar 2020 at 13:41:14 (+), Lukasz Luba wrote:
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 9cd8f0adacae..0efd6cf6d023 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -1047,9 +1047,8
On 3/13/20 10:15 AM, Quentin Perret wrote:
On Monday 09 Mar 2020 at 13:41:15 (+), Lukasz Luba wrote:
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index d2b5f062a07b..676b56424886 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
On 3/9/20 2:15 PM, Steven Price wrote:
On 09/03/2020 13:41, Lukasz Luba wrote:
Register devfreq cooling device and attempt to register Energy Model. This
will add the devfreq device to the Energy Model framework. It will create
a dedicated and unified data structures used i.e. in thermal
max): PM QoS gives
precedence to the MIN_FREQUENCY request, while higher OPPs disabled
with dev_pm_opp_disable() would override MIN_FREQUENCY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Lukasz Luba
Reviewed-by: Chanwoo Choi
---
Added missing Chanwoo's Reviewed-by in posted patch v3.
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].
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Acked-by: Quentin Perret
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 133 ---
Documentation
: Lukasz Luba
---
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/scpi-cpufreq.c
Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 474 --
include/linux/devfreq_cooling.h | 39 +--
include/trace/events/thermal.h| 19 +-
3 files changed, 277 insertions(+), 255 deletions(-)
diff --git a
created based on DT 'dynamic-power-coefficient', voltage and frequency.
Reviewed-by: Steven Price
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/d
From: Lukasz Luba
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain calculation for it locally
From: Lukasz Luba
Drop the CPU specific interface with cpumask and switch to struct device.
The Energy Model framework supports both: CPUs and devfreq devices. The new
interface provides easy way to create a Energy Model (EM), which then might
be used in i.e. thermal subsystem.
Signed-off-by
From: Lukasz Luba
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
From: Lukasz Luba
Let Panfrost devfreq device use the Energy Model (EM). The EM can be used
in thermal subsystem (devfreq_cooling) for calculating the used power.
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a
From: Lukasz Luba
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 67 +++--
drivers/cpufreq/scmi-cpufreq.c
On 1/20/20 3:11 PM, Dietmar Eggemann wrote:
On 20/01/2020 15:53, Dietmar Eggemann wrote:
On 16/01/2020 16:20, lukasz.l...@arm.com wrote:
From: Lukasz Luba
[...]
+enum em_type {
+ EM_SIMPLE,
+ EM_CPU,
+};
s/EM_SIMPLE/EM_DEV ?
Right now I only see energy models and _one_
Hi Quentin,
On 1/17/20 10:54 AM, Quentin Perret wrote:
Hey Lukasz,
Still reading through this, but with small changes, this looks pretty
good to me.
On Thursday 16 Jan 2020 at 15:20:29 (+), lukasz.l...@arm.com wrote:
+int em_register_perf_domain(struct device *dev, unsigned int nr_states,
On 1/20/20 3:28 PM, Quentin Perret wrote:
On Monday 20 Jan 2020 at 15:53:35 (+0100), Dietmar Eggemann wrote:
Would be really nice if this wouldn't be required. We should really aim
for 1 framework == 1 set of interfaces.
What happens if someone calls em_get_pd() on a CPU EM?
E.g:
static
Hi Dietmar,
On 1/20/20 2:53 PM, Dietmar Eggemann wrote:
On 16/01/2020 16:20, lukasz.l...@arm.com wrote:
From: Lukasz Luba
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well
On 1/20/20 6:27 PM, Dietmar Eggemann wrote:
On 20/01/2020 16:09, Quentin Perret wrote:
Hey Lukasz,
On Monday 20 Jan 2020 at 14:52:07 (+), Lukasz Luba wrote:
On 1/17/20 10:54 AM, Quentin Perret wrote:
Suggested alternative: have two registration functions like so:
int
On 1/21/20 10:08 AM, Quentin Perret wrote:
On Monday 20 Jan 2020 at 16:20:49 (+), Lukasz Luba wrote:
On 1/20/20 3:28 PM, Quentin Perret wrote:
Agreed, this looks a bit confusing. It should be trivial to make
em_dev_get() (or whatever we end up calling it) work for CPUs too,
though. And
On 4/23/20 6:15 PM, Daniel Lezcano wrote:
On 23/04/2020 18:57, Lukasz Luba wrote:
On 4/23/20 4:12 PM, Daniel Lezcano wrote:
On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
Add support for other devices that CPUs. The registration function
does not require a valid cpumask
Hi Daniel,
On 4/23/20 2:22 PM, Daniel Lezcano wrote:
On Fri, Apr 10, 2020 at 09:42:03AM +0100, Lukasz Luba wrote:
The Energy Model framework is going to support devices other that CPUs. In
order to make this happen change the callback function and add pointer to
a device as an argument
On 4/23/20 4:12 PM, Daniel Lezcano wrote:
On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
Add support for other devices that CPUs. The registration function
does not require a valid cpumask pointer and is ready to handle new
devices. Some of the internal structures has been
Hi Daniel,
On 4/23/20 6:57 PM, Daniel Lezcano wrote:
On Fri, Apr 10, 2020 at 09:42:09AM +0100, Lukasz Luba wrote:
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power
The Energy Model framework supports also other devices than CPUs. Update
related information and add description for the new usage.
Acked-by: Daniel Lezcano
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 135 +++
1 file changed, 75 insertions
description to warn of potential wrong usage for other
devices.
Acked-by: Daniel Lezcano
Signed-off-by: Lukasz Luba
---
include/linux/energy_model.h | 11 ---
kernel/sched/fair.c | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/linux
Devfreq framework can change the device status in the background. To
mitigate this situation make a copy of the status structure and use it
for internal calculations.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 14 ++
1 file changed, 10 insertions(+), 4
1 - 100 of 170 matches
Mail list logo
