From: "hongbo.zhang" hongbo.zhang@linaro.com
This patch set contains two patches.
[PATCH 1/2] A new interface is introduced to deactive all the referenced cooling devices when thermal zone is disabled. Because the cooling device list is maintained in the generic thermal layer, the thermal driver cannot walk through the list and cannot deactive its cooling devices either. This interface is needed in the .set_mode callback when the thermal zone mode is set to "disabled".
[PATCH 2/2] When a cooling device is unbound it should be deactived, otherwise cooling device will keep active after unbinding, this isn't what we expect.
hongbo.zhang (2): Thermal: Add interface to deactive cooling devices. Thermal: Deactive cooling device when unbind it.
drivers/thermal/thermal_sys.c | 24 ++++++++++++++++++++++++ include/linux/thermal.h | 1 + 2 files changed, 25 insertions(+)
From: "hongbo.zhang" hongbo.zhang@linaro.com
If the thermal zone mode is disabled, all the referenced cooling devices should be put into state zero. Without this patch the thermal driver cannot deactive all its cooling devices in .set_mode callback, because the cooling device list is maintained in the generic thermal layer. This interface is introduced to fix it.
Signed-off-by: hongbo.zhang hongbo.zhang@linaro.com --- drivers/thermal/thermal_sys.c | 22 ++++++++++++++++++++++ include/linux/thermal.h | 1 + 2 files changed, 23 insertions(+)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 2ab31e4..2c28c85 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -1130,6 +1130,28 @@ leave: EXPORT_SYMBOL(thermal_zone_device_update);
/** + * thermal_zone_device_deactive - deactive cooling devices of thermal zone + * @tz: thermal zone device + * + * This function should be called in the thermal zone device .set_mode + * callback when the thermal zone is disabled. + */ +void thermal_zone_device_deactive(struct thermal_zone_device *tz) +{ + struct thermal_cooling_device_instance *instance; + struct thermal_cooling_device *cdev; + + mutex_lock(&tz->lock); + list_for_each_entry(instance, &tz->cooling_devices, node) { + cdev = instance->cdev; + if (cdev->ops->set_cur_state) + cdev->ops->set_cur_state(cdev, 0); + } + mutex_unlock(&tz->lock); +} +EXPORT_SYMBOL(thermal_zone_device_deactive); + +/** * create_trip_attrs - create attributes for trip points * @tz: the thermal zone device * @mask: Writeable trip point bitmap. diff --git a/include/linux/thermal.h b/include/linux/thermal.h index 4b94a61..5e915a3 100644 --- a/include/linux/thermal.h +++ b/include/linux/thermal.h @@ -161,6 +161,7 @@ int thermal_zone_bind_cooling_device(struct thermal_zone_device *, int, int thermal_zone_unbind_cooling_device(struct thermal_zone_device *, int, struct thermal_cooling_device *); void thermal_zone_device_update(struct thermal_zone_device *); +void thermal_zone_device_deactive(struct thermal_zone_device *); struct thermal_cooling_device *thermal_cooling_device_register(char *, void *, const struct thermal_cooling_device_ops *); void thermal_cooling_device_unregister(struct thermal_cooling_device *);
From: "hongbo.zhang" hongbo.zhang@linaro.com
A cooling device should be set to state zero when it is unbound.
Signed-off-by: hongbo.zhang hongbo.zhang@linaro.com --- drivers/thermal/thermal_sys.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 2c28c85..efc5c56 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -885,6 +885,8 @@ int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz, mutex_lock(&tz->lock); list_for_each_entry_safe(pos, next, &tz->cooling_devices, node) { if (pos->tz == tz && pos->trip == trip && pos->cdev == cdev) { + if (cdev->ops->set_cur_state) + cdev->ops->set_cur_state(cdev, 0); list_del(&pos->node); mutex_unlock(&tz->lock); goto unbind;
On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
From: "hongbo.zhang" hongbo.zhang@linaro.com
This patch set contains two patches.
[PATCH 1/2] A new interface is introduced to deactive all the referenced cooling devices when thermal zone is disabled.
we can not deactive a cooling device directly. we should deactive all the thermal_instances for this thermal zone. because a cooling device may be referenced in multiple thermal zones.
Because the cooling device list is maintained in the generic thermal layer, the thermal driver cannot walk through the list and cannot deactive its cooling devices either. This interface is needed in the .set_mode callback when the thermal zone mode is set to "disabled".
Durga is introducing the cooling policy for the generic thermal layer and one of them is "userspace". if we set the policy to userspace, the generic thermal layer will do nothing but getting input from userspace. if we have an API to change the cooling policy for a thermal zone, can this be used instead?
[PATCH 2/2] When a cooling device is unbound it should be deactived, otherwise cooling device will keep active after unbinding, this isn't what we expect.
as I said, it should delete the thermal_instance and then update the cooling device.
thanks, rui
On 21 September 2012 15:21, Zhang Rui rui.zhang@intel.com wrote:
On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
From: "hongbo.zhang" hongbo.zhang@linaro.com
This patch set contains two patches.
[PATCH 1/2] A new interface is introduced to deactive all the referenced cooling devices when thermal zone is disabled.
we can not deactive a cooling device directly. we should deactive all the thermal_instances for this thermal zone. because a cooling device may be referenced in multiple thermal zones.
Understand.
Because the cooling device list is maintained in the generic thermal layer, the thermal driver cannot walk through the list and cannot deactive its cooling devices either. This interface is needed in the .set_mode callback when the thermal zone mode is set to "disabled".
Durga is introducing the cooling policy for the generic thermal layer and one of them is "userspace". if we set the policy to userspace, the generic thermal layer will do nothing but getting input from userspace. if we have an API to change the cooling policy for a thermal zone, can this be used instead?
The reason I sent out these patches is that I found out deactivation of cooling devices is necessary, and I didn't see any update of thermal framework recently. Since you are still working on this framework, can you consider this deactivation function in your next version? or need I resend again? I think it is better you do it.
Another propose is that let the thermal driver walk through its cooling device list is also important I think, if "userspace" mode is introduced, the thermal driver needs to manipulate its cooling device, the thermal driver cannot do this without knowing its cooling devices list. (one method to achieve this is as my last patch several weeks ago)
Another question, when will you update your framework, v3.7? Thanks.
[PATCH 2/2] When a cooling device is unbound it should be deactived, otherwise cooling device will keep active after unbinding, this isn't what we expect.
as I said, it should delete the thermal_instance and then update the cooling device.
Understand.
thanks, rui
On 五, 2012-09-21 at 15:50 +0800, Hongbo Zhang wrote:
On 21 September 2012 15:21, Zhang Rui rui.zhang@intel.com wrote:
On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
From: "hongbo.zhang" hongbo.zhang@linaro.com
This patch set contains two patches.
[PATCH 1/2] A new interface is introduced to deactive all the referenced cooling devices when thermal zone is disabled.
we can not deactive a cooling device directly. we should deactive all the thermal_instances for this thermal zone. because a cooling device may be referenced in multiple thermal zones.
Understand.
Because the cooling device list is maintained in the generic thermal layer, the thermal driver cannot walk through the list and cannot deactive its cooling devices either. This interface is needed in the .set_mode callback when the thermal zone mode is set to "disabled".
Durga is introducing the cooling policy for the generic thermal layer and one of them is "userspace". if we set the policy to userspace, the generic thermal layer will do nothing but getting input from userspace. if we have an API to change the cooling policy for a thermal zone, can this be used instead?
The reason I sent out these patches is that I found out deactivation of cooling devices is necessary, and I didn't see any update of thermal framework recently. Since you are still working on this framework, can you consider this deactivation function in your next version? or need I resend again? I think it is better you do it.
yes, I'll do it.
Another propose is that let the thermal driver walk through its cooling device list is also important I think, if "userspace" mode is introduced, the thermal driver needs to manipulate its cooling device, the thermal driver cannot do this without knowing its cooling devices list. (one method to achieve this is as my last patch several weeks ago)
thermal_instance list is enough for this, because a cooling device may be referenced in multiple trip points for one thermal zone, the thermal zone device should just deactive all the thermal instances when using "userspace" governor.
Another question, when will you update your framework, v3.7?
as this change is introduced recently, I'm not sure if we can catch up 3.7 merge window.
thanks, rui
On 21 September 2012 16:02, Zhang Rui rui.zhang@intel.com wrote:
On 五, 2012-09-21 at 15:50 +0800, Hongbo Zhang wrote:
On 21 September 2012 15:21, Zhang Rui rui.zhang@intel.com wrote:
On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
From: "hongbo.zhang" hongbo.zhang@linaro.com
This patch set contains two patches.
[PATCH 1/2] A new interface is introduced to deactive all the referenced cooling devices when thermal zone is disabled.
we can not deactive a cooling device directly. we should deactive all the thermal_instances for this thermal zone. because a cooling device may be referenced in multiple thermal zones.
Understand.
Because the cooling device list is maintained in the generic thermal layer, the thermal driver cannot walk through the list and cannot deactive its cooling devices either. This interface is needed in the .set_mode callback when the thermal zone mode is set to "disabled".
Durga is introducing the cooling policy for the generic thermal layer and one of them is "userspace". if we set the policy to userspace, the generic thermal layer will do nothing but getting input from userspace. if we have an API to change the cooling policy for a thermal zone, can this be used instead?
The reason I sent out these patches is that I found out deactivation of cooling devices is necessary, and I didn't see any update of thermal framework recently. Since you are still working on this framework, can you consider this deactivation function in your next version? or need I resend again? I think it is better you do it.
yes, I'll do it.
OK, thanks.
Another propose is that let the thermal driver walk through its cooling device list is also important I think, if "userspace" mode is introduced, the thermal driver needs to manipulate its cooling device, the thermal driver cannot do this without knowing its cooling devices list. (one method to achieve this is as my last patch several weeks ago)
thermal_instance list is enough for this, because a cooling device may be referenced in multiple trip points for one thermal zone, the thermal zone device should just deactive all the thermal instances when using "userspace" governor.
Get it.
Another question, when will you update your framework, v3.7?
as this change is introduced recently, I'm not sure if we can catch up 3.7 merge window.
I will rebase ST-Ericsson thermal driver against your new framework and try to upstream it then.
thanks, rui
-
Hongbo Zhang -
Zhang Rui -
zhanghongbo