On 02/10/2023 18:13, Manivannan Sadhasivam wrote:
On Mon, Oct 02, 2023 at 07:00:27PM +0300, Dmitry Baryshkov wrote:
On Mon, 2 Oct 2023 at 18:58, Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
On Mon, Oct 02, 2023 at 06:00:37PM +0300, Dmitry Baryshkov wrote:
On Mon, 2 Oct 2023 at 17:52, Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
On Sun, Oct 01, 2023 at 06:26:14PM +0100, Caleb Connolly wrote:
On 01/10/2023 16:57, Manivannan Sadhasivam wrote:
On Fri, Sep 29, 2023 at 05:16:16PM +0100, Caleb Connolly wrote:
The Thermal Mitigation Device (TMD) Service is a QMI service that runs
on remote subsystems (the modem and DSPs) on Qualcomm SoCs.
It exposes various mitigations including passive thermal controls and
rail voltage restrictions.
This series introduces support for exposing TMDs as cooling devices
in the kernel through the thermal framework, using the QMI interface.
Each TMD client is described as a child of the remoteproc node in
devicetree. With subnodes for each control.
Daniel expressed concerns in the past aganist representing TMD driver as a
cooling device since it is not tied to thermal zones and the governors cannot
use it. Instead he suggested to represent it as a powercap device with thermal
constraints.
Hi Mani,
Forgive me as I'm not yet super familiar with the thermal subsystem.
As I understand it, the DT layout here enables each control to be referenced
under the thermal zones, at least this is the approach taken in CAF 4.9.
Maybe I don't quite understand what you mean, are you saying that using
thermal zones is the wrong approach?
Thermal framework expects each thermal zone represented in DT to have atleast
one corresponding thermal sensor defined using "thermal-sensors" property. But
with TMD, there is no thermal sensor AFAIK.
As far as I understand, no. It is perfectly fine to have 'cooling'
devices, which react to external thermal monitoring events. I might be
mistaken, but I think that is the case here, isn't it?
Yes it is represented as cooling device(s). But I do not see any cognizant way
to plug it with thermal zones i.e., unless TMD itself reports temperature of the
modem, using it as a cooling device for external temperature events doesn't
sound good to me.
Why? We have compute, q6, wlan tsens sensors. So it seems natural to
tell CDSP to slow down if compute sensor reports overheating.
TMD is for external devices such as PCIe modems as well. Is there a temperature
sensor for that?
Is could, for example NVMe does.
But here Caleb only exposes the internal DSP over the TMD as cooling devices, so
it matches the tsens input we have.
Neil
- Mani
- Mani
So please look into that approach.
Any recommended reading? Or drivers I can use as a reference?
drivers/powercap/arm_scmi_powercap.c seems to be a good reference.
- Mani
Thanks
- Mani
This series is based on previous work by Bhupesh Sharma which can be
found at [1]. I'm sending this as a fresh series as it has been a
year since the original version and I have rewritten most of the driver.
[1]: https://lore.kernel.org/linux-arm-msm/20220912085049.3517140-1-bhupesh.sharma@xxxxxxxxxx/
---
Caleb Connolly (4):
remoteproc: qcom: probe all child devices
dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
thermal: qcom: add qmi-cooling driver
MAINTAINERS: Add entry for Qualcomm Cooling Driver
.../bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 13 +
.../bindings/remoteproc/qcom,pas-common.yaml | 6 +
.../bindings/thermal/qcom,qmi-cooling.yaml | 168 +++++++
MAINTAINERS | 8 +
drivers/remoteproc/qcom_q6v5.c | 4 +
drivers/remoteproc/qcom_q6v5_mss.c | 8 -
drivers/thermal/qcom/Kconfig | 13 +
drivers/thermal/qcom/Makefile | 1 +
drivers/thermal/qcom/qmi-cooling.c | 520 +++++++++++++++++++++
drivers/thermal/qcom/qmi-cooling.h | 428 +++++++++++++++++
10 files changed, 1161 insertions(+), 8 deletions(-)
---
base-commit: 9067f80db58bbce81d5f0703aa2fd261e88bc812
// Caleb (they/them)
--
// Caleb (they/them)
--
மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
--
மணிவண்ணன் சதாசிவம்
--
With best wishes
Dmitry
