| Message ID | 1565398727-23090-1-git-send-email-thara.gopinath@linaro.org |
|---|---|
| Headers | show |
| Series | qcom: Model RPMH power domains as thermal cooling devices | expand |
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 > -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
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 >> > > -- Regards Thara
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
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 -- 2.1.4