@@ -23,6 +23,8 @@
#include "ti-bandgap.h"
#include "../thermal_hwmon.h"
+#define TI_BANDGAP_UPDATE_INTERVAL_MS 250
+
/* common data structures */
struct ti_thermal_data {
struct cpufreq_policy *policy;
@@ -159,7 +161,6 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
char *domain)
{
struct ti_thermal_data *data;
- int interval;
data = ti_bandgap_get_sensor_data(bgp, id);
@@ -177,10 +178,9 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
return PTR_ERR(data->ti_thermal);
}
- interval = jiffies_to_msecs(data->ti_thermal->polling_delay_jiffies);
-
ti_bandgap_set_sensor_data(bgp, id, data);
- ti_bandgap_write_update_interval(bgp, data->sensor_id, interval);
+ ti_bandgap_write_update_interval(bgp, data->sensor_id,
+ TI_BANDGAP_UPDATE_INTERVAL_MS);
if (devm_thermal_add_hwmon_sysfs(bgp->dev, data->ti_thermal))
dev_warn(bgp->dev, "failed to add hwmon sysfs attributes\n");
Currently the TI thermal driver sets the sensor update interval based on the polling of the thermal zone. In order to get the polling rate, the code inspects the thermal zone device strcuture internals, thus breaking the self-encapsulation of the thermal framework core framework. On the other side, we see the common polling rates set in the device tree for the platforms using this driver are 500 or 1000 ms. Setting the polling rate to 250 ms would be far enough to cover the combination we found in the device tree. Instead of accessing the thermal zone device structure polling rate, let's use a common update interval of 250 ms for the driver. Cc: Keerthy <j-keerthy@ti.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> --- drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)