Certain resources modeled as a generic power domain in linux kernel can be
used to warm up the SoC (mx power domain on sdm845) if the temperature
falls below certain threshold. These power domains can be considered as
thermal warming devices. (opposite of thermal cooling devices).
In kernel, these warming devices can be modeled as a thermal cooling
device. Since linux kernel today has no instance of a resource modeled as
a power domain acting as a thermal warming device, a generic power domain
based thermal warming device driver that can be used pan-Socs is the
approach taken in this patch series. Since thermal warming devices can be
thought of as the mirror opposite of thermal cooling devices, this patch
series re-uses thermal cooling device framework. To use these power
domains as warming devices require further tweaks in the thermal framework
which are out of scope of this patch series. These tweaks have been posted
as a separate series[1].
The first patch in this series extends the genpd framework to export out
the performance states of a power domain so that when a power domain is
modeled as a cooling device, the number of possible states and current
state of the cooling device can be retrieved from the genpd framework.
The second patch implements the newly added genpd callback for Qualcomm
RPMH power domain driver which hosts the mx power domain.
The third patch introduces a new cooling device register API that allows
a parent to be specified for the cooling device.
The fourth patch introduces the generic power domain warming device
driver.
The fifth patch extends Qualcomm RPMh power controller driver to register
mx power domain as a thermal warming device in the kernel.
The sixth patch describes the dt binding extensions for mx power domain to
be a thermal warming device.
The seventh patch introduces the DT entreis for sdm845 to register mx
power domain as a thermal warming device.
v1->v2:
- Rename the patch series from "qcom: Model RPMH power domains as
thermal cooling devices" to "Introduce Power domain based
thermal warming devices" as it is more appropriate.
- Introduce a new patch(patch 3) describing the dt-bindings for
generic power domain warming device.
- Patch specific changes mentioned in respective patches.
v2->v3:
- Changed power domain warming device from a virtual device node
entry in DT to being a subnode of power domain controller
binding following Rob's review comments.
- Implemented Ulf's review comments.
- The changes above introduced two new patches (patch 3 and 4)
v3->v4:
- Dropped late_init hook in cooling device ops. Instead introduced
a new cooling device register API that allows to define a parent
for the cooling device.
- Patch specific changes mentioned in respective patches.
v4->v5:
- Dropped the patch that introduced the cooling device register
API with parent as per review comments from Ulf.
- Patch specific changes mentioned in respective patches.
v5->v6:
- Rebased to latest kernel
- Few other fixes identified in the review process mentioned in
respective patches
1. https://lkml.org/lkml/2019/9/18/1180
Thara Gopinath (6):
PM/Domains: Add support for retrieving genpd performance states
information
soc: qcom: rpmhpd: Introduce function to retrieve power domain
performance state count
thermal: Add generic power domain warming device driver.
soc: qcom: Extend RPMh power controller driver to register warming
devices.
dt-bindings: power: Extend RPMh power controller binding to describe
thermal warming device
arm64: dts: qcom: Indicate rpmhpd hosts a power domain that can be
used as a warming device.
.../devicetree/bindings/power/qcom,rpmpd.yaml | 3 +
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
drivers/base/power/domain.c | 37 ++++
drivers/soc/qcom/rpmhpd.c | 25 ++-
drivers/thermal/Kconfig | 10 ++
drivers/thermal/Makefile | 4 +
drivers/thermal/pd_warming.c | 169 ++++++++++++++++++
include/linux/pd_warming.h | 29 +++
include/linux/pm_domain.h | 13 ++
9 files changed, 290 insertions(+), 1 deletion(-)
create mode 100644 drivers/thermal/pd_warming.c
create mode 100644 include/linux/pd_warming.h
--
2.20.1
RPMh power control hosts power domains that can be used as
thermal warming devices. Register these power domains
with the generic power domain warming device thermal framework.
Signed-off-by: Thara Gopinath <[email protected]>
---
v3->v4:
- Introduce a boolean value is_warming_dev in rpmhpd structure to
indicate if a generic power domain can be used as a warming
device or not.With this change, device tree no longer has to
specify which power domain inside the rpmh power domain provider
is a warming device.
- Move registering of warming devices into a late initcall to
ensure that warming devices are registered after thermal
framework is initialized.
v5->v6:
- Moved back registering of warming devices into probe since
Bjorn pointed out that now the driver can be initialized as
as a module, late_initcall will not work. Thermal framework
takes care of binding a cooling device to a thermal zone even
if the cooling device is registered before the thermal framework
is initialized.
drivers/soc/qcom/rpmhpd.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index a9c597143525..29e1eb4d11af 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -12,6 +12,7 @@
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
+#include <linux/pd_warming.h>
#include <soc/qcom/cmd-db.h>
#include <soc/qcom/rpmh.h>
#include <dt-bindings/power/qcom-rpmpd.h>
@@ -49,6 +50,7 @@ struct rpmhpd {
bool enabled;
const char *res_name;
u32 addr;
+ bool is_warming_dev;
};
struct rpmhpd_desc {
@@ -90,6 +92,7 @@ static struct rpmhpd sdm845_mx = {
.pd = { .name = "mx", },
.peer = &sdm845_mx_ao,
.res_name = "mx.lvl",
+ .is_warming_dev = true,
};
static struct rpmhpd sdm845_mx_ao = {
@@ -472,7 +475,19 @@ static int rpmhpd_probe(struct platform_device *pdev)
&rpmhpds[i]->pd);
}
- return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
+ ret = of_genpd_add_provider_onecell(pdev->dev.of_node, data);
+
+ if (ret)
+ return ret;
+
+ if (!of_find_property(dev->of_node, "#cooling-cells", NULL))
+ return 0;
+
+ for (i = 0; i < num_pds; i++)
+ if (rpmhpds[i]->is_warming_dev)
+ of_pd_warming_register(rpmhpds[i]->dev, i);
+
+ return 0;
}
static struct platform_driver rpmhpd_driver = {
--
2.20.1
On Thu, 4 Jun 2020 at 03:53, Thara Gopinath <[email protected]> wrote:
>
> RPMh power control hosts power domains that can be used as
> thermal warming devices. Register these power domains
> with the generic power domain warming device thermal framework.
>
> Signed-off-by: Thara Gopinath <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Kind regards
Uffe
> ---
>
> v3->v4:
> - Introduce a boolean value is_warming_dev in rpmhpd structure to
> indicate if a generic power domain can be used as a warming
> device or not.With this change, device tree no longer has to
> specify which power domain inside the rpmh power domain provider
> is a warming device.
> - Move registering of warming devices into a late initcall to
> ensure that warming devices are registered after thermal
> framework is initialized.
>
> v5->v6:
> - Moved back registering of warming devices into probe since
> Bjorn pointed out that now the driver can be initialized as
> as a module, late_initcall will not work. Thermal framework
> takes care of binding a cooling device to a thermal zone even
> if the cooling device is registered before the thermal framework
> is initialized.
>
> drivers/soc/qcom/rpmhpd.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
> index a9c597143525..29e1eb4d11af 100644
> --- a/drivers/soc/qcom/rpmhpd.c
> +++ b/drivers/soc/qcom/rpmhpd.c
> @@ -12,6 +12,7 @@
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/pm_opp.h>
> +#include <linux/pd_warming.h>
> #include <soc/qcom/cmd-db.h>
> #include <soc/qcom/rpmh.h>
> #include <dt-bindings/power/qcom-rpmpd.h>
> @@ -49,6 +50,7 @@ struct rpmhpd {
> bool enabled;
> const char *res_name;
> u32 addr;
> + bool is_warming_dev;
> };
>
> struct rpmhpd_desc {
> @@ -90,6 +92,7 @@ static struct rpmhpd sdm845_mx = {
> .pd = { .name = "mx", },
> .peer = &sdm845_mx_ao,
> .res_name = "mx.lvl",
> + .is_warming_dev = true,
> };
>
> static struct rpmhpd sdm845_mx_ao = {
> @@ -472,7 +475,19 @@ static int rpmhpd_probe(struct platform_device *pdev)
> &rpmhpds[i]->pd);
> }
>
> - return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
> + ret = of_genpd_add_provider_onecell(pdev->dev.of_node, data);
> +
> + if (ret)
> + return ret;
> +
> + if (!of_find_property(dev->of_node, "#cooling-cells", NULL))
> + return 0;
> +
> + for (i = 0; i < num_pds; i++)
> + if (rpmhpds[i]->is_warming_dev)
> + of_pd_warming_register(rpmhpds[i]->dev, i);
> +
> + return 0;
> }
>
> static struct platform_driver rpmhpd_driver = {
> --
> 2.20.1
>
Hi!
> Certain resources modeled as a generic power domain in linux kernel can be
> used to warm up the SoC (mx power domain on sdm845) if the temperature
> falls below certain threshold. These power domains can be considered as
> thermal warming devices. (opposite of thermal cooling devices).
Would you explain when this is needed?
I'd normally expect "too low" temperature to be a problem during power-on, but at
that time Linux is not running so it can not provide the heating...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 6/16/20 6:53 AM, Pavel Machek wrote:
> Hi!
>
>> Certain resources modeled as a generic power domain in linux kernel can be
>> used to warm up the SoC (mx power domain on sdm845) if the temperature
>> falls below certain threshold. These power domains can be considered as
>> thermal warming devices. (opposite of thermal cooling devices).
>
> Would you explain when this is needed?
>
> I'd normally expect "too low" temperature to be a problem during power-on, but at
> that time Linux is not running so it can not provide the heating...
Hi Pavel,
This is more in the scenario if the system in on and temperature is
dipping (I have been told in colder climates). Idea is to turn on
resources so as to prevent further dipping of temperature if possible.
>
> Best regards,
>
> Pavel
>
--
Warm Regards
Thara
Hi!
> >>falls below certain threshold. These power domains can be considered as
> >>thermal warming devices. (opposite of thermal cooling devices).
> >
> >Would you explain when this is needed?
> >
> >I'd normally expect "too low" temperature to be a problem during power-on, but at
> >that time Linux is not running so it can not provide the heating...
> Hi Pavel,
>
> This is more in the scenario if the system in on and temperature is dipping
> (I have been told in colder climates). Idea is to turn on resources so as to
> prevent further dipping of temperature if possible.
I guess even that makes sense...
But, out of curiosity, do you know which kind of device is that and in what
kind of environment? I mean, theoretically it may make sense on a cellphone,
but... I guess you have some fun device and would like to know what it is :-).
Hmm. And we can make this quite generic.
while (too_cold())
barrier();
Wasting power is really easy :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html