Re: [PATCH 0/4] Thermal Framework Enhancements

[Zhang Rui <rui.zhang@intel.com>]

On 一, 2012-06-11 at 23:09 +0530, Durgadoss R wrote:
> This patch series attempts to add some simple governors/
> throttling algorithms to the generic thermal layer.

Oh, this is something what I want to do, but not sure when.
Thanks, Durga.

> Although this patch set creates simple governors which depend
> on the platform data provided, we can start here, and write
> some really smart algorithms that will do the wonder!!
> 
> Patch 1/4: Creates necessary infrastructure required to
> 	   add throttling algorithms in thermal_sys.c
> 	   1. Introduces the get_trend callback
seems duplicate work of my patch set. :(

> 	   2. Introduces the notify_thermal_framework() API

> 	   3. Exposes sysfs to show/store the throttle_policy
> 
yes, I think we need this.

> Patch 2/4: Introduce fair_share governor
> 	   This throttles the cooling_devices according to their
> 	   weights (and hence the name; Suggestion are welcome :-).
> 	   The weights in turn describe the effectiveness of a
> 	   particular cooling device in cooling a thermal zone.
> 

> Patch 3/4: Introduce step_wise governor
> 	   This throttles/de-throttles the cooling devices one
> 	   step at a time. This is exactly similar to the code
> 	   we have in thermal_zone_device_update function. The
> 	   intention is to move all 'throttling logic' related
> 	   code outside thermal_sys.c and keep them separate.

totally agree.
This is in my TODO list as well. :)

BTW, we may need an easy "userspace" governor as well.

> 
> Patch 4/4: Platform data patch
> 	   This patch is not for merge. Just as an example to
> 	   show how we can provide platform data to thermal
> 	   framework. Not that we do not know how to fill structures,
> 	   I felt the patch set is in-complete without this. That's
> 	   why it is here. From next versions, I will ignore this one.
> 
> TODO on these patch sets:
> * Sync up with Rui's latest patches

agreed.

> * Add more protection and tidy up the existing ones
> * Expose the weights and cooling devices through sysfs (Read-Only)

what do you mean "cooling devices"?

> * Remove all throttling related code(if we all agree) from thermal_sys.c

Ack!

> * In fair_share, before setting new state, check if there are other zones,
>   which do not want the 'state' to be changed.

Yep, I think this is handled in my arbitrator patch. :p

>   (To do this, we have to loop through the thermal_tz_list and 
>   thermal_cdev_list inside fair_share.c. Need to see how good it is
>   to make this lists public)

IMO, these governors should just update the thermal_instance, and then
invokes thermal_zone_do_update(). They should not change the cooling
state directly.

> * If we all agree, use step_wise and remove linear_throttle from thermal_sys.c

agreed.

> * Enhance notify_user_space(), so that the use land can extract some sane
>   information out of UEvent.
> 
> WishList:
> * Find a way to provide platform data so that we can map cooling devices
>   for a trip point in a thermal zone.

hmm, what information do we need except "weight"?
I think we can register the weight information when do the binding, like
I did for "upper" and "lower" limits.

> * Make all _throttle methods have same signature. This way we can make use
>   of function pointers and make the code a bit simpler.

what does signature mean?

> * The simple governors heavily depend on the platform data provided. We
>   can think of some really smart logic, that depends on very minimal platform
>   data, and do things on its own :-)
> * Make other subsystem core files register with the thermal framework as a
>   thermal sensor or as a cooling device as appropriate.
>   (I am thinking of Power Supply, Video, cpufreq for now)

about cpufreq, I think Amit has some work on this. hah

> * Ah, Find time to do all this !
> 
me too. :)

Again, thanks for your work, they are good ideas.

thanks,
rui

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html