All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Claudiu <claudiu.beznea@tuxon.dev>
Cc: rafael@kernel.org, rui.zhang@intel.com, lukasz.luba@arm.com,
	robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	geert+renesas@glider.be, magnus.damm@gmail.com,
	mturquette@baylibre.com, sboyd@kernel.org,
	p.zabel@pengutronix.de, ulf.hansson@linaro.org,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.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: Wed, 29 Jan 2025 18:24:32 +0100	[thread overview]
Message-ID: <Z5pkUNNvsWPjRQvy@mai.linaro.org> (raw)
In-Reply-To: <20250103163805.1775705-3-claudiu.beznea.uj@bp.renesas.com>

Hi Claudiu,

On Fri, Jan 03, 2025 at 06:38:01PM +0200, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> On the Renesas RZ/G3S (and other Renesas SoCs, e.g., RZ/G2{L, LC, UL}),
> clocks are managed through PM domains. These PM domains, registered on
> behalf of the clock controller driver, are configured with
> GENPD_FLAG_PM_CLK. In most of the Renesas drivers used by RZ SoCs, the
> clocks are enabled/disabled using runtime PM APIs.
> 
> During probe, devices are attached to the PM domain controlling their
> clocks. Similarly, during removal, devices are detached from the PM domain.
> 
> The detachment call stack is as follows:
> 
> device_driver_detach() ->
>   device_release_driver_internal() ->
>     __device_release_driver() ->
>       device_remove() ->
>         platform_remove() ->
> 	  dev_pm_domain_detach()
> 
> In the upcoming Renesas RZ/G3S thermal driver, the
> struct thermal_zone_device_ops::change_mode API is implemented to
> start/stop the thermal sensor unit. Register settings are updated within
> the change_mode API.
> 
> In case devres helpers are used for thermal zone register/unregister the
> struct thermal_zone_device_ops::change_mode API is invoked when the
> driver is unbound. The identified call stack is as follows:
> 
> device_driver_detach() ->
>   device_release_driver_internal() ->
>     device_unbind_cleanup() ->
>       devres_release_all() ->
>         devm_thermal_of_zone_release() ->
> 	  thermal_zone_device_disable() ->
> 	    thermal_zone_device_set_mode() ->
> 	      rzg3s_thermal_change_mode()
> 
> The device_unbind_cleanup() function is called after the thermal device is
> detached from the PM domain (via dev_pm_domain_detach()).
> 
> The rzg3s_thermal_change_mode() implementation calls
> pm_runtime_resume_and_get()/pm_runtime_put_autosuspend() before/after
> accessing the registers. However, during the unbind scenario, the
> devm_thermal_of_zone_release() is invoked after dev_pm_domain_detach().
> Consequently, the clocks are not enabled, as the device is removed from
> the PM domain at this time, leading to an Asynchronous SError Interrupt.
> The system cannot be used after this.

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.

Would the IP need some cycles to capture the temperature accurately after the
clock is enabled ?

> Add thermal_of_zone_register()/thermal_of_zone_unregister(). These will
> be used in the upcomming RZ/G3S thermal driver.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>


  parent reply	other threads:[~2025-01-29 17:26 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 [this message]
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
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=Z5pkUNNvsWPjRQvy@mai.linaro.org \
    --to=daniel.lezcano@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.