Re: [PATCH 2/6] thermal: of: Export non-devres helper to register/unregister thermal zone
From: Daniel Lezcano <hidden>
Date: 2025-01-29 17:24:36
Also in:
linux-clk, linux-devicetree, linux-pm, linux-renesas-soc, lkml
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>