[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7b263423-11f8-d3e8-d040-e045dc2fb74c@linaro.org>
Date: Mon, 23 Jan 2023 19:02:31 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>,
rafael@...nel.org
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
rui.zhang@...el.com, Amit Kucheria <amitk@...nel.org>,
Sumeet Pawnikar <sumeet.r.pawnikar@...el.com>,
Shang XiaoJing <shangxiaojing@...wei.com>
Subject: Re: [PATCH 2/3] thermal/drivers/intel: Use generic trip points for
processor_thermal_device_pci
Hi Srinivas,
On 18/01/2023 20:09, srinivas pandruvada wrote:
> On Wed, 2023-01-18 at 19:16 +0100, Daniel Lezcano wrote:
>> The thermal framework gives the possibility to register the trip
>> points with the thermal zone. When that is done, no get_trip_* ops
>> are
>> needed and they can be removed.
>>
>> Convert ops content logic into generic trip points and register them
>> with the
>> thermal zone.
>>
> In this scheme is the assumption is that trip point temperature never
> changes? If firmware updated the trip temperature, what needs to be
> done?
I'm a bit confused about the situation where the firmware can change the
trip point in the back of the OSPM.
Does the firmware send a notification about the trip change? Or does it
assume the OSPM will be reading the trip point while monitoring/polling
the thermal zone ?
Is the question for this particular driver?
If the trip point is changed by the userspace (via sysfs),
thermal_zone_set_trip() is used which in turn changes the thermal trip
temperature directly in the generic structure and then calls the back
set_trip_temp.
--
<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
Powered by blists - more mailing lists