mbox series

[v8,00/29] Rework the trip points creation

Message ID 20221003092602.1323944-1-daniel.lezcano@linaro.org
Headers show
Series Rework the trip points creation | expand

Message

Daniel Lezcano Oct. 3, 2022, 9:25 a.m. UTC
This work is the pre-requisite of handling correctly when the trip
point are crossed. For that we need to rework how the trip points are
declared and assigned to a thermal zone.

Even if it appears to be a common sense to have the trip points being
ordered, this no guarantee neither documentation telling that is the
case.

One solution could have been to create an ordered array of trips built
when registering the thermal zone by calling the different get_trip*
ops. However those ops receive a thermal zone pointer which is not
known as it is in the process of creating it.

This cyclic dependency shows we have to rework how we manage the trip
points.

Actually, all the trip points definition can be common to the backend
sensor drivers and we can factor out the thermal trip structure in all
of them.

Then, as we register the thermal trips array, they will be available
in the thermal zone structure and a core function can return the trip
given its id.

The get_trip_* ops won't be needed anymore and could be removed. The
resulting code will be another step forward to a self encapsulated
generic thermal framework.

Most of the drivers can be converted more or less easily. This series
does a first round with most of the drivers. Some remain and will be
converted but with a smaller set of changes as the conversion is a bit
more complex.

Changelog:
 v8:
    - Pretty oneline change and parenthesis removal (Rafael)
    - Collected tags
 v7:
    - Added missing return 0 in the x86_pkg_temp driver
 v6:
    - Improved the code for the get_crit_temp() function as suggested by Rafael
    - Removed inner parenthesis in the set_trip_temp() function and invert the
      conditions. Check the type of the trip point is unchanged
    - Folded patch 4 with 1
    - Add per thermal zone info message in the bang-bang governor
    - Folded the fix for an uninitialized variable in int340x_thermal_zone_add()
 v5:
    - Fixed a deadlock when calling thermal_zone_get_trip() while
      handling the thermal zone lock
    - Remove an extra line in the sysfs change
    - Collected tags
v4:
   - Remove extra lines on exynos changes as reported by Krzysztof Kozlowski
   - Collected tags
 v3:
   - Reorg the series to be git-bisect safe
   - Added the set_trip generic function
   - Added the get_crit_temp generic function
   - Removed more dead code in the thermal-of
   - Fixed the exynos changelog
   - Fixed the error check for the exynos drivers
   - Collected tags
 v2:
   - Added missing EXPORT_SYMBOL_GPL() for thermal_zone_get_trip()
   - Removed tab whitespace in the acerhdf driver
   - Collected tags

Cc: Raju Rangoju <rajur@chelsio.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Peter Kaestle <peter@piie.net>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mark Gross <markgross@kernel.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Amit Kucheria <amitk@kernel.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Nicolas Saenz Julienne <nsaenz@kernel.org>
Cc: Broadcom Kernel Team <bcm-kernel-feedback-list@broadcom.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Lukasz Luba <lukasz.luba@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Thara Gopinath <thara.gopinath@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Antoine Tenart <atenart@kernel.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Dmitry Osipenko <digetx@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: linux-omap@vger.kernel.org

Daniel Lezcano (29):
  thermal/core: Add a generic thermal_zone_get_trip() function
  thermal/sysfs: Always expose hysteresis attributes
  thermal/core: Add a generic thermal_zone_set_trip() function
  thermal/core/governors: Use thermal_zone_get_trip() instead of ops
    functions
  thermal/of: Use generic thermal_zone_get_trip() function
  thermal/of: Remove unused functions
  thermal/drivers/exynos: Use generic thermal_zone_get_trip() function
  thermal/drivers/exynos: of_thermal_get_ntrips()
  thermal/drivers/exynos: Replace of_thermal_is_trip_valid() by
    thermal_zone_get_trip()
  thermal/drivers/tegra: Use generic thermal_zone_get_trip() function
  thermal/drivers/uniphier: Use generic thermal_zone_get_trip() function
  thermal/drivers/hisi: Use generic thermal_zone_get_trip() function
  thermal/drivers/qcom: Use generic thermal_zone_get_trip() function
  thermal/drivers/armada: Use generic thermal_zone_get_trip() function
  thermal/drivers/rcar_gen3: Use the generic function to get the number
    of trips
  thermal/of: Remove of_thermal_get_ntrips()
  thermal/of: Remove of_thermal_is_trip_valid()
  thermal/of: Remove of_thermal_set_trip_hyst()
  thermal/of: Remove of_thermal_get_crit_temp()
  thermal/drivers/st: Use generic trip points
  thermal/drivers/imx: Use generic thermal_zone_get_trip() function
  thermal/drivers/rcar: Use generic thermal_zone_get_trip() function
  thermal/drivers/broadcom: Use generic thermal_zone_get_trip() function
  thermal/drivers/da9062: Use generic thermal_zone_get_trip() function
  thermal/drivers/ti: Remove unused macros ti_thermal_get_trip_value() /
    ti_thermal_trip_is_valid()
  thermal/drivers/acerhdf: Use generic thermal_zone_get_trip() function
  thermal/drivers/cxgb4: Use generic thermal_zone_get_trip() function
  thermal/intel/int340x: Replace parameter to simplify
  thermal/drivers/intel: Use generic thermal_zone_get_trip() function

 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h    |   2 -
 .../ethernet/chelsio/cxgb4/cxgb4_thermal.c    |  41 +----
 drivers/platform/x86/acerhdf.c                |  73 +++-----
 drivers/thermal/armada_thermal.c              |  39 ++---
 drivers/thermal/broadcom/bcm2835_thermal.c    |   8 +-
 drivers/thermal/da9062-thermal.c              |  52 +-----
 drivers/thermal/gov_bang_bang.c               |  39 +++--
 drivers/thermal/gov_fair_share.c              |  18 +-
 drivers/thermal/gov_power_allocator.c         |  51 +++---
 drivers/thermal/gov_step_wise.c               |  22 ++-
 drivers/thermal/hisi_thermal.c                |  11 +-
 drivers/thermal/imx_thermal.c                 |  72 +++-----
 .../int340x_thermal/int340x_thermal_zone.c    |  33 ++--
 .../int340x_thermal/int340x_thermal_zone.h    |   4 +-
 .../processor_thermal_device.c                |  10 +-
 drivers/thermal/intel/x86_pkg_temp_thermal.c  | 120 +++++++------
 drivers/thermal/qcom/qcom-spmi-temp-alarm.c   |  39 ++---
 drivers/thermal/rcar_gen3_thermal.c           |   2 +-
 drivers/thermal/rcar_thermal.c                |  53 +-----
 drivers/thermal/samsung/exynos_tmu.c          |  57 +++----
 drivers/thermal/st/st_thermal.c               |  47 +----
 drivers/thermal/tegra/soctherm.c              |  33 ++--
 drivers/thermal/tegra/tegra30-tsensor.c       |  17 +-
 drivers/thermal/thermal_core.c                | 160 +++++++++++++++---
 drivers/thermal/thermal_core.h                |  24 +--
 drivers/thermal/thermal_helpers.c             |  28 +--
 drivers/thermal/thermal_netlink.c             |  21 +--
 drivers/thermal/thermal_of.c                  | 116 -------------
 drivers/thermal/thermal_sysfs.c               | 133 +++++----------
 drivers/thermal/ti-soc-thermal/ti-thermal.h   |  15 --
 drivers/thermal/uniphier_thermal.c            |  27 ++-
 include/linux/thermal.h                       |  10 ++
 32 files changed, 559 insertions(+), 818 deletions(-)

Comments

Daniel Lezcano Oct. 5, 2022, 12:37 p.m. UTC | #1
Hi Marek,

On 03/10/2022 23:18, Daniel Lezcano wrote:

[ ... ]

>> I've tested this v8 patchset after fixing the issue with Exynos TMU with
>> https://lore.kernel.org/all/20221003132943.1383065-1-daniel.lezcano@linaro.org/ 
>>
>> patch and I got the following lockdep warning on all Exynos-based boards:
>>
>>
>> ======================================================
>> WARNING: possible circular locking dependency detected
>> 6.0.0-rc1-00083-ge5c9d117223e #12945 Not tainted
>> ------------------------------------------------------
>> swapper/0/1 is trying to acquire lock:
>> c1ce66b0 (&data->lock#2){+.+.}-{3:3}, at: exynos_get_temp+0x3c/0xc8
>>
>> but task is already holding lock:
>> c2979b94 (&tz->lock){+.+.}-{3:3}, at:
>> thermal_zone_device_update.part.0+0x3c/0x528
>>
>> which lock already depends on the new lock.
> 
> I'm wondering if the problem is not already there and related to 
> data->lock ...
> 
> Doesn't the thermal zone lock already prevent racy access to the data 
> structure?
> 
> Another question: if the sensor clock is disabled after reading it, how 
> does the hardware update the temperature and detect the programed 
> threshold is crossed?

just a gentle ping, as the fix will depend on your answer ;)

Thanks

   -- D.

[ ... ]
Marek Szyprowski Oct. 5, 2022, 1:05 p.m. UTC | #2
On 05.10.2022 14:37, Daniel Lezcano wrote:
>
> Hi Marek,
>
> On 03/10/2022 23:18, Daniel Lezcano wrote:
>
> [ ... ]
>
>>> I've tested this v8 patchset after fixing the issue with Exynos TMU 
>>> with
>>> https://lore.kernel.org/all/20221003132943.1383065-1-daniel.lezcano@linaro.org/ 
>>>
>>> patch and I got the following lockdep warning on all Exynos-based 
>>> boards:
>>>
>>>
>>> ======================================================
>>> WARNING: possible circular locking dependency detected
>>> 6.0.0-rc1-00083-ge5c9d117223e #12945 Not tainted
>>> ------------------------------------------------------
>>> swapper/0/1 is trying to acquire lock:
>>> c1ce66b0 (&data->lock#2){+.+.}-{3:3}, at: exynos_get_temp+0x3c/0xc8
>>>
>>> but task is already holding lock:
>>> c2979b94 (&tz->lock){+.+.}-{3:3}, at:
>>> thermal_zone_device_update.part.0+0x3c/0x528
>>>
>>> which lock already depends on the new lock.
>>
>> I'm wondering if the problem is not already there and related to 
>> data->lock ...
>>
>> Doesn't the thermal zone lock already prevent racy access to the data 
>> structure?
>>
>> Another question: if the sensor clock is disabled after reading it, 
>> how does the hardware update the temperature and detect the programed 
>> threshold is crossed?
>
> just a gentle ping, as the fix will depend on your answer ;)
>
Sorry, I've been busy with other stuff. I thought I will fix this once I 
find a bit of spare time.

IMHO the clock management is a bit over-engineered, as there is little 
(if any) benefit from such fine grade clock management. That clock is 
needed only for the AHB related part of the TMU (reading/writing the 
registers). The IRQ generation and temperature measurement is clocked 
from so called 'sclk' (special clock).

I also briefly looked at the code and the internal lock doesn't look to 
be really necessary assuming that the thermal core already serializes 
all the calls.

Best regards
Daniel Lezcano Oct. 6, 2022, 6:55 a.m. UTC | #3
Hi Marek,

On 05/10/2022 15:05, Marek Szyprowski wrote:
> 
> On 05.10.2022 14:37, Daniel Lezcano wrote:
>>
>> Hi Marek,
>>
>> On 03/10/2022 23:18, Daniel Lezcano wrote:
>>
>> [ ... ]
>>
>>>> I've tested this v8 patchset after fixing the issue with Exynos TMU
>>>> with
>>>> https://lore.kernel.org/all/20221003132943.1383065-1-daniel.lezcano@linaro.org/
>>>>
>>>> patch and I got the following lockdep warning on all Exynos-based
>>>> boards:
>>>>
>>>>
>>>> ======================================================
>>>> WARNING: possible circular locking dependency detected
>>>> 6.0.0-rc1-00083-ge5c9d117223e #12945 Not tainted
>>>> ------------------------------------------------------
>>>> swapper/0/1 is trying to acquire lock:
>>>> c1ce66b0 (&data->lock#2){+.+.}-{3:3}, at: exynos_get_temp+0x3c/0xc8
>>>>
>>>> but task is already holding lock:
>>>> c2979b94 (&tz->lock){+.+.}-{3:3}, at:
>>>> thermal_zone_device_update.part.0+0x3c/0x528
>>>>
>>>> which lock already depends on the new lock.
>>>
>>> I'm wondering if the problem is not already there and related to
>>> data->lock ...
>>>
>>> Doesn't the thermal zone lock already prevent racy access to the data
>>> structure?
>>>
>>> Another question: if the sensor clock is disabled after reading it,
>>> how does the hardware update the temperature and detect the programed
>>> threshold is crossed?
>>
>> just a gentle ping, as the fix will depend on your answer ;)
>>
> Sorry, I've been busy with other stuff. I thought I will fix this once I
> find a bit of spare time.

Ok, that is great if you can find time to fix it up because I've other 
drivers to convert to the generic thermal trips.


> IMHO the clock management is a bit over-engineered, as there is little
> (if any) benefit from such fine grade clock management. That clock is
> needed only for the AHB related part of the TMU (reading/writing the
> registers). The IRQ generation and temperature measurement is clocked
> from so called 'sclk' (special clock).
> 
> I also briefly looked at the code and the internal lock doesn't look to
> be really necessary assuming that the thermal core already serializes
> all the calls.

I looked at the code and I think the driver can be simplified (fixed?) 
even more.

IIUC, the sensor has multiple trip point interrupts, so if the device 
tree is describing more trip points than the sensor supports, there is a 
warning and the number of trip point is capped.

IMO that can be simplified by using two trip point interrupt because the 
thermal_zone_device_update() will call the set_trips callback with the 
new boundaries. IOW, the thermal framework sets a new trip point 
interrupt when one is crossed.

That should result in the simplification of the tmu_control as well as 
the tmu_probe function. As well as removing the limitation of the number 
of trip points.

In order to have that correctly working, the 'set_trips' ops must be 
used to call the tmu_control callback instead of calling it in tmu_probe.

The intialization workflow should be:

probe->...
  ->thermal_zone_device_register()
   ->thermal_zone_device_update()
    ->update_trip_points()
     ->ops->set_trips()
       ->tmu_control()

Also, replace the workqueue by a threaded interrupt.

Does it make sense?
Marek Szyprowski Oct. 6, 2022, 4:25 p.m. UTC | #4
Hi Daniel,

On 06.10.2022 08:55, Daniel Lezcano wrote:
>
> On 05/10/2022 15:05, Marek Szyprowski wrote:
>>
>> On 05.10.2022 14:37, Daniel Lezcano wrote:
>>>
>>> On 03/10/2022 23:18, Daniel Lezcano wrote:
>>>
>>> [ ... ]
>>>
>>>>> I've tested this v8 patchset after fixing the issue with Exynos TMU
>>>>> with
>>>>> https://lore.kernel.org/all/20221003132943.1383065-1-daniel.lezcano@linaro.org/ 
>>>>>
>>>>>
>>>>> patch and I got the following lockdep warning on all Exynos-based
>>>>> boards:
>>>>>
>>>>>
>>>>> ======================================================
>>>>> WARNING: possible circular locking dependency detected
>>>>> 6.0.0-rc1-00083-ge5c9d117223e #12945 Not tainted
>>>>> ------------------------------------------------------
>>>>> swapper/0/1 is trying to acquire lock:
>>>>> c1ce66b0 (&data->lock#2){+.+.}-{3:3}, at: exynos_get_temp+0x3c/0xc8
>>>>>
>>>>> but task is already holding lock:
>>>>> c2979b94 (&tz->lock){+.+.}-{3:3}, at:
>>>>> thermal_zone_device_update.part.0+0x3c/0x528
>>>>>
>>>>> which lock already depends on the new lock.
>>>>
>>>> I'm wondering if the problem is not already there and related to
>>>> data->lock ...
>>>>
>>>> Doesn't the thermal zone lock already prevent racy access to the data
>>>> structure?
>>>>
>>>> Another question: if the sensor clock is disabled after reading it,
>>>> how does the hardware update the temperature and detect the programed
>>>> threshold is crossed?
>>>
>>> just a gentle ping, as the fix will depend on your answer ;)
>>>
>> Sorry, I've been busy with other stuff. I thought I will fix this once I
>> find a bit of spare time.
>
> Ok, that is great if you can find time to fix it up because I've other 
> drivers to convert to the generic thermal trips.
>
>
>> IMHO the clock management is a bit over-engineered, as there is little
>> (if any) benefit from such fine grade clock management. That clock is
>> needed only for the AHB related part of the TMU (reading/writing the
>> registers). The IRQ generation and temperature measurement is clocked
>> from so called 'sclk' (special clock).
>>
>> I also briefly looked at the code and the internal lock doesn't look to
>> be really necessary assuming that the thermal core already serializes
>> all the calls.
>
> I looked at the code and I think the driver can be simplified (fixed?) 
> even more.
>
> IIUC, the sensor has multiple trip point interrupts, so if the device 
> tree is describing more trip points than the sensor supports, there is 
> a warning and the number of trip point is capped.
>
> IMO that can be simplified by using two trip point interrupt because 
> the thermal_zone_device_update() will call the set_trips callback with 
> the new boundaries. IOW, the thermal framework sets a new trip point 
> interrupt when one is crossed.
>
> That should result in the simplification of the tmu_control as well as 
> the tmu_probe function. As well as removing the limitation of the 
> number of trip points.
>
> In order to have that correctly working, the 'set_trips' ops must be 
> used to call the tmu_control callback instead of calling it in tmu_probe.
>
> The intialization workflow should be:
>
> probe->...
>  ->thermal_zone_device_register()
>   ->thermal_zone_device_update()
>    ->update_trip_points()
>     ->ops->set_trips()
>       ->tmu_control()
>
> Also, replace the workqueue by a threaded interrupt.
>
> Does it make sense?

Yes, definitely. Frankly speaking I've never looked into that code, so I 
was not aware that it needs some cleanup.

Best regards