Centos-kernel-stream-9/include/linux/dtpm.h

74 lines
1.5 KiB
C
Raw Permalink Normal View History

powercap/drivers/dtpm: Add API for dynamic thermal power management On the embedded world, the complexity of the SoC leads to an increasing number of hotspots which need to be monitored and mitigated as a whole in order to prevent the temperature to go above the normative and legally stated 'skin temperature'. Another aspect is to sustain the performance for a given power budget, for example virtual reality where the user can feel dizziness if the GPU performance is capped while a big CPU is processing something else. Or reduce the battery charging because the dissipated power is too high compared with the power consumed by other devices. The userspace is the most adequate place to dynamically act on the different devices by limiting their power given an application profile: it has the knowledge of the platform. These userspace daemons are in charge of the Dynamic Thermal Power Management (DTPM). Nowadays, the dtpm daemons are abusing the thermal framework as they act on the cooling device state to force a specific and arbitrary state without taking care of the governor decisions. Given the closed loop of some governors that can confuse the logic or directly enter in a decision conflict. As the number of cooling device support is limited today to the CPU and the GPU, the dtpm daemons have little control on the power dissipation of the system. The out of tree solutions are hacking around here and there in the drivers, in the frameworks to have control on the devices. The common solution is to declare them as cooling devices. There is no unification of the power limitation unit, opaque states are used. This patch provides a way to create a hierarchy of constraints using the powercap framework. The devices which are registered as power limit-able devices are represented in this hierarchy as a tree. They are linked together with intermediate nodes which are just there to propagate the constraint to the children. The leaves of the tree are the real devices, the intermediate nodes are virtual, aggregating the children constraints and power characteristics. Each node have a weight on a 2^10 basis, in order to reflect the percentage of power distribution of the children's node. This percentage is used to dispatch the power limit to the children. The weight is computed against the max power of the siblings. This simple approach allows to do a fair distribution of the power limit. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-08 16:41:44 +00:00
/* SPDX-License-Identifier: GPL-2.0-only */
/*
* Copyright (C) 2020 Linaro Ltd
*
* Author: Daniel Lezcano <daniel.lezcano@linaro.org>
*/
#ifndef ___DTPM_H__
#define ___DTPM_H__
#include <linux/powercap.h>
#define MAX_DTPM_DESCR 8
#define MAX_DTPM_CONSTRAINTS 1
struct dtpm {
struct powercap_zone zone;
struct dtpm *parent;
struct list_head sibling;
struct list_head children;
struct dtpm_ops *ops;
unsigned long flags;
u64 power_limit;
u64 power_max;
u64 power_min;
int weight;
};
struct dtpm_ops {
u64 (*set_power_uw)(struct dtpm *, u64);
u64 (*get_power_uw)(struct dtpm *);
powercap/drivers/dtpm: Encapsulate even more the code Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. Conflicts: include/linux/cpuhotplug.h The enums are just in a very different order in this tree, so context was way off, and in this case, the one enum being added had already been added elsewhere in the file. commit 4570ddda43387e5a130dd85e71a1947b0c11da77 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Fri Mar 12 14:04:07 2021 +0100 powercap/drivers/dtpm: Encapsulate even more the code In order to increase the self-encapsulation of the dtpm generic code, the following changes are adding a power update ops to the dtpm ops. That allows the generic code to call directly the dtpm backend function to update the power values. The power update function does compute the power characteristics when the function is invoked. In the case of the CPUs, the power consumption depends on the number of online CPUs. The online CPUs mask is not up to date at CPUHP_AP_ONLINE_DYN state in the tear down callback. That is the reason why the online / offline are at separate state. As there is already an existing state for DTPM, this one is only moved to the DEAD state, so there is no addition of new state with these changes. The dtpm node is not removed when the cpu is unplugged. That simplifies the code for the next changes and results in a more self-encapsulated code. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20210312130411.29833-1-daniel.lezcano@linaro.org (cherry picked from commit 4570ddda43387e5a130dd85e71a1947b0c11da77) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:47 +00:00
int (*update_power_uw)(struct dtpm *);
powercap/drivers/dtpm: Add API for dynamic thermal power management On the embedded world, the complexity of the SoC leads to an increasing number of hotspots which need to be monitored and mitigated as a whole in order to prevent the temperature to go above the normative and legally stated 'skin temperature'. Another aspect is to sustain the performance for a given power budget, for example virtual reality where the user can feel dizziness if the GPU performance is capped while a big CPU is processing something else. Or reduce the battery charging because the dissipated power is too high compared with the power consumed by other devices. The userspace is the most adequate place to dynamically act on the different devices by limiting their power given an application profile: it has the knowledge of the platform. These userspace daemons are in charge of the Dynamic Thermal Power Management (DTPM). Nowadays, the dtpm daemons are abusing the thermal framework as they act on the cooling device state to force a specific and arbitrary state without taking care of the governor decisions. Given the closed loop of some governors that can confuse the logic or directly enter in a decision conflict. As the number of cooling device support is limited today to the CPU and the GPU, the dtpm daemons have little control on the power dissipation of the system. The out of tree solutions are hacking around here and there in the drivers, in the frameworks to have control on the devices. The common solution is to declare them as cooling devices. There is no unification of the power limitation unit, opaque states are used. This patch provides a way to create a hierarchy of constraints using the powercap framework. The devices which are registered as power limit-able devices are represented in this hierarchy as a tree. They are linked together with intermediate nodes which are just there to propagate the constraint to the children. The leaves of the tree are the real devices, the intermediate nodes are virtual, aggregating the children constraints and power characteristics. Each node have a weight on a 2^10 basis, in order to reflect the percentage of power distribution of the children's node. This percentage is used to dispatch the power limit to the children. The weight is computed against the max power of the siblings. This simple approach allows to do a fair distribution of the power limit. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-08 16:41:44 +00:00
void (*release)(struct dtpm *);
};
powercap/drivers/dtpm: Add hierarchy creation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. commit 3759ec678e8944dc2ea70cab77a300408f78ae27 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Fri Jan 28 17:35:34 2022 +0100 powercap/drivers/dtpm: Add hierarchy creation The DTPM framework is available but without a way to configure it. This change provides a way to create a hierarchy of DTPM node where the power consumption reflects the sum of the children's power consumption. It is up to the platform to specify an array of dtpm nodes where each element has a pointer to its parent, except the top most one. The type of the node gives the indication of which initialization callback to call. At this time, we can create a virtual node, where its purpose is to be a parent in the hierarchy, and a DT node where the name describes its path. In order to ensure a nice self-encapsulation, the DTPM subsys array contains a couple of initialization functions, one to setup the DTPM backend and one to initialize it up. With this approach, the DTPM framework has a very few material to export. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20220128163537.212248-3-daniel.lezcano@linaro.org (cherry picked from commit 3759ec678e8944dc2ea70cab77a300408f78ae27) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:51 +00:00
struct device_node;
powercap/drivers/dtpm: Convert the init table section to a simple array Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. commit b9794a822281944ef3de5b1812a94cbdb8134320 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Fri Jan 28 17:35:33 2022 +0100 powercap/drivers/dtpm: Convert the init table section to a simple array The init table section is freed after the system booted. However the next changes will make per module the DTPM description, so the table won't be accessible when the module is loaded. In order to fix that, we should move the table to the data section where there are very few entries and that makes strange to add it there. The main goal of the table was to keep self-encapsulated code and we can keep it almost as it by using an array instead. Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20220128163537.212248-2-daniel.lezcano@linaro.org (cherry picked from commit b9794a822281944ef3de5b1812a94cbdb8134320) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:51 +00:00
struct dtpm_subsys_ops {
const char *name;
int (*init)(void);
powercap/dtpm: Destroy hierarchy function Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. commit c404c64d64bc31bebe8a2015103671f7cd282731 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Sun Jan 30 22:02:06 2022 +0100 powercap/dtpm: Destroy hierarchy function The hierarchy creation function exits but without a destroy hierarchy function. Due to that, the modules creating the hierarchy can not be unloaded properly because they don't have an exit callback. Provide the dtpm_destroy_hierarchy() function to remove the previously created hierarchy. The function relies on all the release mechanisms implemented by the underlying powercap framework. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20220130210210.549877-4-daniel.lezcano@linaro.org (cherry picked from commit c404c64d64bc31bebe8a2015103671f7cd282731) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:53 +00:00
void (*exit)(void);
powercap/drivers/dtpm: Add hierarchy creation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. commit 3759ec678e8944dc2ea70cab77a300408f78ae27 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Fri Jan 28 17:35:34 2022 +0100 powercap/drivers/dtpm: Add hierarchy creation The DTPM framework is available but without a way to configure it. This change provides a way to create a hierarchy of DTPM node where the power consumption reflects the sum of the children's power consumption. It is up to the platform to specify an array of dtpm nodes where each element has a pointer to its parent, except the top most one. The type of the node gives the indication of which initialization callback to call. At this time, we can create a virtual node, where its purpose is to be a parent in the hierarchy, and a DT node where the name describes its path. In order to ensure a nice self-encapsulation, the DTPM subsys array contains a couple of initialization functions, one to setup the DTPM backend and one to initialize it up. With this approach, the DTPM framework has a very few material to export. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20220128163537.212248-3-daniel.lezcano@linaro.org (cherry picked from commit 3759ec678e8944dc2ea70cab77a300408f78ae27) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:51 +00:00
int (*setup)(struct dtpm *, struct device_node *);
};
enum DTPM_NODE_TYPE {
DTPM_NODE_VIRTUAL = 0,
DTPM_NODE_DT,
};
struct dtpm_node {
enum DTPM_NODE_TYPE type;
const char *name;
struct dtpm_node *parent;
powercap/drivers/dtpm: Add API for dynamic thermal power management On the embedded world, the complexity of the SoC leads to an increasing number of hotspots which need to be monitored and mitigated as a whole in order to prevent the temperature to go above the normative and legally stated 'skin temperature'. Another aspect is to sustain the performance for a given power budget, for example virtual reality where the user can feel dizziness if the GPU performance is capped while a big CPU is processing something else. Or reduce the battery charging because the dissipated power is too high compared with the power consumed by other devices. The userspace is the most adequate place to dynamically act on the different devices by limiting their power given an application profile: it has the knowledge of the platform. These userspace daemons are in charge of the Dynamic Thermal Power Management (DTPM). Nowadays, the dtpm daemons are abusing the thermal framework as they act on the cooling device state to force a specific and arbitrary state without taking care of the governor decisions. Given the closed loop of some governors that can confuse the logic or directly enter in a decision conflict. As the number of cooling device support is limited today to the CPU and the GPU, the dtpm daemons have little control on the power dissipation of the system. The out of tree solutions are hacking around here and there in the drivers, in the frameworks to have control on the devices. The common solution is to declare them as cooling devices. There is no unification of the power limitation unit, opaque states are used. This patch provides a way to create a hierarchy of constraints using the powercap framework. The devices which are registered as power limit-able devices are represented in this hierarchy as a tree. They are linked together with intermediate nodes which are just there to propagate the constraint to the children. The leaves of the tree are the real devices, the intermediate nodes are virtual, aggregating the children constraints and power characteristics. Each node have a weight on a 2^10 basis, in order to reflect the percentage of power distribution of the children's node. This percentage is used to dispatch the power limit to the children. The weight is computed against the max power of the siblings. This simple approach allows to do a fair distribution of the power limit. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-08 16:41:44 +00:00
};
static inline struct dtpm *to_dtpm(struct powercap_zone *zone)
{
return container_of(zone, struct dtpm, zone);
}
powercap/drivers/dtpm: Encapsulate even more the code Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. Conflicts: include/linux/cpuhotplug.h The enums are just in a very different order in this tree, so context was way off, and in this case, the one enum being added had already been added elsewhere in the file. commit 4570ddda43387e5a130dd85e71a1947b0c11da77 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Fri Mar 12 14:04:07 2021 +0100 powercap/drivers/dtpm: Encapsulate even more the code In order to increase the self-encapsulation of the dtpm generic code, the following changes are adding a power update ops to the dtpm ops. That allows the generic code to call directly the dtpm backend function to update the power values. The power update function does compute the power characteristics when the function is invoked. In the case of the CPUs, the power consumption depends on the number of online CPUs. The online CPUs mask is not up to date at CPUHP_AP_ONLINE_DYN state in the tear down callback. That is the reason why the online / offline are at separate state. As there is already an existing state for DTPM, this one is only moved to the DEAD state, so there is no addition of new state with these changes. The dtpm node is not removed when the cpu is unplugged. That simplifies the code for the next changes and results in a more self-encapsulated code. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20210312130411.29833-1-daniel.lezcano@linaro.org (cherry picked from commit 4570ddda43387e5a130dd85e71a1947b0c11da77) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:47 +00:00
int dtpm_update_power(struct dtpm *dtpm);
powercap/drivers/dtpm: Add API for dynamic thermal power management On the embedded world, the complexity of the SoC leads to an increasing number of hotspots which need to be monitored and mitigated as a whole in order to prevent the temperature to go above the normative and legally stated 'skin temperature'. Another aspect is to sustain the performance for a given power budget, for example virtual reality where the user can feel dizziness if the GPU performance is capped while a big CPU is processing something else. Or reduce the battery charging because the dissipated power is too high compared with the power consumed by other devices. The userspace is the most adequate place to dynamically act on the different devices by limiting their power given an application profile: it has the knowledge of the platform. These userspace daemons are in charge of the Dynamic Thermal Power Management (DTPM). Nowadays, the dtpm daemons are abusing the thermal framework as they act on the cooling device state to force a specific and arbitrary state without taking care of the governor decisions. Given the closed loop of some governors that can confuse the logic or directly enter in a decision conflict. As the number of cooling device support is limited today to the CPU and the GPU, the dtpm daemons have little control on the power dissipation of the system. The out of tree solutions are hacking around here and there in the drivers, in the frameworks to have control on the devices. The common solution is to declare them as cooling devices. There is no unification of the power limitation unit, opaque states are used. This patch provides a way to create a hierarchy of constraints using the powercap framework. The devices which are registered as power limit-able devices are represented in this hierarchy as a tree. They are linked together with intermediate nodes which are just there to propagate the constraint to the children. The leaves of the tree are the real devices, the intermediate nodes are virtual, aggregating the children constraints and power characteristics. Each node have a weight on a 2^10 basis, in order to reflect the percentage of power distribution of the children's node. This percentage is used to dispatch the power limit to the children. The weight is computed against the max power of the siblings. This simple approach allows to do a fair distribution of the power limit. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-08 16:41:44 +00:00
int dtpm_release_zone(struct powercap_zone *pcz);
powercap/drivers/dtpm: Use container_of instead of a private data field Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. commit d2cdc6adc30879d81160199fc7c6ab890fc4bd4c Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Fri Mar 12 14:04:10 2021 +0100 powercap/drivers/dtpm: Use container_of instead of a private data field The dtpm framework provides an API to allocate a dtpm node. However when a backend dtpm driver needs to allocate a dtpm node it must define its own structure and store the pointer of this structure in the private field of the dtpm structure. It is more elegant to use the container_of macro and add the dtpm structure inside the dtpm backend specific structure. The code will be able to deal properly with the dtpm structure as a generic entity, making all this even more self-encapsulated. The dtpm_alloc() function does no longer make sense as the dtpm structure will be allocated when allocating the device specific dtpm structure. The dtpm_init() is provided instead. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20210312130411.29833-4-daniel.lezcano@linaro.org (cherry picked from commit d2cdc6adc30879d81160199fc7c6ab890fc4bd4c) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:48 +00:00
void dtpm_init(struct dtpm *dtpm, struct dtpm_ops *ops);
powercap/drivers/dtpm: Add API for dynamic thermal power management On the embedded world, the complexity of the SoC leads to an increasing number of hotspots which need to be monitored and mitigated as a whole in order to prevent the temperature to go above the normative and legally stated 'skin temperature'. Another aspect is to sustain the performance for a given power budget, for example virtual reality where the user can feel dizziness if the GPU performance is capped while a big CPU is processing something else. Or reduce the battery charging because the dissipated power is too high compared with the power consumed by other devices. The userspace is the most adequate place to dynamically act on the different devices by limiting their power given an application profile: it has the knowledge of the platform. These userspace daemons are in charge of the Dynamic Thermal Power Management (DTPM). Nowadays, the dtpm daemons are abusing the thermal framework as they act on the cooling device state to force a specific and arbitrary state without taking care of the governor decisions. Given the closed loop of some governors that can confuse the logic or directly enter in a decision conflict. As the number of cooling device support is limited today to the CPU and the GPU, the dtpm daemons have little control on the power dissipation of the system. The out of tree solutions are hacking around here and there in the drivers, in the frameworks to have control on the devices. The common solution is to declare them as cooling devices. There is no unification of the power limitation unit, opaque states are used. This patch provides a way to create a hierarchy of constraints using the powercap framework. The devices which are registered as power limit-able devices are represented in this hierarchy as a tree. They are linked together with intermediate nodes which are just there to propagate the constraint to the children. The leaves of the tree are the real devices, the intermediate nodes are virtual, aggregating the children constraints and power characteristics. Each node have a weight on a 2^10 basis, in order to reflect the percentage of power distribution of the children's node. This percentage is used to dispatch the power limit to the children. The weight is computed against the max power of the siblings. This simple approach allows to do a fair distribution of the power limit. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-08 16:41:44 +00:00
void dtpm_unregister(struct dtpm *dtpm);
int dtpm_register(const char *name, struct dtpm *dtpm, struct dtpm *parent);
powercap/drivers/dtpm: Add hierarchy creation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. commit 3759ec678e8944dc2ea70cab77a300408f78ae27 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Fri Jan 28 17:35:34 2022 +0100 powercap/drivers/dtpm: Add hierarchy creation The DTPM framework is available but without a way to configure it. This change provides a way to create a hierarchy of DTPM node where the power consumption reflects the sum of the children's power consumption. It is up to the platform to specify an array of dtpm nodes where each element has a pointer to its parent, except the top most one. The type of the node gives the indication of which initialization callback to call. At this time, we can create a virtual node, where its purpose is to be a parent in the hierarchy, and a DT node where the name describes its path. In order to ensure a nice self-encapsulation, the DTPM subsys array contains a couple of initialization functions, one to setup the DTPM backend and one to initialize it up. With this approach, the DTPM framework has a very few material to export. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20220128163537.212248-3-daniel.lezcano@linaro.org (cherry picked from commit 3759ec678e8944dc2ea70cab77a300408f78ae27) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:51 +00:00
int dtpm_create_hierarchy(struct of_device_id *dtpm_match_table);
powercap/dtpm: Destroy hierarchy function Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2126952 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for compliant platforms. This set cleans up powercap and enables DTPM for edge systems to use in thermal and power management; this is all in drivers/powercap. This set has been tested via simple boot tests, and of course the CI loop. This may be difficult to test on Arm due to DTPM being a very new feature. However, this is exactly the same powercap framework used by intel_rapl, which should continue to function properly regardless. commit c404c64d64bc31bebe8a2015103671f7cd282731 Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Sun Jan 30 22:02:06 2022 +0100 powercap/dtpm: Destroy hierarchy function The hierarchy creation function exits but without a destroy hierarchy function. Due to that, the modules creating the hierarchy can not be unloaded properly because they don't have an exit callback. Provide the dtpm_destroy_hierarchy() function to remove the previously created hierarchy. The function relies on all the release mechanisms implemented by the underlying powercap framework. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20220130210210.549877-4-daniel.lezcano@linaro.org (cherry picked from commit c404c64d64bc31bebe8a2015103671f7cd282731) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-09-16 16:47:53 +00:00
void dtpm_destroy_hierarchy(void);
powercap/drivers/dtpm: Add API for dynamic thermal power management On the embedded world, the complexity of the SoC leads to an increasing number of hotspots which need to be monitored and mitigated as a whole in order to prevent the temperature to go above the normative and legally stated 'skin temperature'. Another aspect is to sustain the performance for a given power budget, for example virtual reality where the user can feel dizziness if the GPU performance is capped while a big CPU is processing something else. Or reduce the battery charging because the dissipated power is too high compared with the power consumed by other devices. The userspace is the most adequate place to dynamically act on the different devices by limiting their power given an application profile: it has the knowledge of the platform. These userspace daemons are in charge of the Dynamic Thermal Power Management (DTPM). Nowadays, the dtpm daemons are abusing the thermal framework as they act on the cooling device state to force a specific and arbitrary state without taking care of the governor decisions. Given the closed loop of some governors that can confuse the logic or directly enter in a decision conflict. As the number of cooling device support is limited today to the CPU and the GPU, the dtpm daemons have little control on the power dissipation of the system. The out of tree solutions are hacking around here and there in the drivers, in the frameworks to have control on the devices. The common solution is to declare them as cooling devices. There is no unification of the power limitation unit, opaque states are used. This patch provides a way to create a hierarchy of constraints using the powercap framework. The devices which are registered as power limit-able devices are represented in this hierarchy as a tree. They are linked together with intermediate nodes which are just there to propagate the constraint to the children. The leaves of the tree are the real devices, the intermediate nodes are virtual, aggregating the children constraints and power characteristics. Each node have a weight on a 2^10 basis, in order to reflect the percentage of power distribution of the children's node. This percentage is used to dispatch the power limit to the children. The weight is computed against the max power of the siblings. This simple approach allows to do a fair distribution of the power limit. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-08 16:41:44 +00:00
#endif