Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 02 2月, 2023 1 次提交
  3. 25 1月, 2023 1 次提交
  5. 06 1月, 2023 3 次提交
    • J
      thermal/drivers/qcom: Fix set_trip_temp() deadlock · e6ec64f8
      由 Johan Hovold 提交于 
      The set_trip_temp() callback is used when changing the trip temperature
through sysfs. As it is called with the thermal-zone-device lock held
it must not use thermal_zone_get_trip() directly or it will deadlock.

Fixes: 78c3e2429be8 ("thermal/drivers/qcom: Use generic thermal_zone_get_trip() function")
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20221214131617.2447-2-johan+linaro@kernel.orgSigned-off-by: NDaniel Lezcano <daniel.lezcano@kernel.org>
      e6ec64f8
    • D
      thermal/core: Add a generic thermal_zone_set_trip() function · 2e38a2a9
      由 Daniel Lezcano 提交于 
      The thermal zone ops defines a set_trip callback where we can invoke
the backend driver to set an interrupt for the next trip point
temperature being crossed the way up or down, or setting the low level
with the hysteresis.

The ops is only called from the thermal sysfs code where the userspace
has the ability to modify a trip point characteristic.

With the effort of encapsulating the thermal framework core code,
let's create a thermal_zone_set_trip() which is the writable side of
the thermal_zone_get_trip() and put there all the ops encapsulation.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20221003092602.1323944-4-daniel.lezcano@linaro.org
      2e38a2a9
    • D
      thermal/core: Add a generic thermal_zone_get_trip() function · 7c3d5c20
      由 Daniel Lezcano 提交于 
      The thermal_zone_device_ops structure defines a set of ops family,
get_trip_temp(), get_trip_hyst(), get_trip_type(). Each of them is
returning a property of a trip point.

The result is the code is calling the ops everywhere to get a trip
point which is supposed to be defined in the backend driver. It is a
non-sense as a thermal trip can be generic and used by the backend
driver to declare its trip points.

Part of the thermal framework has been changed and all the OF thermal
drivers are using the same definition for the trip point and use a
thermal zone registration variant to pass those trip points which are
part of the thermal zone device structure.

Consequently, we can use a generic function to get the trip points
when they are stored in the thermal zone device structure.

This approach can be generalized to all the drivers and we can get rid
of the ops->get_trip_*. That will result to a much more simpler code
and make possible to rework how the thermal trip are handled in the
thermal core framework as discussed previously.

This change adds a function thermal_zone_get_trip() where we get the
thermal trip point structure which contains all the properties (type,
temp, hyst) instead of doing multiple calls to ops->get_trip_*.

That opens the door for trip point extension with more attributes. For
instance, replacing the trip points disabled bitmask with a 'disabled'
field in the structure.

Here we replace all the calls to ops->get_trip_* in the thermal core
code with a call to the thermal_zone_get_trip() function.

The thermal zone ops defines a callback to retrieve the critical
temperature. As the trip handling is being reworked, all the trip
points will be the same whatever the driver and consequently finding
the critical trip temperature will be just a loop to search for a
critical trip point type.

Provide such a generic function, so we encapsulate the ops
get_crit_temp() which can be removed when all the backend drivers are
using the generic trip points handling.

While at it, add the thermal_zone_get_num_trips() to encapsulate the
code more and reduce the grip with the thermal framework internals.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NZhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20221003092602.1323944-2-daniel.lezcano@linaro.org
      7c3d5c20
  7. 26 10月, 2022 1 次提交
  9. 04 10月, 2022 1 次提交
  11. 01 10月, 2022 1 次提交
    • S
      thermal: core: Increase maximum number of trip points · 82b1ec79
      由 Sumeet Pawnikar 提交于 
      On one of the Chrome system, if we define more than 12 trip points,
probe for thermal sensor fails with
"int3403 thermal: probe of INTC1046:03 failed with error -22"
and throws an error as
"thermal_sys: Error: Incorrect number of thermal trips".

The thermal_zone_device_register() interface needs maximum
number of trip points supported in a zone as an argument.
This number can't exceed THERMAL_MAX_TRIPS, which is currently
set to 12. To address this issue, THERMAL_MAX_TRIPS value
has to be increased.

This interface also has an argument to specify a mask of trips
which are writable. This mask is defined as an int.
This mask sets the ceiling for increasing maximum number of
supported trips. With the current implementation, maximum number
of trips can be supported is 31.

Also, THERMAL_MAX_TRIPS macro is used in one place only.
So, remove THERMAL_MAX_TRIPS macro and compare num_trips
directly with using a macro BITS_PER_TYPE(int)-1.
Signed-off-by: NSumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      82b1ec79
  13. 17 8月, 2022 2 次提交
    • D
      thermal/of: Remove old OF code · f59ac19b
      由 Daniel Lezcano 提交于 
      All the drivers are converted to the new OF API, remove the old OF code.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linexp.org>
Link: https://lore.kernel.org/r/20220804224349.1926752-34-daniel.lezcano@linexp.orgSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      f59ac19b
    • D
      thermal/of: Rework the thermal device tree initialization · 3fd6d6e2
      由 Daniel Lezcano 提交于 
      The following changes are reworking entirely the thermal device tree
initialization. The old version is kept until the different drivers
using it are converted to the new API.

The old approach creates the different actors independently. This
approach is the source of the code duplication in the thermal OF
because a thermal zone is created but a sensor is registered
after. The thermal zones are created unconditionnaly with a fake
sensor at init time, thus forcing to provide fake ops and store all
the thermal zone related information in duplicated structures. Then
the sensor is initialized and the code looks up the thermal zone name
using the device tree. Then the sensor is associated to the thermal
zone, and the sensor specific ops are called with a second level of
indirection from the thermal zone ops.

When a sensor is removed (with a module unload), the thermal zone
stays there with the fake sensor.

The cooling device associated with a thermal zone and a trip point is
stored in a list, again duplicating information, using the node name
of the device tree to match afterwards the cooling devices.

The new approach is simpler, it creates a thermal zone when the sensor
is registered and destroys it when the sensor is removed. All the
matching between the cooling device, trip points and thermal zones are
done using the device tree, as well as bindings. The ops are no longer
specific but uses the generic ones provided by the thermal framework.

When the old code won't have any users, it can be removed and the
remaining thermal OF code will be much simpler.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linexp.org>
Link: https://lore.kernel.org/r/20220804224349.1926752-2-daniel.lezcano@linexp.orgSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      3fd6d6e2
  15. 28 7月, 2022 4 次提交
  17. 19 5月, 2022 1 次提交
  19. 14 8月, 2021 2 次提交
  21. 22 4月, 2021 1 次提交
  23. 15 3月, 2021 1 次提交
  25. 20 1月, 2021 5 次提交
  27. 08 1月, 2021 1 次提交
  29. 11 12月, 2020 1 次提交
  31. 12 10月, 2020 2 次提交
  33. 07 7月, 2020 2 次提交
  35. 30 6月, 2020 4 次提交
  37. 14 4月, 2020 6 次提交