public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Biju Das <biju.das.jz@bp.renesas.com>,
	"Claudiu.Beznea" <claudiu.beznea@tuxon.dev>
Cc: "rafael@kernel.org" <rafael@kernel.org>,
	"rui.zhang@intel.com" <rui.zhang@intel.com>,
	"lukasz.luba@arm.com" <lukasz.luba@arm.com>,
	"robh@kernel.org" <robh@kernel.org>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"magnus.damm@gmail.com" <magnus.damm@gmail.com>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Subject: Re: [PATCH 2/6] thermal: of: Export non-devres helper to register/unregister thermal zone
Date: Thu, 30 Jan 2025 18:31:53 +0100	[thread overview]
Message-ID: <867eb310-11a7-48bd-b2fa-35e001875498@linaro.org> (raw)
In-Reply-To: <TY3PR01MB11346E087A4DFCC5BDCCB10B486E92@TY3PR01MB11346.jpnprd01.prod.outlook.com>

On 30/01/2025 11:33, Biju Das wrote:
> Hi Daniel Lezcano,
> 
>> -----Original Message-----

[ ... ]

>>>> I've been through the driver before responding to this change. What
>>>> is the benefit of powering down / up (or clock off / on) the thermal
>>>> sensor when reading the temperature ?
>>>>
>>>> I can understand for disable / enable but I don't get for the
>>>> classic usage where a governor will be reading the temperature regularly.
>>>
>>> I tried to be as power saving as possible both at runtime and after
>>> the IP is not used anymore as the HW manual doesn't mentioned anything
>>> about accuracy or implications of disabling the IP clock at runtime.
>>> We use similar approach (of disabling clocks at runtime) for other IPs
>>> in the RZ/G3S SoC as well.
>>>
>>>>
>>>> Would the IP need some cycles to capture the temperature accurately
>>>> after the clock is enabled ?
>>>
>>> There is nothing about this mentioned about this in the HW manual of
>>> the RZ/G3S SoC. The only points mentioned are as described in the driver code:
>>> - wait at least 3us after each IIO channel read
>>> - wait at least 30us after enabling the sensor
>>> - wait at least 50us after setting OE bit in TSU_SM
>>>
>>> For this I chose to have it implemented as proposed.
>>
>> IMO, disabling/enabling the clock between two reads through the pm runtime may not be a good thing,
>> especially if the system enters a thermal situation where it has to mitigate.
> 
> Just a question, You mean to avoid device destruction due to high temperature?? Assuming disabling the clk happens
> when the temp reaches the boundary and re-enabling of the clk after a time(which involves monitoring the CLK ON
> bit after enabling it, or a run time enable failure happens), where it exceeds the threshold??


Well, I have some comments with the device tree thermal configuration 
which may answer your question but I'll wait for Claudiu to check the 
temperature read comparison without rounding to 0.5°C

What I meant is if the temperature read is inaccurate, the mitigation 
will be inaccurate too. It may not reach the critical temperature but it 
is possible the performance could be impacted negatively under thermal 
stress.



-- 
<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

  reply	other threads:[~2025-01-30 17:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-03 16:37 [PATCH 0/6] thermal: renesas: Add support for RZ/G3S Claudiu
2025-01-03 16:38 ` [PATCH 1/6] clk: renesas: r9a08g045: Add clocks, resets and power domain support for the TSU IP Claudiu
2025-01-10 14:16   ` Geert Uytterhoeven
2025-01-03 16:38 ` [PATCH 2/6] thermal: of: Export non-devres helper to register/unregister thermal zone Claudiu
2025-01-09 17:34   ` Daniel Lezcano
2025-01-15 15:42     ` Ulf Hansson
2025-02-04 14:33       ` Jonathan Cameron
2025-02-05  8:33         ` Claudiu Beznea
2025-02-05 11:39           ` Jonathan Cameron
2025-01-29 17:24   ` Daniel Lezcano
2025-01-30  9:08     ` Claudiu Beznea
2025-01-30 10:07       ` Daniel Lezcano
2025-01-30 10:30         ` Claudiu Beznea
2025-01-30 10:50           ` Claudiu Beznea
2025-01-30 17:24           ` Daniel Lezcano
2025-01-30 17:32             ` Claudiu Beznea
2025-01-30 20:53             ` Claudiu Beznea
2025-01-30 22:33               ` Daniel Lezcano
2025-01-30 23:16                 ` Claudiu Beznea
2025-02-03 16:30                   ` Claudiu Beznea
2025-01-30 10:33         ` Biju Das
2025-01-30 17:31           ` Daniel Lezcano [this message]
2025-01-30 17:47             ` Biju Das
2025-01-03 16:38 ` [PATCH 3/6] dt-bindings: thermal: r9a08g045-tsu: Document the TSU unit Claudiu
2025-01-08 23:43   ` Rob Herring (Arm)
2025-01-22 10:12   ` Geert Uytterhoeven
2025-01-03 16:38 ` [PATCH 4/6] thermal: renesas: rzg3s: Add thermal driver for the Renesas RZ/G3S SoC Claudiu
2025-01-22 10:29   ` Geert Uytterhoeven
2025-01-25 12:18     ` Jonathan Cameron
2025-01-27  8:32       ` Claudiu Beznea
2025-01-27  8:54         ` Geert Uytterhoeven
2025-01-27  9:11           ` Biju Das
2025-01-27  9:15             ` Claudiu Beznea
2025-01-27  9:17               ` Biju Das
2025-01-03 16:38 ` [PATCH 5/6] arm64: dts: renesas: r9a08g045: Add TSU node Claudiu
2025-01-22 10:31   ` Geert Uytterhoeven
2025-01-30 17:53   ` Daniel Lezcano
2025-01-03 16:38 ` [PATCH 6/6] arm64: defconfig: Enable RZ/G3S thermal Claudiu
2025-01-22 10:33   ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=867eb310-11a7-48bd-b2fa-35e001875498@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=claudiu.beznea.uj@bp.renesas.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=magnus.damm@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=sboyd@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox