mbox series

[0/4] qcom: Model RPMH power domains as thermal cooling devices

Message ID 1565398727-23090-1-git-send-email-thara.gopinath@linaro.org (mailing list archive)
Headers show
Series qcom: Model RPMH power domains as thermal cooling devices | expand

Message

Thara Gopinath Aug. 10, 2019, 12:58 a.m. UTC
Certain RPMH power domains can be used to warm up the SoC (mx 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. To use these power domains as warming devices
require further tweaks in the thermal framework which are out of scope
of this patch series.

The first patch in this series extends the genpd framework to export out
the performance states of a power domain so that when the RPMH 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 RPMH power
domain driver.

The third patch implements the modeling of a RPMH power domain as
a cooling device and the final patch adds the device node entry for sdm845
to consider RPMHPD MX a cooling device.

Thara Gopinath (4):
  PM/Domains: Add support for retrieving genpd performance states
    information
  soc: qcom: rpmhpd: Introduce function to retrieve power domain
    performance state count
  thermal: qcom: Add RPMHPD cooling device driver.
  arm64: dts: qcom: Extend AOSS RPMHPD node

 arch/arm64/boot/dts/qcom/sdm845.dtsi    |   7 ++
 drivers/base/power/domain.c             |  38 +++++++++
 drivers/soc/qcom/rpmhpd.c               |  11 +++
 drivers/thermal/qcom/Kconfig            |   7 ++
 drivers/thermal/qcom/Makefile           |   1 +
 drivers/thermal/qcom/qcom-rpmhpd-cdev.c | 141 ++++++++++++++++++++++++++++++++
 include/linux/pm_domain.h               |  18 ++++
 7 files changed, 223 insertions(+)
 create mode 100644 drivers/thermal/qcom/qcom-rpmhpd-cdev.c

Comments

Daniel Lezcano Aug. 14, 2019, 10:52 a.m. UTC | #1
Hi Thara,

interesting series. Can you describe what use case this series will solve?

On 10/08/2019 02:58, Thara Gopinath wrote:
> Certain RPMH power domains can be used to warm up the SoC (mx on sdm845)
> if the temperature falls below certain threshold. 

What is the relationship between the temperature fall, the sensor(s)
location and the warming device(s) in this case?


> These power domains
> can be considered as thermal warming devices
> (opposite of thermal cooling devices).

Is it possible to elaborate how works the RPMH as a warming device and
what is the "mx on sdm845"?

> In kernel, these warming devices can be modeled as a 
> thermal cooling device. To use these power domains as warming devices
> require further tweaks in the thermal framework which are out of scope
> of this patch series.
> 
> The first patch in this series extends the genpd framework to export out
> the performance states of a power domain so that when the RPMH 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 RPMH power
> domain driver.
> 
> The third patch implements the modeling of a RPMH power domain as
> a cooling device and the final patch adds the device node entry for sdm845
> to consider RPMHPD MX a cooling device.
> 
> Thara Gopinath (4):
>   PM/Domains: Add support for retrieving genpd performance states
>     information
>   soc: qcom: rpmhpd: Introduce function to retrieve power domain
>     performance state count
>   thermal: qcom: Add RPMHPD cooling device driver.
>   arm64: dts: qcom: Extend AOSS RPMHPD node
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi    |   7 ++
>  drivers/base/power/domain.c             |  38 +++++++++
>  drivers/soc/qcom/rpmhpd.c               |  11 +++
>  drivers/thermal/qcom/Kconfig            |   7 ++
>  drivers/thermal/qcom/Makefile           |   1 +
>  drivers/thermal/qcom/qcom-rpmhpd-cdev.c | 141 ++++++++++++++++++++++++++++++++
>  include/linux/pm_domain.h               |  18 ++++
>  7 files changed, 223 insertions(+)
>  create mode 100644 drivers/thermal/qcom/qcom-rpmhpd-cdev.c
>
Thara Gopinath Aug. 15, 2019, 1:09 p.m. UTC | #2
On 08/14/2019 06:52 AM, Daniel Lezcano wrote:
> 
> Hi Thara
> 
> interesting series. Can you describe what use case this series will solve?
> 
> On 10/08/2019 02:58, Thara Gopinath wrote:
>> Certain RPMH power domains can be used to warm up the SoC (mx on sdm845)
>> if the temperature falls below certain threshold. 
> 
> What is the relationship between the temperature fall, the sensor(s)
> location and the warming device(s) in this case?
Hi Daniel,

Thanks for the review!

My understanding is that there are a bunch of hot-spots. If the
temperature sensors in any of these hot-spots, detect a fall
in temperature, a bunch of resources are used to warm up the entire Soc.
In this case a power domain controlled by the resource power manager
hardened (RPMh) is one of these resources used to warm up the Soc.

> 
>> These power domains
>> can be considered as thermal warming devices
>> (opposite of thermal cooling devices).
> 
> Is it possible to elaborate how works the RPMH as a warming device and
> what is the "mx on sdm845"?
RPMh is resource power manager hardened. It takes numbers between 0-15
to set the power domains to require states (like TURBO, NOMINAL etc).
The frequency and voltage of the domains are controlled by the hardware
based on the number(the number of states supported by a power domains
are in fact read from the h/w runtime).
So MX in one such power domain controlled by RPMh on sdm845 which is
used to warm up the SoC as well. MX is modeled as a regular power domain
in the linux-kernel (registered with genpd).

Regards
Thara
> 
>> In kernel, these warming devices can be modeled as a 
>> thermal cooling device. To use these power domains as warming devices
>> require further tweaks in the thermal framework which are out of scope
>> of this patch series.
>>
>> The first patch in this series extends the genpd framework to export out
>> the performance states of a power domain so that when the RPMH 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 RPMH power
>> domain driver.
>>
>> The third patch implements the modeling of a RPMH power domain as
>> a cooling device and the final patch adds the device node entry for sdm845
>> to consider RPMHPD MX a cooling device.
>>
>> Thara Gopinath (4):
>>   PM/Domains: Add support for retrieving genpd performance states
>>     information
>>   soc: qcom: rpmhpd: Introduce function to retrieve power domain
>>     performance state count
>>   thermal: qcom: Add RPMHPD cooling device driver.
>>   arm64: dts: qcom: Extend AOSS RPMHPD node
>>
>>  arch/arm64/boot/dts/qcom/sdm845.dtsi    |   7 ++
>>  drivers/base/power/domain.c             |  38 +++++++++
>>  drivers/soc/qcom/rpmhpd.c               |  11 +++
>>  drivers/thermal/qcom/Kconfig            |   7 ++
>>  drivers/thermal/qcom/Makefile           |   1 +
>>  drivers/thermal/qcom/qcom-rpmhpd-cdev.c | 141 ++++++++++++++++++++++++++++++++
>>  include/linux/pm_domain.h               |  18 ++++
>>  7 files changed, 223 insertions(+)
>>  create mode 100644 drivers/thermal/qcom/qcom-rpmhpd-cdev.c
>>
> 
>
Bjorn Andersson Aug. 24, 2019, 6 a.m. UTC | #3
On Wed 14 Aug 03:52 PDT 2019, Daniel Lezcano wrote:

> 
> Hi Thara,
> 
> interesting series. Can you describe what use case this series will solve?
> 

The purpose is to ensure a minimum voltage (voltage corner) on the
memory rail (mx) at low temperature, to meet some physical requirement.

> On 10/08/2019 02:58, Thara Gopinath wrote:
> > Certain RPMH power domains can be used to warm up the SoC (mx on sdm845)
> > if the temperature falls below certain threshold. 
> 
> What is the relationship between the temperature fall, the sensor(s)
> location and the warming device(s) in this case?
> 

Presumably any on-die sensor could be used and the minimum voltage
requirement only applies below some configurable threshold.

> 
> > These power domains
> > can be considered as thermal warming devices
> > (opposite of thermal cooling devices).
> 
> Is it possible to elaborate how works the RPMH as a warming device and
> what is the "mx on sdm845"?
> 

RPMh is the interface used to configure the voltage corner (and other
shared resources, such as regulators, interconnects etc). mx is the
"memory rail" power domain.

Regards,
Bjorn